Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
 
Other projects
   Altirra

Archives

Blog Archive

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:

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.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.