This is the BSDA Study Guide Book written via a
This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Backup_and_restore_a_file_system.html.
Backup and restore a file system
Recognize the utilities used to backup an entire filesystem and the various dump(1) levels.
Type "data loss statistics" into a search engine and you will receive a wide variety of results. Here are some current claims:
- "6% of all PCs will suffer an episode of data loss in any given year"
- "U.S. businesses loose [sic] over $12 billion per year because of data loss."
- "60% of companies that lose their data close down within 6 months of the disaster."
It is difficult to easily verify these claims, one thing is certain: if your system's data is lost, you can find yourself in a lot of trouble. Perhaps you will have to spend extra time restoring lost configuration files and data (if it is available!) You may have to pay significant overtime to data entry personnel to restore a database. Your company could be adversely affected ... you might lose your employer's trust, or even your job.
One thing is fairly certain, even if we "manufacture" the claim: you can be sure that anyone who loses data and has a backup of that data is much happier that anyone who loses data and has no backup. And yet, talk to a sampling of small-to-medium businesspeople about backups - you will see more than a few shrugs, floor-stares, blank stares, or heads hung in shame.
A complete "disaster recovery plan" is beyond the scope of this book, or your responsibility as a junior sysadmin. But you should definitely know how to backup and restore file systems ... a critical part of any recovery plan. Ask your senior administrator to see the relevant portions of your company's "disaster recovery plan". If he doesn't get back to you soon, ask him how you might help in creating one!!!
Various Options for Backup
There are many options for data backup - just as there are many companies who put statistics about data loss on their websites. You might:
cpio(1) everything to another location
- burn data to a optical media
dd(1) to "clone" a filesystem
- backup important files to floppy disk (well not MUCH data - many people now use a flash memory device instead.)
- Use a fine 3rd party program (AMANDA, Veritas, Bacula, rsync and others)
However, the canonical, reliable, quick, and portable (available on every BSD system) backup program is
dump(8). Its "partner" is
Dump was designed to backup UNIX and UNIX-like systems to tape drive quickly and efficiently.
Dump is fast, writes to a variety of media, works on live filesystems, does incremental backups, already know tons about your filesystem(s), and has a host of other options to make it work in almost every situation.
I'm not trying to tell you that you can't use other programs for your backups, but I am telling you that for this book, we're going to use
dump. Make backups regularly and often! You will someday be very glad that you did.
For the full "dump" on
dump, see the manpage. Here are some things your should remember about
Dump has ten "levels" of backup (0-9).
- A level zero
'dump -0') will backup all files on a filesystem.
- A higher level
dump will only backup files changed since the last
dump of a lower level.
- Level zero is the default.
Unless a filesystem is unmounted or mounted read-only, you should tell
dump that the filesystem is live ('-L').
Dump will then make a snapshot of the filesystem and "dump" the snapshot (so that any activity on the drive doesn't break the "dump").
You must specify which filesystem you want to
dump, either by its mount-point name (e.g.
/usr), or by its device name (e.g.
Finally, by default
dump writes to a tape drive
(/dev/sa0). By using the '-f' option to
dump, you may have
dump write its output to another file, a special device, or even the standard output.
For information on
dump's other options, including tape size and density specifications, blocksize for the
dump, auto-sizing of output, operator notifications, estimation of tape requirements, manipulation of the dumpdate data and other features as well as environment variables that affect
dump, see the
Restore(8) is used to turn a "dump" back into usable data. The general format of the
restore command is as follows:
# restore [-flag] [-options]
To rebuild a file system, the
-r option is generally used.
Restore is generally used on a "pristine" file system (one that has been recently 'formatted' with
newfs(8)), and a level zero
dump must be restored prior to any incremental dumps. Change to the target directory before beginning the restore procedure.
Note that this is a rather abbreviated discussion of
restore; refer to their manual pages and the examples below for more information. Finally, be advised that you should be running as root to
restore entire filesystems.
dd(1), cp(1) and other alternatives
dd(1) is a simple program to copy from standard input to standard output.
cp(1) is used frequently by almost anyone who uses a BSD system. Because of the familiarity and relative ease of use of some of these programs, some people may use them as backup tools. Of course, it is the primary system administrator to decide what to use; gathering evidence and research to assist in this decision should also be part of a complete disaster recovery plan.
Dump a mounted /usr to primary tape drive:
#* dump -L /usr*
Dump /var to a file named "var.dmp":
#* dump -L /var -f /backup/var.dmp*
Restore from tape (/dev/sa0) to a new filesystem on /mnt:
#* cd /mnt; restore -rf /dev/sa0*
Assume "/newusr" is a new/clean filesystem with appropriate space; here's how to restore a dump file from /backup/usr.dmp:
#* cd /newusr; restore -ruf /backup/usr.dmp*
Here's a simple script using
dump piped to
restore as a "quick and dirty" backup solution in a machine with multiple drives. We have a root partition, /var and /usr, and 3 same-sized "bak" (backup) partitions on another disk:
/bin/chflags -R noschg /rootbak/* /varbak/* /usrbak/*
/bin/rm -rf /rootbak/* /varbak/* /usrbak/*
/sbin/dump -0 -a -L -u -f - / | ( cd /rootbak ; /sbin/restore -ruf - )
/sbin/dump -0 -a -L -u -f - /var | ( cd /varbak ; /sbin/restore -ruf - )
/sbin/dump -0 -a -L -u -f - /usr | ( cd /usrbak ; /sbin/restore -ruf - )
Note that this isn't a good substitute for a complete backup plan; it would only protect you in the event that your first disk failed (and, if this is a problem, you should perhaps consider a RAID setup, but that's beyond our scope here) and not from theft of the system or natural disasters, etc. If the "bak" directories were on a remote host, it might be more helpful, but there could be performance and security issues over a network to a truly "remote" machine.
cp to "back up" my homedir (-R is recursive, -p preserves ownership and mode data):
$cd ~ && cp -Rp * /mybackuplocation/
dd to slowly "clone" a drive block-for-block (set the optional
bs blocksize argument to increase speed):
#dd if=/dev/ad0 of=/dev/ad1
Note that it's probably best if the drives are identical for this usage. In the example above, if
ad1 is smaller than the source disk, you will not get a complete 'clone'. If
ad1 is larger, at the very least you will have wasted space.
- Practice the operations above with a "test" machine.
- Can you create the proper command(s) for a solution with
- What about
dump(8), restore(8), dd(1)