Automate configuration backups with subversion

Vincent Danen explains how subversion can be used to keep track of revisions to configuration files.

Backups are important, and incremental backups work even better because you can refer to or retrieve early copies of important files you may have changed, such as a configuration file that you realized broke something else a week later. However, unless you keep, and never delete, the incremental archive, you'll run into a situation where your last backup file isn't the file you needed. If it's a copy of the current configuration file, but not the previous "revision," you may not be able to revert the changes you made without, perhaps, some significant effort.

Subversion, while being a great developer's tool, is also a fantastic sysadmin's tool in that you can use subversion seamlessly to keep track of revisions to configuration files automatically.

The basic steps to create a single-host subversion repository quickly would be to execute the following, as root, on the host for which you'd like to keep /etc in subversion:

# mkdir -p /root/subversion/copy
# svnadmin create /root/subversion/repos
# cd ~/subversion/copy
# rsync -a /etc .
# svn import etc file:///root/subversion/repos -m "initial import"
# rm -rf etc
# svn co file:///root/subversion/repos etc

When this is complete, you will have a current snapshot of your /etc directory in a local subversion repository with a copy available in /root/subversion/copy/etc.

Next, place the bash script in Listing A into a file named /root/subversion/copy/backup:

What this script does is use rsync to copy /etc to our "scratch" copy in /root/subversion/copy; then it executes the svn status command to see if there have been any changes. If there are no changes, the script silently exits; however, if there are changes, it parses the output of the svn status command and adds files that don't already exist in the repository, and removes files that have been deleted. Once this is done, the svn commit command is called with a generic log message. The commit will do the actual removal and addition of files that were either deleted or added, and will also merge in any changes made to existing files. An example run of the above script might look like:

 [root@host copy]# ./backup
The following changes were made to /etc:
M      exim/exim.conf
Sending        exim/exim.conf
Transmitting file data .
Committed revision 2.

At this point, you can use the standard subversion commands such as log, diff, and so forth in the scratch copy, and copying any files back to the main /etc directory should it be required. If you do check out an older revision and replace the copy in the main /etc directory, it will get automatically committed again as a new revision.

This script is most useful for an automated daily "snapshot" of the /etc directory, so a cronjob should exist to execute it on a daily basis. It's a simple but effective script that could easily be extended to have a central "subversion backup host" for a networked system to keep up-to-date copies (and histories) of configuration files for any number of machines. It is also easy enough to duplicate the script to handle directories other than just /etc.

Delivered each Tuesday, TechRepublic's free Linux NetNote provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!