Last month’s “Guru Guidance” column showed how to create a backup strategy. A backup, though, is useless if it can’t be restored. Fortunately, restoring a few files is usually a straightforward operation. Because the computer can boot and run the normal backup tools, you should be able to restore individual files using the backup software, albeit run in reverse.
However, a problem that requires more planning is how to recover the system when all is lost — for instance, if your hard drive fails completely or if the computer is stolen by burglars. Several strategies exist for handling such disasters, but some approaches may be unavailable to you depending on how you created your backup. Broadly speaking, options fall into two categories: re-installation and restore, and complete restore.
Re-Installation and Restore
One restore option is to re-install Linux from your original installation media, install and reconfigure your backup software, and use the new, fresh installation to restore your original files. This approach has a few important advantages, such as the ability to restore a system that’s been only partially backed up, and the ability to restore a system if your emergency system fails.
Unfortunately, this approach also has some significant drawbacks. One problem is that a re-installation and restore is likely to be very time-consuming, because of the need to deal with installation options and reconfiguration. Another problem is that your restored system might require substantial reconfiguration, particularly if you were lax about backing up configuration files (such as those found in /etc).
The basic procedure for a re-installation and restore operation is as follows:
1.Install any necessary new or replacement hardware.
2.Start your Linux installation procedure as if you were installing a fresh system.
3.Choose installation options according to one of two plans:
*If your backup includes all system files and you want to completely restore them, install a minimal system on a small partition. Set aside empty partitions to hold the restored Linux from your backup media. In this case, the installation you’re performing is for a temporary Linux system.
*If your backup lacks critical system files (such as /usr and the kernel), install everything you want to your restored computer. Create partitions of appropriate size for a fully working system. In this case, the installation you’re performing will replace the old Linux installation, but it will be supplemented by user files (from /home) and perhaps some system files (such as those in /usr/local).
4.Once installation is complete, install your backup software package, if it wasn’t included in the basic installation.
5.Update your system software to the latest versions.
6.If necessary, prepare the partitions on which you plan to restore files and mount them. If you’ve done a temporary Linux installation, mount your future root (/) directory at a temporary location (say, /mnt/restore). If your current installation replaces the old one, mount the partitions to which files will be restored in their ultimate locations. Note that some backup tools require that the target partition be unmounted when a restore take place, contrary to the advice just given. This is true of dd, for instance.
7.Restore your files. The details of how you do this depend on your backup software.
8.If your new partition layout differs from your old one, edit your /etc/fstab file appropriately. (Edit the restored /etc/fstab file, which will be located under whatever temporary location you used for the restore, such as /mnt/restore/etc/fstab.)
9.Restore your system so it can boot, if necessary. You needn’t concern yourself with this step if you’ve done a replacement installation, but you must take this step if you’ve done a temporary installation. The upcoming section, “Restoring Your System to Boot,” describes this step in more detail.
10.If necessary, reboot into your newly restored system.
11.If desired, you may re-allocate the partition you used for a temporary installation for use under your newly-restored system. Alternatively, you can keep it around for future emergency use.
12.Tweak the system as required. For instance, you might need to adjust options in /etc configuration files, particularly if you did a replacement re-installation.
A complete restore is, in some ways, simpler than a re-installation and restore. The main problem with a complete restore is that it requires more in the way of preparation — which you’ll see shortly. Complete restores are also impossible if you only backed up your most critical data, such as the /home directory.
The basic procedure for a complete restore is as follows:
1.Install any necessary new or replacement hardware.
2.Boot your emergency Linux system. (Preparing these disks is covered shortly, in “Preparing Emergency Disks.”)
3.Partition your hard disks and create new filesystems on them. (Depending on your backup tools, you might not need to create new filesystems. The dd tool creates filesystems during the restore process, for example.) Remember to include a swap partition.
4.Mount your new partitions in a temporary location.
5.Use your backup software to restore data to your hard disks. The details of how to do this differ from one backup tool to another.
6.If your new partition layout differs from your old one, edit your /etc/fstab file appropriately. (Again, edit the restored /etc/fstab file, which will be located under whatever temporary location you used for the restore, such as /mnt/restore/etc/fstab.)
7.Restore your system so it can boot, as described shortly, in “Restoring Your System to Boot.”
8.Reboot your computer.
9.Tweak any configuration options that require adjustment because of hardware changes, software upgrades you want to implement, and so on. In extreme cases, you may need to recompile your kernel, perhaps with the help of another computer.
Preparing Emergency Disks
In the case of a re-installation and restore procedure, the re-installation takes the place of the emergency disk. In the case of complete restores, you’ll need an emergency disk.
In the past, preparing an emergency disk was a tricky task that required careful planning. Today, several options are possible, including:
*Emergency partition. You can prepare a small Linux installation on an emergency partition on your regular hard disk. This method has the advantage that it’s easily customized, but the disadvantage that it will be lost in some emergency situations.
This distribution (http://www.slackware.org/zipslack/
) is a variant of Slackware
that fits on a 100 MB Zip
disk or similar media and is booted from a floppy disk. It’s a minimal, text-only Linux distribution, but one that’s perfectly suited for emergency restores.
*Your distribution’s installation disks. Many Linux distributions have installation CD-ROM’s that may be used as emergency systems. You boot from the CD-ROM and issue a special command, whereupon the system boots into a simple Linux installation that’s suitable for emergency operations.
*CD-R distributions. Knoppix
), is a CD-R-based Linux system, complete with a graphical user interface. It makes a comfortable emergency restore system. Many similar systems have cropped up in recent years, so take your pick from among them.
In all of these cases, you should be sure that your chosen emergency restore system supports your backup software and hardware. In theory, you can always add the necessary software, creating a custom emergency system. In practice, such additions are easier with non- CD-R systems, since adding software to a bootable CD-R and and keeping the disc bootable requires jumping through some extra hoops. Alternatively, you could keep your backup software on some other media, such as a Zip disk or a floppy disk.
Restoring Your System to Boot
To boot, your computer requires a boot loader to load the kernel into memory. Key parts of the boot loader aren’t stored in the normal Linux filesystem, so they aren’t restored along with the rest of the operating system when you restore your normal files. Thus, to make your system bootable again after a full restore, you must re-install the boot loader.
Two boot loaders are common with Linux: the Linux Loader (LILO) and the Grand Unified Boot Loader (GRUB). Check for the presence of the /sbin/lilo and /sbin/grub programs to determine which boot loader your system used. LILO is controlled through the /etc/lilo.conf file, whereas GRUB’s configuration file is called /boot/grub/grub.conf or /boot/grub/menu.lst.
To restore LILO, load /etc/lilo.conf into your favorite text editor and examine its contents. You should see several global configuration options and one or more stanzas, each of which describes one kernel or non-Linux operating system that LILO may boot. Listing One shows a typical /etc/lilo.conf file.
To reconfigure LILO for your freshly-restored system, you must review, and possibly change, a few items:
1.Check the boot= line in the global configuration area. This line specifies where the boot loader will be installed. Listing One places the boot loader in the master boot record (MBR) of the first ATA hard disk (/dev/hda). You should only change this option if you’ve switched disk types (replaced an ATA disk with a SCSI disk, for instance) or if you place LILO in a Linux boot partition (/dev/hda3, for example, which might be /boot in your installation). In the latter case, you’ll need another boot loader, such as the one provided by DOS, to load LILO. Unless you’re multi-booting many operating systems, it’s generally better to put LILO in the MBR.
2.Check and, if necessary, alter the root= lines in any stanzas that apply to Linux. Be sure these lines point to the correct Linux root (/) filesystem. This partition should be the same as the one specified in your restored /etc/fstab for the Linux root filesystem.
3.If you’ve restored Linux using a temporary mount point, you must deal with the references to normal files. You can either adjust these references (all of which point to files in the /boot directory in Listing One) or make the files available in your temporary system’s /boot directory. The latter option is easy to achieve if you’re using a separate /boot partition: Simply unmount it from its temporary mount point and re-mount it over your temporary system’s /boot directory. If you’re not using a separate /boot partition, the easiest option is to modify the references to these files in /etc/lilo.conf; however, you’ll need to change them back after you’ve finished re-installing LILO.
To actually re-install LILO, type lilo as root at a command prompt. If your modified lilo.conf file isn’t in the current /etc directory, point to it with –C, as in lilo –C /mnt/restore/etc/lilo.conf. If all goes well, this command will read the lilo.conf file, create a customized boot loader, and place it in the MBR or the boot sector of the Linux boot partition.
GRUB reconfiguration is done in much the same way, but many details differ. Listing Two shows a simple GRUB configuration file.
kernel /bzImage-2.6.15 ro root=/dev/hda7
Many, but not all, partition references in GRUB take the form (hd x,y), where x is a number referring to a hard disk device and y is a partition number. Numbering for both begins with 0. Thus, in GRUB, Linux’s /dev/hda3 is (hd0,2).
As with LILO, you should modify the partition identifiers to conform to your new partition layout, if required. The one on the root line in your Linux stanza is particularly important; it refers to the partition that holds the Linux kernel and GRUB binary files. Also be sure to change the Linux partition identifier following the root= option on the kernel line. This identifier is passed to the kernel, and so is stated in Linux format rather than in the GRUB format. Unlike GRUB’s root option, this kernel option refers to the Linux root (/) filesystem.
If you’ve changed your configuration from using a separate /boot partition to folding these files into the Linux root filesystem or vice-versa, you’ll need to add or delete references to the /boot directory when referring to files in that directory. This includes, most notably, the kernel file itself. Listing Two assumes a separate /boot partition (/dev/hda3 or (hd0,2)). If the system has no such partition, you’d add /boot before /bzImage-2.6.15 on the kernel line and set the root line to point to the Linux root filesystem.
Be sure to point to the kernel and other files where they will exist when you reboot, not where they’re mounted in your temporary restore. LILO locates these files when you type lilo, but GRUB locates them when the system boots, so you should not include paths such as /mnt/restore/boot/bzImage-2.6.15, as you might with LILO.
When you’ve finished modifying GRUB, you must re-install it to your MBR or Linux boot partition. To do so, follow these steps:
1.Type grub as root. This should produce a grub> command prompt.
2.Point GRUB to its root partition with the root command, as in root(hd0,2). You’ll normally point to the same partition that’s specified by the root option in your Linux stanza.
3.Type setup(hd0) to install GRUB to the MBR of the first disk. If you want to use another boot loader in the MBR and use GRUB as a secondary boot loader, replace (hd0) with a partition identifier, as in setup(hd0,2).
At this point, your system should be restored and bootable. Your emergency disk probably supports the shutdown command, so try it, as in shutdown –r now to reboot the computer. When the system reboots, you may need to eject your floppy disk or CD-ROM to boot from the hard disk.
Ideally, the computer should boot up and work as it would have if you’d rebooted just after backing it up. Unfortunately, problems sometimes occur at this stage, so you may need to troubleshoot them. Difficulties related to the boot loader are most common, so review your boot loader configuration to be sure everything is set up as it should be.
Testing Your Procedure
Before you run into a problem, you should test your restore procedure. The best way to do this is to remove your hard disk and test the restore procedure on a blank disk. This approach minimizes the risks involved in such a test, but has the drawback of making the computer unavailable for regular work.
Alternatively, you might try restoring to a completely different computer — but keep in mind that hardware differences may reduce the capabilities of the restored system. The two systems might also conflict with one another if placed on a network, so it’s best to perform such a test with the network disconnected.
If you can’t spare a disk or computer for testing, try testing as much of the restore procedure as possible without actually performing a full restore. Perhaps you could restore one user’s home directory to an alternate location, for instance. Such incomplete tests won’t be sufficient to be sure you’ll be able to restore a fully bootable system, though.
Roderick W. Smith is the author or co-author of over a dozen books, including Advanced Linux Networking and Linux Power Tools. He can be reached at