Product SiteDocumentation Site

9.10. Backup

Making backups is one of the main responsibilities of any administrator, but it is a complex subject, involving powerful tools which are often difficult to master.
Many programs exist, such as amanda, bacula, BackupPC. Those are client/server system featuring many options, whose configuration is rather difficult. Some of them provide user-friendly web interfaces to mitigate this. But Debian contains dozens of other backup software covering all possible use cases, as you can easily confirm with apt-cache search backup.
Rather than detailing some of them, this section will present the thoughts of the Falcot Corp administrators when they defined their backup strategy.
At Falcot Corp, backups have two goals: recovering erroneously deleted files, and quickly restoring any computer (server or desktop) whose hard drive has failed.

9.10.1. Backing Up with rsync

Backups on tape having been deemed too slow and costly, data will be backed up on hard drives on a dedicated server, on which the use of software RAID (see Odjeljak 12.1.1, “Software RAID”) will protect the data from hard drive failure. Desktop computers are not backed up individually, but users are advised that their personal account on their department's file server will be backed up. The rsync command (from the package of the same name) is used daily to back up these different servers.
The available hard drive space prohibits implementation of a complete daily backup. As such, the rsync command is preceded by a duplication of the content of the previous backup with hard links, which prevents usage of too much hard drive space. The rsync process then only replaces files that have been modified since the last backup. With this mechanism a great number of backups can be kept in a small amount of space. Since all backups are immediately available and accessible (for example, in different directories of a given share on the network), you can quickly make comparisons between two given dates.
This backup mechanism is easily implemented with the dirvish program. It uses a backup storage space (“bank” in its vocabulary) in which it places timestamped copies of sets of backup files (these sets are called “vaults” in the dirvish documentation).
The main configuration is in the /etc/dirvish/master.conf file. It defines the location of the backup storage space, the list of “vaults” to manage, and default values for expiration of the backups. The rest of the configuration is located in the bank/vault/dirvish/default.conf files and contains the specific configuration for the corresponding set of files.

Primjer 9.3. The /etc/dirvish/master.conf file

    root    22:00
expire-default: +15 days
    *   *     *   *         1    +3 months
    *   *     1-7 *         1    +1 year
    *   *     1-7 1,4,7,10  1
The bank setting indicates the directory in which the backups are stored. The exclude setting allows you to indicate files (or file types) to exclude from the backup. The Runall is a list of file sets to backup with a time-stamp for each set, which allows you to assign the correct date to the copy, in case the backup is not triggered at precisely the assigned time. You have to indicate a time just before the actual execution time (which is, by default, 10:04 pm in Debian, according to /etc/cron.d/dirvish). Finally, the expire-default and expire-rule settings define the expiration policy for backups. The above example keeps forever backups that are generated on the first Sunday of each quarter, deletes after one year those from the first Sunday of each month, and after 3 months those from other Sundays. Other daily backups are kept for 15 days. The order of the rules does matter, Dirvish uses the last matching rule, or the expire-default one if no other expire-rule matches.

Primjer 9.4. The /backup/root/dirvish/default.conf file

tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
The above example specifies the set of files to back up: these are files on the machine (for local data backup, simply specify the name of the local machine as indicated by hostname), especially those in the root tree (tree: /), except those listed in exclude. The backup will be limited to the contents of one filesystem (xdev: 1). It will not include files from other mount points. An index of saved files will be generated (index: gzip), and the image will be named according to the current date (image-default: %Y%m%d).
There are many options available, all documented in the dirvish.conf(5) manual page. Once these configuration files are setup, you have to initialize each file set with the dirvish --vault vault --init command. From there on the daily invocation of dirvish-runall will automatically create a new backup copy just after having deleted those that expired.

9.10.2. Restoring Machines without Backups

Desktop computers, which are not backed up, will be easy to reinstall from custom DVD-ROMs prepared with Simple-CDD (see Odjeljak 12.3.3, “Simple-CDD: The All-In-One Solution”). Since this performs an installation from scratch, it loses any customization that can have been made after the initial installation. This is fine since the systems are all hooked to a central LDAP directory for accounts and most desktop applications are preconfigured thanks to dconf (see Odjeljak 13.3.1, “GNOME” for more information about this).
The Falcot Corp administrators are aware of the limits in their backup policy. Since they can't protect the backup server as well as a tape in a fireproof safe, they have installed it in a separate room so that a disaster such as a fire in the server room won't destroy backups along with everything else. Furthermore, they do an incremental backup on DVD-ROM once per week — only files that have been modified since the last backup are included.