In the past year alone, I’ve had four near-fatal drive failures, each on a different system. To alleviate some of the pain associated with recovering from these kinds of problems, I’ve been working on building a self-contained, multiboot rescue CD that I can use to bring up a crippled system and perform emergency surgery.
This includes tasks such as repairing a broken partition table, cloning a failing drive to a new disk before the old one dies completely, or simply changing a corrupted file that is preventing the operating system from booting.
There are actually a number of options for building these kinds of things, depending on what you are trying to do. If you just want to fix up a Windows installation, you can use the Windows XP Recovery Console and a boot CD to bring a crippled system far enough along to do rudimentary repair work. (Fred Langa shows how to turn the recovery console into a functional command-line interface in this article. )
If you want something more than that and are willing to invest some sweat equity, you can put together a relatively full-featured Windows-based graphical repair environment by using Bart PE or one of its derivatives. (Fred talks about Bart PE in this article.)
There are also several different Linux-based recovery CD images that are useful for repairing a variety of problems. SystemRescueCD and Recovery Is Possible are two distributions that are designed for general system recovery. Most of the general purpose Linux distributions also provide a recovery image that is specifically optimized for fixing their own installations too.
Another option here is to use plain old DOS as the basis for a recovery CD. As with the other platforms, there are a couple of pre-made recovery toolkits that you can use for this, such as Ultimate Boot CD and 911 Rescue CD, but it’s also pretty simple to build your own.
If you want a single recovery CD that can be used to address the widest array of problems, you’ll probably need to incorporate Linux, Windows XP, and DOS into your build. For example, most of the hardware management tools use DOS as a boot loader, but recovering from system configuration errors often requires full access to the underlying file systems, which typically means booting up a thinned-down version of the installed operating system.
In my case, I chose to put the emphasis on DOS, while also using bootable images of Windows XP and Linux for those times when the DOS tools are insufficient. The reasons? DOS boots faster than any of the other operating systems, meaning that I can get into a busted system quicker. Also, since DOS relies on the system BIOS for most of its device support, I usually need to load only a couple of drivers, and those will easily fit on a floppy boot image, which can’t be said for any of the other platforms. The complete lack of any kind of system security is another benefit, since I don’t have to worry about passwords or file system privileges.
On the other side of the coin, however, working with DOS leads to the unavoidable and unmistakable realization that you are essentially working with abandonware; the operating system is dead for all practical purposes, and the number of available tools is continually diminishing. Access to modern hardware devices can also be tricky, network services are practically non-existent, and even if you get everything working memory management is absolutely miserable.
But despite the shortcomings, the benefits to using DOS for recovery purposes still outweigh the negatives, and for some things it’s downright mandatory. Having said that, if there were a better alternative, I would be running toward it.
