0

I used a live USB Linux system to create images of Windows Installations (Win 8 and 10) on hard drives like this:

dd if=/dev/sdb bs=64k conv=noerror, sync | gzip -c > /dev/sdc1/win.img.gz

However, when I try to restore them (on the same machines the images are from) like this:

gunzip -c win.img.gz | dd of=/dev/sdb

they don't boot.

Is it possible I should have backed up some sort of metadata of the filesystems? Or partition tables? I thought dd created bitwise exact copies of everything on the hard drives so that wouldn't be needed.

curious_weather
  • 1
  • Are you sure your devices have size exact multiple of 64k? Usually hard drives I was worked with have the largest power-of-two multiple of 8k. Other than this, this is very strange, it should boot. Are you using UEFI or legacy? Do you restore onto the device of *exactly same size* (not any smaller or larger than the original)? Is this the only drive Windows is using? – Nikita Kipriyanov Mar 09 '23 at 12:08
  • Hm, I thought bs only changed buffer size and therefore how many syscalls happen to read/write the data, but didn't jeopardize data integrity. Are you sure that could be an issue? – curious_weather Mar 09 '23 at 12:16
  • Otherwise: legacy and UEFI, depending on the machine. the bios settings haven't been changed. I am trying to restore onto the very same hard drives I backed up from. They are laptop hard drives, so they are the only drive Windows was using. – curious_weather Mar 09 '23 at 12:18
  • Yes, sure. This can be the source of the problem, in case of big devices or/and UEFI, since both use GPT, which is stored at defined locations in the beginning *and* the end of the device. If device is larger, the second copy of GPT happens to be out of place and this screws things. – Nikita Kipriyanov Mar 09 '23 at 12:55
  • by the way, the space before " sync", do you have it in the original command? I believe there should be no spaces around commas between items in the "conv" option – Nikita Kipriyanov Mar 09 '23 at 13:07
  • The devices are the same size, 250GB. If the bs was wrong, would the image be recoverable? If the GPT table at the beginning of the disk is sane, I guess I can move it to the end with sgdisk -e. – curious_weather Mar 09 '23 at 14:33

0 Answers0