[Home]  [Links]  [grouch] 

Back up that data!

Do it. Just do it. Sure, you can brag about your uptime and you leave documents open and in progress for a week at a time. But it's a computer. Something is waiting for you to be most vulnerable and complacent and then it will strike.

The question is still "when" will something go wrong, not "if". Hard drives can fail. Your power supply may reveal that it has a cheap fan with a sleeve bearing instead of the ball bearings you thought. It would probably be considerate and wait until you're away for a couple of days before it cooked. Maybe there's a marginal connection within those unknown thousands in a memory stick that finally goes bad, and your computer has the equivalent of a major stroke. Most likely is, you simply do something clever that turns out to be not so clever.

The most important parts of a system are those its users have created or customized. Most of the thousands of files on your system you can restore from your installation CD(s). If you have a fast and robust backup system then go ahead and backup the entire thing. But most of us have to be selective to keep backups within the practical limits of a CD writer or Zip drive or small tape drive.

Your /home/ directories should be backed up regularly and often. Don't forget the /root user. The /etc directory should be preserved since it contains many of the tweaks you've made to get your system the way you want it. Most likely your logs in /var/log are rotated by way of a cron job, but you should backup this directory to preserve those logs. My entire /var directory is about 42 MB. That's not too large to commit to CD or Zip. It's small enough that I just tar and zip the whole thing rather than grabbing individual directories within /var.

On a server system you'll automate all of the backup process through scripts, cron jobs, or programs. I find on a personal system that the cron job always manages to kick in just at the wrong time and the sudden high load interferes with what I'm doing. So I use a simple bash shell script, chmod 744 so only root can execute it, and run it when it suits me:

#!/bin/bash
# back it up, back it up
# This file should be saved as /root/backups or similar,
#  and be chmod 744 /root/backups

# the /opt directory is a little like /usr/local --
#  it catches 'stuff' for the local machine rather than network

cd /opt/backs

# Next, instead of a 'for-next', 'while', or regular expressions,
# I like to make a very simple list of the directories to be
# tarred and zipped. This is most likely insufficient for any
# system that has lots of users!

tar zvcf etc.tgz /etc   # (z)ip, (v)erbose, (c)reate, (f)ile
tar zvcf root.tgz /root
tar zvcf var.tgz /var
tar zvcf boot.tgz /boot

# Note that you could include datestamps in the filenames.
# I don't because my backup media is dated and I remove the
# files from /opt/backs after transferring to the backup media.
# Use what suits your needs and preferences.

# Next come the user directories. Again, you could use regular
# expressions to get these directory names, but for a small system
# a simple list (if updated!) works well and keeps the script
# very easy to read.
# Substitute _your_ users' names, of course. ;)

tar zvcf bonehead.tgz /home/bonehead
tar zvcf dimp.tgz /home/dimp
tar zvcf grunt.tgz /home/grunt
tar zvcf harvey.tgz /home/harvey
tar zvcf jackal.tgz /home/jackal
tar zvcf jdean.tgz /home/jdean

tar zvcf newguest.tgz /home/newguest
#  new, anonymous caller history
#  newguest has a restricted shell, but i still like to preserve
#  the contents of this directory

tar zvcf shaft.tgz /home/shaft
tar zvcf shebe.tgz /home/shebe

# end

Running that will produce individual tarred and gzipped files that allow quite a bit of flexibility in the way you store them. Just don't leave them on the same system they are supposed to preserve from calamity.

(The above script is extremely limited; it does just one task and requires manual maintenance. Ben Okopnik has written a series of articles for Linux Gazette on shell scripting. These cover bash in good depth and provide examples of generalized scripts that can be combined or modified for some very powerful tools. See http://www.linuxgazette.net look for issues 52 through 55).