Welcome once again, one and all, to another installment of Sysadmin's Corner. We start this week by visiting another of those ugly topics no one likes to talk about ... your system backups. In the next few columns, I want to discuss backup strategies, tools, and ways to make the whole process a bit less unpleasant.

You can get pretty much anyone you ask to agree that backups are a good idea. You can also pretty much guarantee that no one does their backups as often as they should. While I won't name names, I've known a number of people over the years who (despite touting the benefits of regular backups) treat their important data with bad habits such as these:

Since there is no point in boring you with a list that goes on and on, I'll stop for now. Suffice to say that when the system crashes and data has to be recovered, it's always "important" data. So, what's the best way to protect that important data?

For a lot of people dealing with simple systems, the data that is our accounts, word processing documents, e-mails, is the only truly important part. In the world of that other operating system, most backups involved copying documents to a diskette. I know of one instance where a user had only a single diskette for all their important documents, because they were worried about the hard disk crashing! True story.

The problem with diskettes is that they hold only so much information. Backing up your whole system would take years (hours, anyway) and require sedation afterwards. Every system should have some kind of large storage capacity backup, like a tape drive. Network backups are possible if the device you need exists on some other machine, but that's a topic of its own.

Okay, I admit there are instances where you don't have a proper backup device and you need solutions. For instance ...

A number of people have taken advantage of Linux's powerful network tools and masquerading (not to mention price) to create simple mail servers and Internet gateways for the company. The company gave you this machine, because nobody else was using it and you told them Linux works for sardines. This machine is an old 486 with a 2-speed CD-ROM and no tape drive. You asked for one, but your insistence that Linux would cost them nothing and give them the world made you break one of the cardinal rules and cut corners on backups.

On this server of yours, you are probably running diald, fetchmail, IP masquerading and e-mail. Not particularly complex, and the data (the e-mail) gets transferred to the user PCs anyway. Not much to worry about there, right? Keep in mind though, that it took you several hours to properly tweak this machine, and to get just the right settings for dialing out and connecting to your ISP. Sure, Linux is stable as can be, but disks crash. You can reinstall Linux from the CD-ROM in minutes, but getting everything just right might take a little longer than that and users want their e-mail and Internet access yesterday.

It's a good idea to have everything, but everything is not always a requirement. Since this type of system is essentially the sum total of its configuration files, you can do what I call an identity backup. This script will collect all the files that make your put-together server unique among all other put-together servers. Here's what it looks like.

   #!/bin/bash
   #
   # Identity backup for Linux systems
   # This script does a backup of important files 
   # Marcel Gagne, 2000
   #
   clear
   echo "Identity backup for Linux systems"
   echo "2000: Salmar Consulting Inc."
   echo ""
   #
   echo "Please enter a directory name for temporary image storage."
   echo "ie: /data1/PROTECT"
   #
   read PROTECT_dir
   #
   #####################################################
   # Start by copying config files in etc
   mkdir -p $PROTECT_dir/etc/rc.d
   mkdir $PROTECT_dir/root
   mkdir -p $PROTECT_dir/usr/local/.Admin
   
   cd /etc
   for file_names in passwd group shadow profile bashrc sendmail.cw          
   sendmail.cf hosts hosts.allow hosts.deny named.conf named.boot 
   hosts.lpd diald.conf aliases
   do
       cp $file_names $PROTECT_dir/etc
   done
   find nsdata -print | cpio -pduvm $PROTECT_dir/etc
   find ppp -print | cpio -pduvm $PROTECT_dir/etc
   find sysconfig -print | cpio -pduvm $PROTECT_dir/etc
   cp rc.d/rc.local $PROTECT_dir/etc/rc.d
   #
   cd /
   cp /root/.fetchmailrc $PROTECT_dir/root
   find usr/local/.Admin -print | cpio -pduvm $PROTECT_dir/usr

The basics are this. After obtaining a temporary backup directory, I make the structure by creating the directory hierarchy that I want to recreate. (Using the -p flag on mkdir, I can save myself a few keystrokes and create the entire subdirectory I need in one pass.)

I often save little admin scripts to a directory called /usr/local/.Admin as is the case with this one. Consequently, in the script, I make sure to back up that directory as part of my identity backup. If you want to use a different directory, make sure you take this into consideration. After writing the script, I make it script-executable and run it:

   # chmod 700 /usr/local/.Admin/identity_backup
   # /usr/local/.Admin/identity_backup

When the script runs, I give it a directory name on my server. Something I use pretty regularly is /data1/PROTECT or /something/PROTECT but you can use anything that makes sense, making sure, of course, that the filesystem you copy to has enough disk space. What I wind up with here is a kind of configuration "mirror" of my system. I can quickly pull back the files I need from a copy of the structure that originally existed.

This list of backed-up items is by no means complete. I am taking the bare minimum files and configurations to recreate a functional system as quickly as possible, should disaster strike. Now that we have this quick-identity snapshot, what should we do with it? If you created your PROTECT_dir in /data1, you would do the following:

   # cd /data1
   # tar -czvf hostname.identity.tar PROTECT_dir

This will create a tarred and gzipped file of your system configuration. The next step is to get it off the system and put it somewhere safe. If the file is small enough (as is sometimes the case), you can save it to a floppy. In fact, you could tar the whole thing to a floppy and save yourself a step. Alternatively, you can ftp the file to another server, a Windows PC, or (if you are a sys admin working remotely) to your own server. A few minutes ago, I tested the script as you see it on a remote Linux system that acts as a corporate e-mail/Internet gateway. The resulting file was about 35 kilobytes. You can store an awful lot of those on your own system.

If you wanted to extract this "identity" to your local system, you might do something like this:

   # mkdir -p /home/remote_servers/hostname
   # cd /home/remote_servers/hostname
   # tar -xzvf hostname.identity.tar.gz

There you have it! A copy of what makes that system unique, but saved someplace other than the server itself.

Warning! This is not an all-encompassing answer to backups. For that, we need to discuss other ways of looking at your system, your data, and how you store it. That is the kind of country where I intend to take this series.

And so, we wrap up another week. Until we chat again, remember that when you're down, only a good backup will get you back up.