## Backup and restore a file system ##

[Author](authors.html): [[KevinDKinsey]]

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

----

### 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, but 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 ###

1.  Practice the operations above with a "test" machine.
2.  Can you create the proper command(s) for a solution with `tar`?
3.  What about `cpio`?

### More information ###

`dump(8), restore(8), dd(1)`
