2. Overview
The process shown below is not easy, and can be hazardous to your data. Practice it before you need it! Do as I did, and practice on a sacrificial computer!
The target computer for this HOWTO is a Pentium computer with a Red Hat 7.1 Linux server or workstation installation on one IDE hard drive. The target computer does not have vast amounts of data because the computer was set up as a "sacrificial" test bed. That is, I did not want to test this process with a production computer and production data. Also, I did a fresh installation before I started the testing so that I could always re-install if I needed to revert to a known configuration.
 | NOTE |
|---|---|
The sample commands will show, in most cases, what I had to type to recover the target system. You may have to use similar commands, but with different parameters. It is up to you to be sure you duplicate your setup, and not the test computer's setup. |
The basic procedure is set out in W. Curtis Preston, Unix Backup & Recovery, O'Reilly & Associates, 1999, which I have favorably reviewed in Linux Journal. However, the book is a bit thin on specific, real-time questions. For example, exactly which files do you back up? What metadata do you need to preserve, and how?
Before beginning the process set forth in this HOWTO you will need to back up your system with a typical backup tool such as Amanda, BRU™, tar, Arkeia® or cpio. The question, then, is how to get from toasted hardware to the point where you can run the restoration tool that will restore your data.
Users of Red Hat Package Manager (RPM) based Linux distributions should also save RPM metadata as part of their normal backups. Something like:
bash# rpm -Va > /etc/rpmVa.txt |
in your backup script will give you a basis for comparison after a bare metal restoration.
To get to this point, you need to have:
Your hardware up and running again, with replacement components as needed. The BIOS should be correctly configured, including time and date, and hard drive parameters. At the moment, there is no provision for using a different hard drive.
A parallel port Iomega® ZIP® drive or equivalent. You will need at least 30 MB of space.
Your backup media.
A minimal Linux system that will allow you to run the restoration software.
To get there, you need at least two stages of backup, and possibly three. Exactly what you back up and in which stage you back it up is determined by your restoration process. For example, if you are restoring a tape server, you may not need networking during the restoration process. So only back up networking in your regular backups.
You will restore in stages as well. In stage one, we build partitions, file systems, etc. and restore a minimal file system from the ZIP disk. The goal of stage one is to be able to boot to a running computer with a network connection, tape drives, restoration software, or whatever we need for stage two.
The second stage, if it is necessary, consists of restoring backup software and any relevant databases. For example, suppose you use Arkeia and you are building a bare metal recovery ZIP disk for your backup server. Arkeia keeps a huge database on the server's hard drives. You can recover the database from the tapes, if you want. Instead, why not tar and gzip the whole arkeia directory (at /usr/knox), and save that to another computer over nfs or ssh? Stage one, as we have defined it below, does not include X, so you will have some experimenting to do if you wish to back up X as well as your backup program. Some restore programs require X.
Of course, if you are using some other backup program, you may have some detective work to do to. You will have to find out the directories and files it needs to run. If you use tar, gzip, cpio, mt or dd for your backup and recovery tools, they will be saved to and restored from our ZIP disk as part of the stage one process describe below.
The last stage is a total restoration from tape or other media. After you have done that last stage, you should be able to boot to a fully restored and operational system.
2.1. Limitations
This HOWTO is restricted to making a minimal backup such that, having then restored that backup to new hardware ("bare metal"), you can then use your regular backups to restore a completely working system. This HOWTO does not deal with your regular backups at all.
Even within that narrow brief, this HOWTO is not exhaustive. You still have some research, script editing, and testing to do.
The scripts here restore the partition data exactly as found on the source hard drive. This is nice if you are restoring on an identical computer or at least and identical hard drive, but that is often not the case. For now, there are two remedies (which will make more sense after you've read the rest of the HOWTO):
Edit the partition table input file. I've done that a few times. You can also do this to add new partitions or delete existing ones (but edit the scripts that use the partition table input file as well).
Hand build a new partition table and go from there. That is one reason why restore.metadata does not call the hard drive rebuilding script. Use the rebuilding script.
The scripts shown here only handle ext2fs, FAT12, FAT16 and FAT32. Until some eager volunteer supplies code for doing so in these scripts, you will need other tools for backing up and restoring file systems we haven't covered. Partition Image looks like a useful candidate here.
