Q:

How to recover backed up GPT disk with DD but without the extra GPT information?

A few years ago I backed up my laptop hdd with dd so that I could install linux but then revert back to windows if I wanted to. I didn't know much about UEFI and none about GPT disks, so I didn't do anything other than:
dd if=/dev/sda of=somefile.bin bs=64K

Then I restored it a few days ago and TADA, the FS in the partitions are unidentifiable. In windows' diskpart it shows the correct number of partitions with the correct sizes but the FS show as RAW for all of them.
In linux's gparted it shows all as Unidentified or something like that.
Is there a way I could perhaps fix this and make my windows partitions bootable again? I mean, I wanted to upgrade it to windows 10. I don't mind losing the data I had on it, but I don't have a recovery disk and the laptop came with Windows 8 so no product key or COA on it. :(
Any help is appreciated.

A:

Your dd operation backed up the entire disk, including the GPT data structures. Those data structures define the start and end points of partitions, so they're necessary to access the data within the partitions. If you restored in the same way (to /dev/sda, not to /dev/sda1 or some other partition), the filesystems stored in the partitions should be accessible. Thus, something has gone badly wrong. Four possibilities occur to me:

Bad backup -- You might have backed up in some way other than what you've specified. For instance, you might have backed up a partition (like /dev/sda1) rather than a whole disk; or you might have gzipped the backup and forgotten this detail; or you might have used a tool other than dd. In this case, you must figure out what you actually did in order to recover the data.
Bad restore -- As above, but on the restore side. Obviously, you're closer to this, so you're less likely to be remembering something incorrectly.
Data corruption -- In-between the backup time and now, your backup file might have been damaged in any number of ways. If this has happened, recovery may be difficult or impossible. OTOH, recovery could be as simple as using a filesystem repair tool (you'd need to do this in Windows for NTFS).
Differing disk sizes -- If the original and restore disks differ in size, problems can occur:

If your restore disk is smaller than the original, your secondary GPT data structures will not exist on the backup, rendering the partition table technically invalid, although the main partition table would still be accessible. An OS might or might not be able to get past this and access the partitions, but if the size difference is greater than a few sectors, at least one partition is likely to be badly damaged. In this case, your best bet is to restore to a disk that's at least as large as the original.
If your restore disk is larger than the original (even by a single sector), the backup GPT data structures won't be where they should be. Most OSes should be able to cope with this, but if you suspect this is an issue, you can use gdisk to fix the problem:

Launch gdisk on the disk.
Type x to enter the experts' menu.
Type e to relocate the backup data structures.
Type w to save your changes. You'll be asked for verification. Give it.

If you can't figure out what happened and how to correct for that problem, my only suggestion is to use TestDisk on the restored disk. If you're lucky, TestDisk may be able to work around a damaged partition table, but if the problem is something like your backup being gzipped and you haven't ungzipped it, TestDisk will be useless. Likewise if the filesystem data structures themselves have been damaged.

