6. Second Stage Restoration

As the computer reboots, go back to the BIOS and verify that the clock is more or less correct.

Once you have verified the clock is correct, exit the BIOS and reboot to the hard drive. You can simply let the computer boot in its normal sequence. You will see a lot of error messages, mostly along the lines of "I can't find blah! Waahhh!" If you have done your homework correctly up until now, those error messages won't matter. You don't need linuxconf or apache to do what you need to do.


As an alternative, you can boot to single user mode (at the lilo prompt, enter linux single), but you will have to configure your network manually and fire up sshd or whatever daemons you need to restore your system. How you do those things is very system specific.

You should be able to log into a root console (no X, no users, sorry). You should now be able to use the network, for example to NFS mount the backup of your system.

If you did the two stage backup I suggested for Arkeia, you can now restore Arkeia's database and executables. You should be able to run

/etc/rc.d/init.d/arkeia start

and start the server. If you have the GUI installed on another computer with X installed, you should now be able to log in to Arkeia on your tape server, and prepare your restoration.


When you restore, read the documentation for your restoration programs carefully. For example, tar does not normally restore certain characteristics of files, like suid bits. File permissions are set by the user's umask. To restore your files exactly as you saved them, use tar's p option. Similarly, make sure your restoration software will restore everything exactly as you saved it.

To restore the test computer:

bash# restore.all

If you used tar for your backup and restoration, and used the -k (keep old files, don't overwrite) option, you will see a lot of this:

tar: usr/sbin/rpcinfo: Could not create file: File exists
tar: usr/sbin/zdump: Could not create file: File exists
tar: usr/sbin/zic: Could not create file: File exists
tar: usr/sbin/ab: Could not create file: File exists

This is normal, as tar is refusing to overwrite files you restored during the first stage of restoration.

Then reboot. On the way down, you will see a lot of error messages, such as "no such pid." This is a normal part of the process. The shutdown code is using the pid files from daemons that were running when the backup was made to shut down daemons that were not started on the last boot. Of course there's no such pid.

Your system should come up normally, with a lot fewer errors than it had before; ideally no errors. The acid test of how well your restore works is to verify all packages. During the first stage backup, a verification was performed on the system, producing the file rpmVa.txt. Verify your system again, and compare the results to the one made earlier. E.g.:

bash# rpm -Va | sort +2 -t ' ' | uniq > ~/foo.txt
diff /mnt/zip/metadata/rpmVa.txt ~/foo.txt

Prelinking error messages are normal and you can ignore them. Do not first run the command /etc/cron.daily/prelink to remove them. Doing so may introduce new errors in the verification results that will skew your results.

Some files, such as configuration and log files, will have changed in the normal course of things, and you should be able to mentally filter those out of the report. Emacs users should check out its ediff facilities.

Now you should be up and running. It is time to test your applications, especially those that run as daemons. The more sophisticated the application, the more testing you may need to do. If you have remote users, disable them from using the system, or make it "read only" while you test it. This is especially important for databases, to prevent making any corruption or data loss worse than it already might be.

If you normally boot to X, it was disabled as part of the first stage restoration. Test X before you re-enable it. Re-enable it by changing that one line in /etc/inittab. Find the line that looks like this:


and change it to this:


Or just run this on the target to change it back. Note: different distributions use different run level schemes. These values work on Red Hat derived distributions; they may not on others.

sed -i s/id:.:initdefault:/id:5:initdefault:/g /etc/inittab

You should now be ready for rock and roll -- and some aspirin and a couch.