4. Creating the Stage 1 Back Up

Having made your production backups, you need to preserve your partition information so that you can rebuild your partitions.

The script make.fdisk scans a hard drive for partition information, and saves it in three files. The first is an executable script, called make.dev.x (where "x" is the name of the device file, e.g. hda). Second is mount.dev.x, which creates mount points and mounts the newly created partitions on them. The last, dev.x, is the commands necessary for fdisk to build the partitions. You specify which hard drive you want to build scripts for (and thus the file names) by naming the associated device file as the argument to make.fdisk. For example, on a typical IDE system,

bash# make.fdisk /dev/hda

spits out the scripts make.dev.hda, mount.dev.hda and the input file for fdisk, dev.hda.

In addition, if make.fdisk encounters a FAT partition, it preserves the partition's boot sector in a file named dev.xy, where x is the drive's device name (e.g. sdc, hda) and y is the partition number. The boot sector is the first sector, 512 bytes, of the partition. This sector is restored at the same time the partitions are rebuilt, in the script make.dev.hda

Fortunately, the price of hard drives is plummeting almost as fast as the public's trust in politicians after an election. So it is good that the output files are text, and allow hand editing. Right now, that's the only way to rebuild on a larger replacement drive. (See the To Do list.)

Other metadata are preserved in the script save.metadata. The script saves the partition information in the file fdisk.hda in the root of the ZIP disk. It is a good idea to print this file and your /etc/fstab so that you have hard copy should you ever have to restore the partition data manually. You can save a tree by toggling between two virtual consoles, running fdisk in one and catting /etc/fstab or /fdisk.hda as needed. However, doing so is error prone.

You will also want to preserve files relevant to your restoration method. For example, if you use nfs to save your data, you will need to preserve hosts.allow, hosts.deny, exports, etc. Also, if you are using any network-backed restoration process, such as Amanda or Quick Restore, you will need to preserve networking files like HOSTNAME, hosts, etc. and the relevant software tree.

The simplest way to handle these and similar questions is to preserve the entire etc directory.

There is no way a 100 MB ZIP drive is going to hold a server installation of a modern distribution of Linux. We have to be much more selective than simply preserving the whole kazoo. What files do we need?

• The boot directory.

• The /etc directory and subdirectories.

• Directories needed at boot time.

• Device files in /dev.

To determine the directories needed at boot, we look at the boot initialization file /etc/rc.sysinit. It sets its own path like so:

PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

Trial and error indicated that we needed some other directories as well, such as /dev. In Linux, you can't do much without device files.

In reading the script save.metadata, note that we aren't necessarily saving files that are called with absolute paths.

We may require several iterations of back up, test the bare metal restore, re-install from CD and try again, before we have a working backup script. While I worked on this HOWTO, I made five such iterations before I had a successful restoration. That is one reason why it is essential to use scripts whenever possible. Test thoroughly!

One thing you can do on an RPM based system is use the rpm program to determine which files are where. For example, to get a complete list of the files used by the openssh package, run:

bash# rpm -ql openssh

There are somethings you don't need. like the man pages. You can inspect each one and decide whether to back it up or not.

crunch etc etc --exclude etc/samba --exclude X11