Cedar Backup has been designed primarily for situations where there is a single master and a set of other clients that the master interacts with. However, it will just as easily work for a single machine (a backup pool of one).
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.
This setup procedure discusses how to set up Cedar Backup in the “normal case” for a pool of one. If you would like to modify the way Cedar Backup works (for instance, by ignoring the store stage and just letting your backup sit in a staging directory), you can do that. You'll just have to modify the procedure below based on information in the remainder of the manual.
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 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.
Your CD-R or CD-RW drive must either be a SCSI device or must be configured to act like a SCSI device from the perspective of the cdrecord and mkisofs commands. Regardless of what kind of drive you have, make sure you know its SCSI address and its filesystem device name. The SCSI address will be used to write to media, and the device name will be used when Cedar Backup needs to mount the media (for instance, when a validation check must be run).
See the section called “Configuring your SCSI Device” for more information on SCSI devices and how they are configured.
There is no need to set up your CD-R or CD-RW device if you have decided not to execute the store action.
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.
Cedar Backup requires a backup directory tree on disk. This directory tree must be roughly three times as big as the amount of data that will be backed up on a nightly basis, to allow for the data to be collected, staged, and then placed into an ISO CD image on disk. (This is one disadvantage to using Cedar Backup in single-machine pools, but in this day of really large hard drives, it might not be an issue.) Note that if you elect not to purge the staging directory every night, you will need even more space.
You should create a collect directory, a staging directory and a working (temporary) directory. One recommended layout is this:
/opt/ backup/ collect/ stage/ 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
.
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 cron job. For more information on using cron, see the manpage for crontab(5).
Backing up large directories and creating ISO CD 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 run 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 either the next week, or until you
re-run the backup using the --full
flag.
Since Cedar Backup should be run as root, one way to configure the
cron job is to add a line like this to your
/etc/crontab
file:
30 00 * * * root cback all
Or, you can create an executable script containing just these lines
and place that file in the /etc/cron.daily
directory:
#/bin/sh cback all
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.
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 “Single machine (pool of
one)” entry in the file, and change the line so that the
backup goes off when you want it to.
Following the instructions in the section called “Configuration File Format” (above) create a configuration file for your machine. Since you are working with a pool of one, you must configure all four action-specific sections: collect, stage, store and purge.
The usual location for the Cedar Backup config file is
/etc/cback.conf
. If you change the location,
make sure you edit your cronjobs (step 5) 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, such as invalid CD-R/CD-RW device entries.
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.
Place a valid CD-R or CD-RW disc in your drive, and then use the command cback --full all. You should execute this command as root. 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 and also mount
the CD-R or CD-RW disc to be sure it can be read.
If Cedar Backup ever completes “normally” but the disc that is created is not usable, please report this as a bug. [28] To be safe, always enable the consistency check option in the store configuration section.