I mentioned:
> For example, at work, my backup scripts have an option to read the
> contents from the tape. Both tar and cpio have to re-read the entire
> archive to produce this, so I can be pretty sure that the entire
> archive is readable.
Will McCorkle wrote:
> James, I would really like to see the script(s) you mention below if it
> would not compromise you in any way.
Well, the backup system I use at work is a whole series of scripts
flying in close formation across two machines[1]. They have to back up a
Progress database and keep a usable copy on a spare server, and they
rely a lot on how I've got things set up. So the whole system wouldn't
be of much help.
They're also designed *not* to use clever scripting tricks as much as
possible, so other people can understand them as easily as possible. So
they use temporary files instead of subprocesses, for example.
The core of the backup routine, though, is a simple series of finds:
cd /
find home -xdev > $tempfile
find data/backup -xdev >> $tempfile
find . -xdev >> $tempfile
et cetera, followed by a
cpio -ocBv < $tempfile > /dev/rmt0
While I'm at it, points to note:
* I carefully start the finds in the / directory, and don't specify
leading slashes. This makes sure that there aren't any leading
slashes in the filenames stored on tape: they're stored as
home/jamesw/whatever, which means I can easily restore them to
scratch space if I don't want to overwrite the existing copy of the
file. GNU tar will deliberately drop leading slashes for just this
reason: Unix cpio doesn't.
* I use cpio because that's what the firm has always run and I see no
reason to switch. Besides, it keeps me up to speed on cpio.
* I use the series of finds to ensure I get the files onto tape in
the order I want. Usually, when I'm asked to restore one file, it's
from /home, so it's a good idea to have that at the beginning of
tape where I can get it back within ten minutes. Next comes the
backup of the company's main database (= £££). Stuff in /usr goes
last, so if the backup fails or gets too large, the data that can
be replaced the most easily is most likely to be lost. [2]
* The -xdev prevents the find from crossing filesystems. It *shouldn't*
make a difference except for /, but that's the sort of assumption
that can break with dire consequences.
* The main databases need Progress-specific backup tools (or to be shut
down during backup, which isn't acceptable), and there are training
databases replicated from the main ones that don't need backup. So
no, I don't want to backup the entire machine.
The core of the tape check routine is even simpler:
cpio -itvBc < /dev/rmt0 > `date +%d%m%y`
I don't always run this, and when I do, I run it separately from cron.
It provides a dated file with all the files that the tape thinks it
contains. As I understand it, this means that the drive has read (and
presumably checksummed) the data inbetween the file names (i.e. the
files themselves). When I've had a failing tape, the script certainly
hasn't listed files beyond the failure point.
Incidentally, doing a diff against $tempfile, above, isn't necessarily
useful: files in /var, for example, may be found by find but be gone by
the time cpio gets there. This is normal, understandable, not a problem,
and is reported by the cpio that writes the backup in the first place.
So I just check that the last file (which is always the same) is there.
There's *always* scope for other things to go wrong, and I really should
run this more often on another machine. Tape drives can go out of
alignment, so they create tapes that they can reliably read, but nothing
else can. I've even heard of SCSI faults that inverted certain bits on
read and write, so backups got mangled on the way to tape and unmangled
on the way out...
Hope this helps,
James.
[1] OK, they run AIX, not Linux, but the scripts don't care about that.
[2] AIX runs on machines designed to run AIX. One benefit of this is
that AIX can make a bootable backup tape (a mksysb) that contains
everything on the root volume group (everything but the database and
scratch disks). And /usr should be identical to how it was at the
last mksysb. So I can just restore a mksysb, if necessary, to get the
machine booting, then overlay data from a cpio backup as needed.
--
E-mail address: james | The Loch Ness Monster is not, in fact, a plesiosaur
@westexe.demon.co.uk | or a brontosaurus or any other saurian silliness. That
| would be ridiculous. Dinosaurs are extinct.
| Obviously it's a dodo. -- Ursula Vernon
