Posted by: Ed Tittel
add only super-critical drives to Windows 7 image backup savesets, use an extra internal drive for your Windows 7 image backups, Windows 7 image backup/restore has interesting quirks
Yesterday afternoon, I came back from running an errand in the afternoon only to find a BSOD waiting for me on my production Windows 7 machine. After I got it restarted, I realized something major had gone wrong. Not only had the OS “lost” all of the security updates and patches it’s had applied to it, the update process wouldn’t complete successfully, either. Downloads went fine, install completed without a hitch, but when I cycled the machine through the restart process to do the final clean-up, I saw a new WU error message “Unable to configure Windows. Reverting to previous version.”
“This is bad!” I thought. I was right, but it took me six hours to figure out how right I was, and to take the steps necessary to restore my latest image backup (taken Sunday night, February 7). Along the way I learned numerous interesting but extremely frustrating things about the Image backup facility built into Windows 7. Here’s an abbreviated list:
- Windows 7 scans only internally mounted hard disks when looking for the folder named WindowsImageBackup. I am in the habit of backing up to an eSATA-attached hard disk, so I had to copy that directory from my K: drive to my only internal data drive F:. 181GB, which took 45 minutes.
- Whatever drives go into a Windows 7 image saveset must be restored for the backup to complete. Although the interface includes an “Exclude drives” option, the backup cannot be restored if any member drives from the saveset get excluded.
- Also, no drive in the saveset can be the source for the image to be restored, because this means it would at some point have to restore itself from itself (which is the file system equivalent of the chicken and egg problem, conveniently solved by being disallowed).
- My only internal hard drive other than the system drive (also disallowed, but because it’s an 80 GB Intel SSD and thus too small to play host to a 181 GB image file anyway) is the F: and I stupidly configured it to be part of the saveset, so I couldn’t run the image restore as things stood.
Obviously, I needed to copy the WindowsImageBackup folder one more time (another 45 minutes shot) to a different drive that was neither C: (the Intel system drive) nor F: (my other internal data drive, and a part of the image saveset). Enter Drive D: already attached to my PC through a PCI-e x1 two-port eSATA card. “OK” I figured, “the reason the Windows 7 Repair Environment won’t see D: is because it doesn’t recognize eSATA drives while conducting repairs. (The Repair Environment is a special version of the pre-installation environment, or PE, that is included on install DVDs and appears on bootable UFDs created to house the various Win7 ISO files.)
My first thought was to simply disconnect the F: drive and use its power and data cables to hook up to D: and let the restore get underway. That’s when I learned that even if you exclude a drive from the restore instructions for an image backup, Windows 7 won’t allow it to proceed with a missing drive. If you image two drives, you must then restore the same two drives (or drives that are equal in size or bigger). With F: disconnected to hook up D: that meant no dice.
Next, I grabbed a motherboard cable set that plugs into a motherboard SATA port and a Molex 4-pin power connector, and essentially routes that connection outside the case. Alas, Windows 7 RE still couldn’t see that drive. I had thought that because I was using a third-party Silicon Image Sil3132 two-port eSATA adapter, that this might explain why Win7 RE overlooked scanning attached devices during repair maneuvers. But even when I hooked the D: drive up through the adapter card shown in the photo below, Win7 RE still blithely ignored its presence.
Nothing short of opening the case, plugging a new SATA cable from drive to motherboard, and plugging in a power output from the PSU sufficed to get Windows 7 to recognize the drive.
Finally with both C: and F: up and running, and available for an image restore, and another internal drive also avaialble from which the image file could be read to perform that restore, I was ready to rock and roll. Time required to go through all of the shenigans and scenarios involved was right about six hours. I don’t know how long the restore took to complete, because I fired it off at a little after 10:00 PM last night and went to bed shortly thereafter. When I got up this morning, the machine was back up and running in an apparently normal and healthy state. I copied my saved PST files from yet another external drive to the proper folder in my User file hierarchy, and thereby regained all my e-mail messages through yesterday’s debacle.
Now, I get to go and repeat my last two days’ work because that’s the only stuff that I lost irretrievably when this machine decided to go south on me. Here are the morals I extract from this episode:
1. When you build or buy a Windows 7 machine, if you want to use image backup, insert or acquire an extra internal drive, so you can use it to image all of your other drives if you choose to do so.
2. When you construct an image file saveset, include only those drives you want to be able to back up from any image in that set. As of today, I’m relying on conventional file-by-file backup for all of my drives, except for the system drive (where the image stuff matters most, because of the boot-up, operating system, and volume shadow copy stuff).
3. I’m reworking my backup schedule to go nightly for all important working directories, but will still keep making an image backup once a week (mine goes off at 0-dark-thirty on Sunday night when I am never, ever working late). Hopefully, I can avoid future data/work losses that way.