It has been five years since I posted BackupPC and Bare Metal Restore of Windows XP, which has been surprisingly popular. However, Windows XP has been out of official support for quite a while now, and the same techniques, although they can be made to function with newer versions of Windows, are no longer ideal. On the plus side, there are better options for bare metal recovery now.
First, it’s worth mentioning that BackupPC is a system designed to back up files, not images, so recovery is going to be slightly imperfect. While the files themselves can be completely recovered, the ability to recover file permissions is limited, so that it may not be suitable for a server with complex file permissions or where security of the data is paramount. File based backups are particularly good for the case where files are lost or damaged (often through user error) but not well suited to complete system recovery — and catastrophic media failure is often an opportunity to clean out the debris that tends to accumulate over time with computer use.
So, while the ideal vehicle may have been a different backup method, such as an image backup, it’s still quite possible to recover with just the files, as I outline here. To complete this task, you’ll need a little more than twice as much space as the system to be recovered — it can be in two different places, and that isn’t a bad idea for performance — installation media for the system to be recovered, access to either HyperV or a VirtualBox virtual machine (VirtualBox is free), and the drivers necessary for the system to be recovered to reach the storage. For example, if it’s on a network share, network drivers may be necessary (even if they’re built in to Windows 7.)
Step 1: Build a local tar file using BackupPC_tarCreate
This is probably familar as being the exact same step one as before; I note that using gzip to save space or I/O appears to slow things down. 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 base media
The point of this step is to get the drives partitioned the way you want, and as before, it will just be wiped out, so it doesn’t make sense to worry about much except the partition scheme and whether or not it’s bootable, so a base installation will do. You’ll want it to be able to access the network (or whatever media is being used) as well.
So, in a nutshell, you install an operating system similar to the one you’re recovering. It doesn’t need to be identical, so you can, for example, use a 32-bit version to recover a 64-bit version, or what have you. You just need a basic, running, system.
Step 3: Back up the system
Yes, the idea is to create a system image of the base system you just installed. The data will be discarded. This can be done from Control Panel->System and Security->Backup and Restore->Create a System Image. This image either needs to be placed somewhere the VM can get to it, or moved there.
Step 4: Mount and erase the drive image
The backup image created in Step 3 is a directory called “WindowsImageBackup” that contains a folder for the PC, along with a lot of metadata and one or more VHD files. These VHD files are virtual hard drives that can be directly mounted in supported VMs. You’ll need a VM image that’s capable of understanding the filesystem, but it doesn’t need to match the operating system being recovered. For VirtualBox, the VHD file can be added to the Storage tree anywhere; it can be left in place, but it will grow to the size of the total of all files to be recovered, so plan accordingly.
For Windows 7, it’s probably easiest to clean it out by right-clicking on the drive (that maps to the VHD) and performing a quick format. While it’s possible to leave the operating system and other files in place, this usually causes all kinds of permission issues recovering matching files and can result in a corrupted image, so it’s simplest just to clean it out.
Step 5: Extract backup files to the drive image
This step requires that Cygwin be installed on the VM. A stock install of Cygwin is all that’s really needed, but there’s an important change to make to fstab:
none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
This is necessary because tar’s attempt to restore acl’s to directories doesn’t quite match the way Windows expects things to be done, and without adding “noacl” to fstab as above, tar will create files and directories which it doesn’t have access to, and will experience failures trying to restore subdirectories.
After making the change and completely closing all Cygwin windows, open a Cygwin window, navigate to the destination drive, and run tar on the archive created in step one. (A shared drive will make it accessible to the VM.)
tar -xvf /cygdrive/z/borkstation.tar
“Z” in this case is the Windows drive which is mapped to the location of the archive; the path simply needs to point to the correct file. This part takes a while, and since the virtual image needs to expand on its host disk, there will be a lot of I/O. It helps to have the source archive and the destination VHD on different media.
If permission restrictions aren’t important to you, now’s the time to right-click the destination drive within the VM, and grant full rights to “Authenticated Users.” This should be sufficient to prevent any lingering permission side-effects.
At this point, the VM should be shut down so the VHD is released. (It’s a bad idea for more than one owner to access a VHD at the same time.)
Step 6: Recover the image
The simplest way to do this is to boot the system to be recovered to the vanilla operating system installed to produce the image, and use the same Control Panel to select Recovery, then Advanced Recovery Methods, then “Use a system image you created earlier to recover your computer.”
This can also be accomplished from installation media, which is handy if anything goes wrong. Rather than installing a new operating system, selecting “Repair your computer,” then moving on to Advanced Recovery Methods, should also be able to restore the image. If you use this method, it may be necessary to manually load network drivers before being able to access shares.
Note: after the image is restored, the system may complain about not being able to load drivers, and claim that the restore failed. I’m not sure why this occurs, but it doesn’t seem to matter. Reboot, and the system should be mostly back-to-normal.
Step 7: Clean up
After rebooting, pretty much everything should be as it was. 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:
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.