Windows 7 natively backs up user files and creates -- and keeps current -- an image of the system drive. So if a catastrophic system failure occurs, all you have to do is pop in your installation DVD, boot it and restore the disk image to pick up where you left off.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But for all its benefits, the backup system has several frustrating quirks. The biggest problem I've had is with Windows 7 adding multiple hard drives (that are not system drives) to the image for no apparent reason. For example, when I set backup to add a system image, it did so for my C: drive, and then it also insisted on adding F: -- a drive mainly for storing virtual machine images and software installation packages. I tried several workarounds, like removing the swap file from that drive, but nothing worked. Every time I went to create a new system image, it insisted on adding an F: image.
While the exact reasons for this problem are unclear, I found a few scenarios likely to occur.
1. You have added a new drive to the system and installed a fresh copy of Windows on that drive, but the boot files are still on the original drive.
When you install a second copy of Windows on a system, the installer modifies the existing boot loader to include a new entry for the freshly installed Windows version. Boot files, wherever they may reside, are considered part of the system image. Therefore, the backup system is obliged to add that entire volume as part of the system image. Otherwise, it can't guarantee that the restored image will be bootable.
This makes sense, but it didn't seem to have any bearing on my own problem. I hadn't installed Windows 7 on that second drive; it was on the C: system. Barring some bizarre corner-case bug in the backup system, which I couldn't do anything about, there had to be something special about F: for the backup system to insist on including it.
2. You have a volume initialized as a GPT volume.
Looking for other clues, I ran disk management and inspected the drive properties. It turned out that when I installed that drive, I mistakenly initialized it as a GPT volume.
GPT (GUID Partition Table) is a new disk-partitioning system designed for compatibility with systems that use Extensible Firmware Interface (EFI). It was created in part to overcome some of the limitations of the old master boot record (MBR) disk-partitioning system. All of my other drives, including my system drive, were MBR drives.
When you initialize a disk as GPT, Windows automatically adds an EFI system partition to the front of the drive (a boot partition). That way, it's seen by the backup system, it's interpreted as a system drive, and it's added to the system-image set. Since the backup system can't tell what you're going to be booting from -- it might well be from that drive -- it has to add that to the image set to preserve the bootability of the whole system.
The solution was simple, if a little time-consuming. I moved everything off the F: drive, used the Clean command in the diskpart tool to erase the drive's labeling and reinitialized the drive as MBR. After reformatting it, I copied everything back.
I suspect I originally formatted F: as GPT in preparation for some experiments involving large volumes (it's a 1TB drive) that never came to fruition. Knowing what I know now, I'll stick with MBR for all my system volumes until a real need for GPT arises.
3. You have lingering references in the registry to installed applications on other volumes.
Shortly after I cleared the GPT volume and reformatted it as an MBR volume, the system once again started to include the same drive in my system images.
The resurgence of this problem may have been caused by a lingering reference to an application installed on something besides the system drive. This might have also caused the backup system to include the drive the app was on.
CCleaner's automated registry-cleanup tool was the best place to start. The developers of the program made sure that anything flagged for deletion isn't crucial to the system. To be on the safe side, though, I had the program make backups of what it deleted. After running that and rebooting, the Windows backup tool started behaving normally -- and it has been fine for more than a month. In conclusion, I'm fairly sure the third problem will crop up on systems more often than the other two. Users are more likely to install an application somewhere other than the system drive than they are to create a GPT partition or install a second copy of Windows in their systems.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about personal computing and IT for more than 15 years for a variety of publications, including (among others) Windows Magazine, InformationWeek and the TechTarget family of sites.