¶Don't use Windows Backup
Okay, I'm now very late to this party, but let me say: don't use Windows Backup (Backup and Restore). Just don't. I attempted to use it to clone a Windows 7 installation onto a new hard drive, after running into some problems with cloning utilities, and it failed so utterly badly that I'm glad I never tried using it to actually do backups.
Let me start with the backup process. I opted to do only a critical partition backup because I was only concerned with cloning the system partitions. The data partitions I could copy peacemeal myself, but the system partition is harder to clone correctly without messing up symlinks, hardlinks, ACLs, and alternate streams. We're long past the point where you can just do a straight file copy of the Windows folder -- doing that nowadays will cause the WinSxS folder to pop open with a giant SPROING and spray duplicate file confetti all over your new drive. Either a very smart file backup tool or a partition imager is needed to get everything over correctly, and Windows Backup at least knows how to do this.
Now, when you ask Windows to back up only your system drive, it "helpfully" includes other drives that it believes are needed for system startup. I say "helpfully" because it doesn't explain what criteria are used to include drives, nor does it allow that decision to be overridden. The result was that Backup would not allow me to create a system recovery image without including my D: drive. I've since heard that services on other partitions will cause this, which in my case would be my Perforce server. This is a pretty lame requirement to have since (a) the forced inclusion of other drives is inexplicable in the UI and (b) this is still no guarantee that the services will work as they may have data on other drives anyway. Fortunately, C: and D: combined was only 170GB, so that easily fit on my external HDD and wouldn't take too long. Go do something else while it backs up the partitions, pop in a CD-R to burn the recovery boot disk, done.
Then, I tried to restore the backup onto the new HDD. What a mess.
My frustration can be summed up in one word: 80042414. That's the inscrutable error code I kept getting whenever I tried to restore the image, along with a vague mention of not finding a suitable disk and eight things I could do that might maybe work to resolve the problem. Apparently, a 500GB hard drive doesn't have enough space to restore a 120GB C: partition and a 50GB D: partition. Adding to the frustration:
- System Image Recovery doesn't tell you up front what drives it did find. You can dig around in one of the Advanced buttons to find them, which is how I verified it was seeing the disk.
- It doesn't tell you what's in the backup and thus how much space you need, just that it couldn't find drives big enough. Thus, if you thought your backup was 400GB and it's actually 500GB, the only way you know this is either by trying bigger drives or looking directly in the XML file.
- You don't specify which drives to restore to. Instead, you tell it which drives not to use, and it repartitions and reformats all the rest, defaulting to all drives except the one holding the backup. I can't convey how horrific this is.
- You can't specify which drive to use as the primary. Several times, it mentions that you need to ensure that the BIOS correctly selects as the boot drive the one that you want the boot partition restored to, and if the wrong drive is used, you need to change the BIOS boot setting and try again. Oh, and it doesn't tell you which drive it thinks this is.
- You can't choose to only restore some of the volumes in the backup. Either you manage to restore all of them, or not.
Apparently, the UI is just a wrapper on top of the wbadmin.exe tool, which itself has a not-so-great interface on top of an API with minimal error reporting capabilities. It's scary that people might be backing up servers with this.
Anyway, back to the error. 80042414 is an HRESULT, where the leading '8004' means a subsystem-specific error and the '2414' is the specific error code. A search in the Platform SDK headers reveals that the name for this error code is VSS_E_ASRERROR_FIXED_PHYSICAL_DISK_AVAILABLE_AFTER_DISK_EXCLUSION. From the description, it appears this error code basically means "something didn't fit." This explains the poor UI experience, but doesn't offer any more information than the expanded text in the UI does.
That then leads to why the backup wouldn't fit on the new drive. Not having any more detailed error or log messages, my best guess is that the restore utility was attempting to recreate the extended partition that the D: logical partition was placed in, with its original size. This would have the annoying consequence that despite the backup only having 170GB of partition data, it would still require a 700GB drive to restore to. It would also be consistent with reports that you can restore a C: image to a smaller HDD by shrinking the partition prior to backing up, since in that case there isn't an extended partition to muck up the works. This is a serious limitation since the target drive cannot have even one sector less than the total partition sizes, which is bad considering that a "700GB" drive may vary considerably in the precise number of sectors it actually has available, and so trying to get a replacement drive of the same size would be a crapshoot. They don't usually print the max LBA on the retail box.
Truth be told, I wasn't expecting much from the start, and all of this was just confirmation. What is disturbing is how fragile this restore process is despite the UI that makes it look like a reasonable backup solution. At least in the days of NT 4.0, there was no confusion that using NTBACKUP would be a bit of a rough ride -- heck, it still tried to get you to use tape. With this, though, people get fooled into thinking they just boot their recovery CD with their replacement drive, only to be stymied by a cryptic error whenever they try to restore.