Cedar Backup has been designed to backup entire “pools” of machines. In any given pool, there is one master and some number of clients. Most of the work takes place on the master, so configuring a client is a little simpler than configuring a master.
Backups are designed to take place over an RSH or SSH connection. Because RSH is generally considered insecure, you are encouraged to use SSH rather than RSH. This document will only describe how to configure Cedar Backup to use SSH; if you want to use RSH, you're on your own.
Once you complete all of these configuration steps, your backups will run as scheduled out of cron. Any errors that occur will be reported in daily emails to your root user (or the user that receives root's email). If you don't receive any emails, then you know your backup worked.
Note: all of these configuration steps should be run as the root user, unless otherwise indicated.
See Appendix D, Securing Password-less SSH Connections for some important notes on how to optionally further secure password-less SSH connections to your clients.
There are four parts to a Cedar Backup run: collect, stage, store and purge. The usual way of setting off these steps is through a set of cron jobs. Although you won't create your cron jobs just yet, you should decide now when you will run your backup so you are prepared for later.
Backing up large directories and creating ISO filesystem images can be intensive operations, and could slow your computer down significantly. Choose a backup time that will not interfere with normal use of your computer. Usually, you will want the backup to occur every day, but it is possible to configure cron to execute the backup only one day per week, three days per week, etc.
Because of the way Cedar Backup works, you must ensure that your
backup always runs on the first day of your
configured week. This is because Cedar Backup will only clear
incremental backup information and re-initialize your media when
running on the first day of the week. If you skip running Cedar
Backup on the first day of the week, your backups will likely be
“confused” until the next week begins, or until you
re-run the backup using the --full flag.
Cedar Backup relies on email for problem notification. This notification works through the magic of cron. Cron will email any output from each job it executes to the user associated with the job. Since by default Cedar Backup only writes output to the terminal if errors occur, this neatly ensures that notification emails will only be sent out if errors occur.
In order to receive problem notifications, you must make sure that email works for the user which is running the Cedar Backup cron jobs (typically root). Refer to your distribution's documentation for information on how to configure email on your system. Note that you may prefer to configure root's email to forward to some other user, so you do not need to check the root user's mail in order to see Cedar Backup errors.
You will not be able to complete the client configuration until at least step 3 of the master's configuration has been completed. In particular, you will need to know the master's public SSH identity to fully configure a client.
To find the master's public SSH identity, log in as the backup
user on the master and cat the public identity
file ~/.ssh/id_rsa.pub:
user@machine> cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0vOKjlfwohPg1oPRdrmwHk75l3mI9Tb/WRZfVnu2Pw69
uyphM9wBLRo6QfOC2T8vZCB8o/ZIgtAM3tkM0UgQHxKBXAZ+H36TOgg7BcI20I93iGtzpsMA/uXQy8kH
HgZooYqQ9pw+ZduXgmPcAAv2b5eTm07wRqFt/U84k6bhTzs= user@machine
Choose a user to be used for backups. Some platforms may come with
a "ready made" backup user. For other platforms, you may have to
create a user yourself. You may choose any id you like, but a
descriptive name such as backup or
cback is a good choice. See your
distribution's documentation for information on how to add a user.
Standard Debian systems come with a user named
backup. You may choose to stay with this
user or create another one.
Once you have created your backup user, you must create an SSH keypair for it. Log in as your backup user, and then run the command ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa:
user@machine> ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Created directory '/home/user/.ssh'.
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
11:3e:ad:72:95:fe:96:dc:1e:3b:f4:cc:2c:ff:15:9e user@machine
The default permissions for this directory should be fine.
However, if the directory existed before you ran
ssh-keygen, then you may need to modify the
permissions. Make sure that the ~/.ssh
directory is readable only by the backup user (i.e. mode
700), that the
~/.ssh/id_rsa file is only readable and
writable only by the backup user (i.e. mode 600)
and that the ~/.ssh/id_rsa.pub file is
writable only by the backup user (i.e. mode 600
or mode 644).
Finally, take the master's public SSH identity (which you found in
step 2) and cut-and-paste it into the file
~/.ssh/authorized_keys. Make sure the
identity value is pasted into the file all on one
line, and that the authorized_keys
file is owned by your backup user and has permissions
600.
If you have other preferences or standard ways of setting up your users' SSH configuration (i.e. different key type, etc.), feel free to do things your way. The important part is that the master must be able to SSH into a client with no password entry required.
Cedar Backup requires a backup directory tree on disk. This directory tree must be roughly as big as the amount of data that will be backed up on a nightly basis (more if you elect not to purge it all every night).
You should create a collect directory and a working (temporary) directory. One recommended layout is this:
/opt/
backup/
collect/
tmp/
If you will be backing up sensitive information (i.e. password
files), it is recommended that these directories be owned by the
backup user (whatever you named it), with permissions
700.
You don't have to use /opt as the root of your
directory structure. Use anything you would like. I use
/opt because it is my “dumping
ground” for filesystems that Debian does not manage.
Some users have requested that the Debian packages set up a more
"standard" location for backups right out-of-the-box. I have
resisted doing this because it's difficult to choose an
appropriate backup location from within the package. If you
would prefer, you can create the backup directory structure
within some existing Debian directory such as
/var/backups or
/var/tmp.
Following the instructions in the section called “Configuration File Format” (above), create a configuration file for your machine. Since you are working with a client, you must configure all action-specific sections for the collect and purge actions.
The usual location for the Cedar Backup config file is
/etc/cback.conf. If you change the location,
make sure you edit your cronjobs (below) to point the
cback script at the correct config file (using
the --config option).
Configuration files should always be writable only by root (or by the file owner, if the owner is not root).
If you intend to place confidental information into the Cedar Backup configuration file, make sure that you set the filesystem permissions on the file appropriately. For instance, if you configure any extensions that require passwords or other similar information, you should make the file readable only to root or to the file owner (if the owner is not root).
Use the command cback validate to validate your configuration file. This command checks that the configuration file can be found and parsed, and also checks for typical configuration problems. This command only validates configuration on the one client, not the master or any other clients in a pool.
Note: the most common cause of configuration problems is in not closing XML tags properly. Any XML tag that is “opened” must be “closed” appropriately.
Use the command cback --full collect purge. If the
command completes with no output, then the backup was run successfully.
Just to be sure that everything worked properly, check the logfile
(/var/log/cback.log) for errors.
Since Cedar Backup should be run as root, you should add a set of
lines like this to your /etc/crontab file:
30 00 * * * root cback collect
30 06 * * * root cback purge
You should consider adding the --output or
-O switch to your cback
command-line in cron. This will result in larger logs, but could
help diagnose problems when commands like
cdrecord or mkisofs fail
mysteriously.
You will need to coordinate the collect and purge actions on the client so that the collect action completes before the master attempts to stage, and so that the purge action does not begin until after the master has completed staging. Usually, allowing an hour or two between steps should be sufficient. [21]
For general information about using cron, see the manpage for crontab(5).
On a Debian system, execution of daily backups is controlled by
the file /etc/cron.d/cedar-backup2. As
installed, this file contains several different settings, all
commented out. Uncomment the “Client machine”
entries in the file, and change the lines so that the backup
goes off when you want it to.