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.
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 wellboth 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 directoryfind 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:
server1:~# rsync -av --exclude "/proc/" --exclude "/dev/" --exclude "/tmp/"
--exclude "/sys/" --exclude "/mnt/" --exclude "/media/" / admin@backup1:/backups/server1
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:
Any directories you wish to exclude must have the trailing slash. You may also exclude files by filetype using the usual shell wildcards. Then use the file in your rsync command like this:
server1:~# rsync -av --exclude-from=/etc/rsync-exclude / admin@backup1:/backups/server1
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 SSHit 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:
rsync -av --exclude-from=/etc/rsync-exclude / admin@backup1:/backups/server1
Then enter this line in /etc/crontab:
0 22 * * * root /usr/local/bin/backup.sh
This will run your backup script every night at 10pm.
This example shows how to copy a directory from the backup server:
server1:~# scp admin@backup1:/backups/server1/etc /etc
Don't use rsync; use whatever other copying method you prefer, because presumably you want the entire file and not just the rsync diffs.
man rsync is very helpful- don't be afraid!
The (Practically) Ultimate OpenSSH/Keychain Howto
Chapter 16: Backup and Recovery, the Linux Cookbook
Making secure remote backups with Rsync
VoIPowering Your Office: Backing Up the SipX Server