0

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.

  • So what are you asking for exactly? How to reinstall windows? – psusi Mar 31 '16 at 1:44
  • I'm asking how to recover backed up GPT disk with DD but without the extra GPT information – johnildergleidisson Mar 31 '16 at 2:04
  • Define "the extra GPT information". If the filesystems are not being recognized after restoring, then your backup is corrupt, or you did not backup and restore it correctly. You mentioned that you don't mind losing the information, which seems to indicate that you are ready to just format the drive and reinstall. – psusi Mar 31 '16 at 2:37
2

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:
      1. Launch gdisk on the disk.
      2. Type x to enter the experts' menu.
      3. Type e to relocate the backup data structures.
      4. 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.

| improve this answer | |
  • I did gzip the backup by piping dd through gzip to the file. I tested the gzip archive and it is ok. I then used gunzip piping it to dd to write to /dev/sda. From my research it seemed like there was special treatment required if the disk was GPT but from what you're saying what I did would have been enough. I'm guessing there is something wrong with the backup file or something went wrong with the restore. What I'll do is to unzip it and try to mount the partitions one by one to eliminate bad backup. Thank you for your answer. – johnildergleidisson Mar 31 '16 at 13:55
  • 1
    Different logical sector size in the original disk and the new disk maybe (or any enclosure/adapter involved)? – Tom Yan Mar 31 '16 at 14:04
  • Well, I didn't replace nor remove the hard drive from the laptop. I'd assume dd would do the work. – johnildergleidisson Mar 31 '16 at 14:37
  • Tom Yan's idea is a good one. If the disk isn't the same one used originally, or if it was moved to or from an external USB enclosure, the logical sector size will have changed, which will mess everything up. – Rod Smith Mar 31 '16 at 16:39
  • s/will/may, though that is unlikely. Virtually all consumer level drives on the market use 512 byte logical sectors even if they have 4k physical sectors to maintain compatibility with Windows ( at least of XP, maybe newer versions properly support 4k native drives ). Filesystems generally use 4k blocks anyhow and so are usually not bothered by switching between 4k and 512b logical sectors. – psusi Apr 2 '16 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.