David Lechnyr <davidrl % at % comcast % dot % net>
February 06, 2004
14:02:40
Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it. -- Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi
The TAO of Backup tells us that even the most insignificant file can take days to recreate by hand. Tape backup methods can be influenced by a variety of needs, including philosophical, political, and just plain common sense. Personally, I prefer something that isn't so complicated that I have to troubleshoot the backup method itself. And as once voiced by a HP technician acquaintance of mine, the backups are worthless if you haven't verified that they worked in the first place.
The most important concept with tape drives under Linux is rewinding and non-rewinding tape devices. Typically, /dev/st0 is your rewinding tape device, while /dev/nst0 is your non-rewinding tape device. If you are backing up only one filesystem, then the rewinding bit is a moot point. However, if you're backing up several filesystems, you don't want the tape drive to rewind each time it backs up a filesystem.
Always do full backups. Media is cheap nowadays, so incremental backups and other similiar schemes (Tower of Hanoi, and so forth) are just a prescription for a headache and a time machine in the case of a need to restore. Having a monthly "offline" backup of unmounted filesystems might not be a bad idea either, but a bit more complicated to orchestrate.
Dump examines files on an ext2/3 filesystem and determines which files need to be backed up. Either a mountpoint of a filesystem or a list of files and directories can be specified for backup. The target filesystem can be specified by its raw device name if it is unmounted (which is actually preferrable). The target is copied to the given disk, tape or other storage medium for safe keeping. A dump that is larger than the output medium is broken into multiple volumes.
Dump recognizes different levels of incremental backups in addition to performing a full backup. At one point in the past, incremental backups made sense for a variety of economic reasons. However the cost of media is low enough today to warrant the reduced headache of performing a full backup each and every time.
Unlike other backup programs, the script below doesn't try to do everything under the sun; it does one thing, and only one thing -- and it does it well. Dump is instructed to perform a level 0 full backup which guarantees the entire file system is copied (-0), to bypass all tape length calculations and write until an end-of-media indication is returned (-a), update the file /usr/local/etc/dumpdates after a successful dump (-u), abort the entire dump in the case of write errors rather than entering into an interactive prompt (-q), use 64 KB per dump record (-b 64), and write to the non-rewinding tape device (-f /dev/nst0).
#!/bin/shDEVICE="sda3 sda4 sda5"if ( ! mt -f /dev/nst0 rewind ) then
echo "No tape in drive." && exit 1
fi
for item in $DEVICE; do
mount /dev/$item -o remount,ro
dump -0auqb 64 -f /dev/nst0 /dev/$item
mount $item -o remount,rw
done
How do you know if one of your backup tapes has gone bad, or even if your backup contains the correct data? Verification. You must check the contents of your backup every now and then to make sure it's working properly. You could continue the above script with the following:
counter=0
for item in $DEVICE; do
let counter=counter+1
mt -f /dev/nst0 rewind
restore -Cyf /dev/nst0 -b 64 -s $counter
done
Regardless, having the tape eject after a successful backup is always a good
visual cue:
mt -f $TAPE offline
Your backup will produce some output, which if run from a cron job, should be e-mailed to you. Turning this off would be considered a "bad thing" as you'll never know if things don't work as expected. The output should look like the following:
DUMP: Date of this level 0 dump: Wed Oct 23 03:00:01 2002
DUMP: Dumping /dev/sda3 (/home) to /dev/nst0
DUMP: Added inode 8 to
exclude list (journal inode)
DUMP: Added inode 7 to exclude list (resize
inode)
DUMP: Label: sdd1
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 12867857 tape
blocks.
DUMP: Volume 1 started with block 1 at: Wed Oct 23 03:00:10 2002
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV)
[regular files]
DUMP: 6.87% done at 2937 kB/s, finished in 1:07
DUMP:
13.55% done at 2902 kB/s, finished in 1:03
DUMP: 21.23% done at 3032 kB/s,
finished in 0:55
DUMP: 28.07% done at 3004 kB/s, finished in 0:51
DUMP: 34.36% done at 2944 kB/s, finished in 0:47
DUMP: 41.01% done at
2928 kB/s, finished in 0:43
DUMP: 47.78% done at 2924 kB/s, finished in
0:38
DUMP: 54.79% done at 2935 kB/s, finished in 0:33
DUMP: 62.31%
done at 2967 kB/s, finished in 0:27
DUMP: 69.68% done at 2986 kB/s,
finished in 0:21
DUMP: 75.21% done at 2931 kB/s, finished in 0:18
DUMP: 81.32% done at 2905 kB/s, finished in 0:13
DUMP: 88.03% done at
2902 kB/s, finished in 0:08
DUMP: 93.01% done at 2848 kB/s, finished in
0:05
DUMP: 98.17% done at 2805 kB/s, finished in 0:01
DUMP: Closing
/dev/nst0
DUMP: Volume 1 completed at: Wed Oct 23 04:18:50 2002
DUMP:
Volume 1 13203008 tape blocks (12893.56MB)
DUMP: Volume 1 took 1:18:40
DUMP: Volume 1 transfer rate: 2797 kB/s
DUMP: 13203008 tape blocks
(12893.56MB) on 1 volume(s)
DUMP: finished in 4719 seconds, throughput
2797 kBytes/sec
And the compare-to-tape bit should look like this:
Dump date: Wed Oct 23 03:00:01 2002
Dumped from: the
epoch
Level 0 dump of /home on darkstar:/dev/sda3
Label: sda3
filesys = /home
Using cp(1), You can also back up all your files from one physical drive to another, since drive space is cheap. This (modified) command owes credit to the Hard Disk Upgrade mini-HOWTO by Yves Bellefeuille:
# mount /backup ; cd / && echo cp -fau `/bin/ls -1Ab | egrep -v "^backup$|^proc$"` /backup | sh
Restore command performs the
inverse function of dump. Single files, directory subtrees and entire
filesystems may be restored from full or partial backups. Note that restore can
get confused when doing incremental restores from dumps that were made on active
file systems. Because restore runs in user code, it has no control over inode
allocation; thus a full dump must be done after a full restore to get a new set
of directories reflecting the new inode numbering, even though the content of
the files is unchanged. Also, be aware that restore is written to run as setuid
root.
#!/bin/sh
mt -f /dev/st0 rewind
echo "Restore from which session number?"
read number
restore -ivf /dev/nst0 -b 64 -s $number
Copyright © 2003 David Lechnyr. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. A copy of the license is available at http://www.gnu.org/licenses/fdl.txt.