About corrupted partition table and data recovery

Recently I ended up corrupting the partition table of one of the external USB disks that I have. This happened when I was creating a backup image of a Microsoft Surface Pro 4 device running Windows 10. I was trying to make the Surface device dual-boot with Ubuntu. My external USB disk (WD Passport 2.5'', USB 3.0, 500GB) which I was using for putting the backup image on had three partitions: one encrypted ext4, two regular NTFS partitions. When creating the backup image of surface from within Windows 10, I selected one of the NTFS volumes of my external USB disk as destination. The backup image was created. However, my other partitions of the USB disk vanished - only the newly created backup partition would show up and rest of the disk would show as "unallocated space". It was obvious that the backup image creation tool in Windows 10 had messed up the partition table of my USB disk. I had not expected this to happen. Needless to say, I was nervous about losing all the data that I had stored on other partitions.

I was however optimistic that my data would be recoverable as I had faced a similar situation of partition table corruption in the past. In situations like this Linux land has been my best bet -- a quick search with keywords data+recovery+ubuntu threw some good pointers. The one I relied on was this one. I tried using "Attempt Data Rescue" from within GParted, but it was stuck without showing any progress. The tool does not give any visual feedback to the user about what's going on. So I killed the process. Next I switched to TestDisk, which I believe is a better tool for data recovery but not without its own quirks. The screenshots at end of the post show the typical steps for a data recovery session of TestDisk tool. I'm noting some of my observations about data recovery using TestDisk:

  1. TestDisk initially does a "Quick Search" after you start the "Analyse" phase. For my case it was not able to detect the partitions which I knew were originally there on my disk.
  2. For a large disk this "Quick Search" too takes a long time (more than 40 minutes for a 500GB USB 3.0 disk on a machine having Intel i7 with 8GB RAM).
  3. TestDisk does not seem to remember the outcomes of any analyses it has done; that is, if by accident or otherwise you navigate away from a screen/phase then you lose the results. I ended up wasting a lot of time due to this (due to re-running the long "Analysis" phases).
  4. Nevertheless, this tool provides a "Deeper Search" menu option which appears after the tool has finished doing the "Quick Search". I was not able to find a direct menu to invoke the "Deeper Search" at the beginning itself.
  5. The "Deeper Search" was able to locate my original partitions on the disk which the "Quick Search" did not reveal.
  6. To "Write" the detected partitions scheme to the partition table of your disk can be unreliable. In my case the partitions, though found by "Deeper Search", could not be properly written to the disk. Now one of the lost partition had started appearing, however, the files inside it were still elusive.
  7. In order to recover the files, I stopped at the stage where results of deeper search were shown by the tool, and without asking the tool to write the partition table, I opted to browse into the detected partitions. There the tool offers options for copying files from detected partitions to another location in any disk available on the machine. This way I was able to copy the files to another disk.
Overall, I think TestDisk is a great tool -- it saved the day for me.



Popular posts from this blog

Implementing a secure contact tracing system

Data leakage possibilities with Aadhaar based e-KYC systems

Opprtunities for improving security in GoI apps