Beware of Windows UUID on Shadow Disks

Thank goodness the Web has warnings like this one!

WinXP brings two new catches, however. First WinXP puts a unique identifier on the drive on which it runs. Cloning software exactly duplicates a hard drive, including WinXP's drive identifier. This isn't a problem unless, after the cloning or backup operation, you boot the system with both the original and backup drives present. As we've said before, if you do, WinXP sometimes gets confused seeing two drives with the same hard drive ID. It boots from the first drive but then reverses the C: and D: designations and saves data on the backup, not the original drive. It can get quite confusing, resulting in data loss and (if you later remove the backup drive) failure to boot. Second, there's the issue of the WPA (Windows product activation) code. So, if you were to later boot directly from your backup hard drive or restore to a different model replacement drive, (rather than restoring everything back to the original drive) WinXP would find itself on a "new" hard drive. Some Microsoft sources told us that changing the hard drive WinXP finds itself on would be sufficient to trigger the need to reactivate.

Windows cold-metal recovery plan

I am uneasy using opaque ghosting or backup tools like Acronis. Instead I have a simple cold-metal recovery plan. I bought a disk identical to my laptop disk. My laptop disk has an XP partition hda1 followed by an IBM service partition hda2. On the mirror disk connected via USB, the second partition sda2 boots Debian. When booted into Debian, I dd the XP partition hda1 to its mirror partition sda1. (I use some bomb-proof shell scripts that read /dev/disk/by-id/ to make sure I don't blow away my deployed XP.) Then comes the tricky part. To avoid the kind of peril above, I copy off the first 100MB of sda1 to a file in my Debian file system, and zero off these 100MB. This makes it impossible for XP to recognize sda1 as an NTFS file system, leave alone get into a fix over UUID.

In case I need cold-metal recovery, I will just transfer the ghost disk from its USB case to the laptop, boot Debian, copy back the file to the first 100MB of the first partition, thus restoring it to a mirror of my deployed XP (as of last backup). Then I reboot to XP, going back a couple weeks in time.

The USB Debian boot has other advantages: I can run badblocks, SMART tools, and backups also over the network, which I do less frequently. The Debian boot can also be used to boot other PCs and servers for maintenance and backups.