VoIPowering Your Office: Backing Up Your Linux Server

We've had fun running SipX, Asterisk, and AstLinux, with a few short side trips into Linux system administration. Today we're going to learn how to back up and restore a Linux server using rsync. Don't forget to test both backing up and restoring your data on a regular basis!

Most Linux files can be backed up by simply copying them; the exception is databases. These cannot be backed up by copying the files; they usually come with their own special dump and restore commands, so you must use these. SipX provides one-button backups of configuration data and its PostgreSQL database.

Rsync
The rsync command is a the backup tool of choice for many Linux server admins. It's reliable, efficient, fast, and it comes with all Linuxes. It may not be installed, so check that first. Then make sure you have OpenSSH installed as wellboth client and server. You'll need rsync and the OpenSSH client on all machines that will be sending backups to the rsync server, because rsync uses SSH to encrypt and authenticate all network traffic.

A typical strategy is to set up a central network rsync backup server.
Then the backup server is mirrored at a remote location, also with rsync,
so the backups are backed up offsite. It's easy to schedule regular automatic
rsync runs using cron, so you can set it and forget it. Well,
not really forget; but it doesn't need a lot of babysitting, just routine checks
to make sure everything is still working correctly. Your first rsync
backup will take the longest. After that it's fast, because it transfers only
changes.

This is the simplest invocation for backing up an entire system. The local machine is server1, and the rsync server is backup1:

server1:~# rsync -av / admin@backup1:/backups/server1

This copies the entire root directory (/) on server1 to the /backups/server1 folder on backup1. The -a, or "archive" option, preserves the original file permissions and timestamps. -v is verbose; omit this if you don't need a running commentary on the progress of your backup. You can also try the -z flag, which turns on compression. This won't do anything for files that are already compressed, like .jpg or .tar files, but it will speed up most backups.

While you're testing and getting the hang of rsync, don't use the whole root directoryfind a directory with a few files in it to play with. Use the -n, or "dry-run" option combined with -vvv. This lets you see what will happen without actually doing anything.

Some directories should not be backed up, like network shares, mounted removable media, /proc, /sys, /dev, and /tmp. You may put these on the command line, like this:

This should be one unbroken line, not two lines as it appears here. This is a bit cumbersome; you can streamline it by putting your exclusions into a separate file. In this example it is called /etc/rsync-exclude. Enter one option per line:

Automating rsync backups
Once you have your file selection fine-tuned and are more comfortable with rsync,
you can script it and plop the script into either a crontab, or the file /etc/crontab
to run it automatically on a schedule. The one hitch in this lovely scheme is
SSHit will ask for a login and password. To get around this you must set
up SSH to authenticate via an encryption key, instead of a system login. (See
Resources for an excellent how-to.) This gives you two options: The first is
to use a passphrase-less SSH key, which presents some obvious security weaknesses,
but it is a common option. The second is to use a password-protected key and
use keychain or ssh-agent to handle the SSH authentication for
you. The downside to this solution is that such passwords do not survive reboots.

If you elect to set up keychain, which is is my preferred option, then you can script rsync like this: