Simplifying backups

Most computer users don’t make use of a system backup tool until after they suffer the misfortunes of a hard drive crash without one. But even then, many find backup software too complicated to configure, and there seems to be little in between creating CD or DVD archives by hand and overpowered network backup systems designed for the enterprise. The Simple Backup Suite (sbackup) is a tool for configuring regular backups of system data and simplifying full and partial recoveries.

A product of Google’s 2005 Summer of Code, sbackup is a set of Python scripts accessible through a graphical interface. The current release is available as an architecture-independent .deb package or a tarball, and will install two GUI tools, simple-backup-config and simple-restore-gnome.

The simple-backup-config tool allows users to choose either a simple backup scheme that performs incremental backups daily and full backups weekly, or to modify the default scheme with their own settings. Users list directories to backup in the Include tab, and select items to exclude in the Exclude tab. Exclusions can be based on directory (e.g., /var/cache), file type (sbackup excludes multimedia files by default), file size (10MB is the default upper limit), or regular expression.

The Destination tab specifies where to store the completed backup “snapshot.” The default is the /var/backup directory, but any directory is acceptable — including remote hosts reachable via SSH or FTP. The Time tab allows control over both the frequency and start time of backup jobs. You can also set a full backup “trigger” time; sbackup does incremental backups on each run if a full backup job is not triggered. By default, sbackup schedules daily incremental backups at midnight, and a full backup once every seven days.

Running a backup from simple-backup-config – click to enlarge

You can execute a backup immediately from within simple-backup-config, but to schedule regular backups according to the selections made, you must hit the Save button. This saves a configuration file to /etc/sbackup.conf and schedules your backups with cron in /etc/cron.d/sbackup. Making a full backup could take hours, depending on the amount of data, but the big advantage of scheduling the task with cron is that you can set up the rules once and count on them being done even if you forget about them.

Restoration

Each backup “snapshot” consists of a directory created in /var/backup or your substitute location. The directory is named according to its creation date and time, and for full backups contains six files:

• files.tgz — the archived data itself
• flist — a listing of the original names of the archived files
• fprops — a listing of the archived files’ permissions, ownership, and timestamps
• excludes — an index of the excluded filetypes
• packages — an index of programs installed on the system
• ver — a record indicating the version of the snapshot

Incremental backups contain a seventh file, base, containing the name of the previous full backup against which the incremental changes were measured. These text files serve as fast caches of the archived data in the restoration process. They allow users to browse the contents of an archive without the overhead of processing it all through tar and gunzip. The packages file is not used by sbackup itself, but can be used by package-management apps like dpkg to reinstall a crashed system to its original state.

Restoring files from a snapsnot with simple-restore-gnome – click to enlarge

To recover a file or directory, launch the simple-restore-gnome tool from a terminal window, or in GNOME choose “Simple Backup Restore” (note the difference in names) from the System -> Administration menu. You can choose which snapshot to read from via a drop-down menu, and select any or all of the files from that snapshot to restore.

Backin’ it on up

The Achilles’ heel of most home users’ backup strategy is that they don’t have one. As with insurance, you start off thinking that you will never need it, and learning the hard way that you do is expensive and time-consuming.

Sbackup is not a replacement for full-blown backup management systems like Amanda or Mondo Rescue. It does not perform advanced tasks like encryption or database or CVS backup, and since it must installed client-side on each machine it cannot function as a centralized backup system for multiple machines. But what it does do it does very well, and very simply. The default strategy is an excellent choice; the only changes I made to it on my own system were some additional includes and excludes.

In keeping with the simplicity of the backup strategy, the current release of sbackup defaults to storing snapshots in a mounted filesystem. Thus to safeguard your system against hardware failure, fire, or other catastrophic events, you will have to copy your backups onto removable media by hand, or else take advantage of the remote server options.

Fortunately all sbackup snapshots are self-contained and completely portable. Sbackup creator Aigars Mahinovs says that CD/DVD-burning support is still on the to-do list before the program is deemed feature-complete, but had to be cut in order to reach the Summer of Code deadline.

I tested sbackup with a FUSE-mounted remote filesystem, and it worked flawlessly as expected. So, depending on your expertise with FUSE, you can add additional feature workarounds (such as encryption) at the filesystem level.

Finally, it is important to note that the sbackup Summer of Code project was mentored by Ubuntu Linux, and as a result makes some assumptions about the system that may not be true for non-Debian-based installations. Also, the GUI tools are written for the GNOME desktop environment, though that does not preclude their use in KDE, XFCE, or other environments.