Tag Archives: Recovery

BackupPC and Bare Metal Restore of Windows XP

By | | Technology
3 Comments

While it’s not well documented, it’s possible to do a bare-metal restore of a machine running Windows XP that’s been backed up via BackupPC (assuming, of course, that some method, such as that documented here, has been used to back up open files, such as the registry.)

Step 1:  Build a local tar file using BackupPC_tarCreate

The alternative, BackupPC_zipCreate, proved problematic; the gigantic archives that it created could not be completely recovered, yet tar archives proved intact.  At any rate, this is best accomplished from the command line, as the backuppc user:

BackupPC_tarCreate -t -n -1 -h borkstation -s C / > borkstation.tar

“borkstation” is the name of the host to recover, “-n -1” means the latest backup, and you’ll obviously need to have enough space where the tar file is going to store the entire backup, which will not be compressed.  Note the space between the “C”, which represents the share to restore, and the “/”, which represents the directory to restore.

Step 2:  Prepare bare XP

Basically, you want to install a working copy of the operating system.  Aside from network drivers, it really doesn’t matter if anything’s installed or working, you’re going to wipe it all out anyway.  The filesystem and the partitions will stay, so configure those the way that you want your system to finally end up.

Step 3:  Prepare Recovery Console

Using the same install CD, you can install the recovery console to speed things up a little versus booting from the CD, although either option will work.  To install the recovery console, use Start->Run, then

d:\i386\winnt32.exe /cmdcons

Where D: is the letter if the CD-ROM.  Whether you choose to install it or not isn’t really important, but what is important is that you open up the permissions for Recovery Console, or some of the remaining steps won’t work.

  1. Start->Run, then type secpol.msc
  2. Go to Security settings->Local policies->Security options
  3. Scroll down to “Recovery console: Allow floppy copy and access to all drives and all folders” and make sure it is enabled.

Step 4:  Install Cygwin

You’ll need a “tar” utility you can rely on for the next step, and experimenting with a plethora of them has shown that unless you build your own, you’ll really need Cygwin.  While installing, be sure to select the gnu tar package.  (Unless your backup contains Cygwin, you can just delete the c:\cygwin directory later to get rid of it all.)

Step 5: Unpack the tar file to the local drive

A prerequisite to this step is that you get access to the tar file created in step 1 — which you’ll have to wait for if it isn’t finished being built yet.  The simplest way to get access to the file is to map a drive to the *nix box that has the tar file. I mapped mine to the Z: drive, which was a pretty arbitrary choice.

Next, create a directory to put the recovered files into, because you do not want them going into the root directory yet.  I created a directory called “recovery.”  Launch Cygwin, then:

cd /cygdrive/c/recovery
tar -xvf /cygdrive/z/borkstation.tar

This part takes a while, but when it’s complete, the entire system as backed up will be in the c:\recovery directory.  N.B.:  this goes a little faster if you leave off the “v” parameter, but then you don’t see anything in the way of progress.  It also helps to occlude or minimize the cygwin window.

Step 6:  Rename and move files

There are three hardcoded paths in XP, that are probably the only folders in root on your minimal installation:  Program Files, Documents and Settings, and WINDOWS.  Within the c:\recovery directory, rename these to something else.  I chose “Program Files.recovery” and so on.

Once these three directories are renamed, cut and paste everything from c:\recovery to c:\.  There’s no need to replace any files in c:\, and there shouldn’t be any overlaps, so if Windows asks if you want to overwrite any files, say “no.”

Step 7:  Boot to Recovery Console and rename key folders

Here’s where Step 3 becomes pretty important.  Once you boot into Recovery Console, you’ll need to allow yourself to work in the root of the drive using the “set” command:

set AllowAllPaths = TRUE

Once that’s done, you can rename the three hardcoded directory paths, moving the originals out of the way for your recovered files.  For the sake of having a fallback position, I rename rather than delete them at this point:

ren "Program Files" "Program Files.delete"
ren "Program Files.recovery" "Program Files"
ren "Documents and Settings" "Documents and Settings.delete"
ren "Documents and Settings.recovery" "Documents and Settings"
ren WINDOWS WINDOWS.delete
ren WINDOWS.recovery WINDOWS

The suffix “.delete” has no inherent meaning, it just gets the folders out of the way and signals that I don’t need them any more.  Once this is done, and you’re sure there were no unfortunate typos, you can type “exit” to reboot to a recovered system.

Step 8:  Clean up

After rebooting, pretty much everything should be as it was, although you’ll have three extra directories with a “.deleted” suffix plus the cygwin directory to get rid of.  It may be necessary to take ownership and grant yourself permission to do so, but there’s really no reason not to wipe them all out, since your original folders and files should be intact.

While the “read only” flag has been preserved for recovered files, the “hidden” and “system” attributes have not.  For most files, this doesn’t seem to matter much, but the “desktop.ini” files that dot the drives can have weird side effects, like launching an editor upon boot and showing up.  It’s easy enough to fix from the command line:

cd \
attrib +h +s /s desktop.ini

This will grind away for a while, since it will reset all the desktop.ini files on the drive.  Once complete, you’re back to where you were upon your last backup.

Share

Restoring Selected Keys from the Registry

By | | Technology
Leave a comment

As I hope everybody does, I have a backup system in place that ensures that I have copies of all critical files, including the system registry.  A combination of Volume Shadow Copy and BackupPC ensure that I’ll have ample copies of the registry available, but the registry itself makes recovery a less-than-straightforward process.

For a bare metal restore, the process is actually not too bad.  To be specific, you can pretty much just copy over the registry files with backups (which is pretty much every file in %systemroot%\system32\config) then rebooting before doing anything else.

More specifically, you want these files:

security, software, system, default, sam

It gets a little weirder from there if you need registry elements from the user hives and security hives, which is conveniently spread out into places like “Documents and Settings\NetworkService\NTUSER.DAT”, “Documents and Settings\LocalService\NTUSER.DAT” and helpfully named things like “UsrClass.dat” spread all over creation.

It wasn’t really my purpose to delineate all these things, so I’ll move on:  instead, my purpose was to point out that what, after losing a drive and reinstalling the operating system, you decide that you don’t want to inherit all the cruft that was lurking in your “old” registry, but instead would like to pull over just a few select keys?

On the plus side, there’s a way to do it.  On the minus side, doing so is about as convoluted as the registry itself.

First, the keys you’re looking for are most likely to be housed in the file “software” or “system,” depending on whether you want some keys describing installed software or hardware, respectively — so restore these files somewhere.  The location doesn’t matter, as long as you don’t put them on top of their current locations.

Second, fire up the registry editor (“regedit” or “regedt32”) which will give you a view of your current registry.  Click on HKEY_LOCAL_MACHINE, which will then make the menu option File->Load Hive available.

Go ahead and pick the “software” file you restored, and you’re immediately prompted for “Key Name.”  This is the key name to mount the hive under, so pick something that’s not a hive already in use.  (In other words, do NOT pick “software” or “hardware” and so on.)  It’s handy, if possible, to pick something absolutely guaranteed not to be in use as a key or value anywhere in the registry, but really anything will do.

Now you can browse the hierarchy of the registry from the file you loaded.  Note that none of these keys are really “in” the registry, but now you can get to them, to select what you need out of the original registry — in my case, it’s almost universally nit picking serial numbers from software I installed long ago and I have an easier time finding the CD than I do where the original serial numbers went.  Once you’ve selected the key, File->Export will allow you to extract it in text form.

Unfortunately, registry exports store the absolute path of whatever you’re exporting, so you’ll have to edit the file to get it back in.  N.B.:  Regedit is notoriously picky about the format of this file, and it will refuse to import a file that isn’t perfect, right down to white space, so you don’t want to edit it with anything that’s going to touch anything but the text (yes, I’m looking at you, TextPad.)  I recommend Notepad with word wrap OFF.

The exported registry file will be littered with references like:

[HKEY_LOCAL_MACHINE\MY_HIVE_KEY\GoodJobSucking]

Your job, of course, is to change every single “MY_HIVE_KEY” to “SOFTWARE” (or whatever hive you’re trying to get the key back into, while leaving everything else alone.  If you were clever about the hive name you selected, this can be a global search-and-replace.

Save the file, then use File->Import to bring the key(s) back in to the actual registry.  When you’re done with this procedure, click on your hive with the crazy name, and select File->Unload Hive to be rid of it.  There’s no “save” in the registry editor, so you’re done at this point.

Share