|
This is the BSDA Study Guide Book written via a
wiki collaboration.
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
Concept
Recognize the utilities used to backup an entire filesystem and the various dump(1) levels.
Introduction
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:
cp(1) or scp(1) or cpio(1) everything to another location- burn data to a optical media
- use
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 restore(8). 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.
About dump(8)
For the full "dump" on dump, see the manpage. Here are some things your should remember about dump:
Dump has ten "levels" of backup (0-9).
- A level zero
dump ('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. /dev/ad1s1a). 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 dump(8) manpage.
About restore(8)
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 dump and restore; refer to their manual pages and the examples below for more information. Finally, be advised that you should be running as root to dump and 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.
Examples
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/sh
/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.
Use cp to "back up" my homedir (-R is recursive, -p preserves ownership and mode data):
$cd ~ && cp -Rp * /mybackuplocation/
Use 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 Exercises
- Practice the operations above with a "test" machine.
- Can you create the proper command(s) for a solution with
tar?
- What about
cpio?
More information
dump(8), restore(8), dd(1)
|