Recovering data painlessly from a friend’s drive
The other day one of my friends was all gloomy saying that he had lost a 4TB drive due to a PSU power failure, so I offered him my help to try to recover his data. This post documents the process.
The story
According to my friend, the HDD was fine until his power supply melted. After that he said he had tried to reboot his computer countless times to no avail. He wasn’t able to recover his operating system (Windows) even using startup recovery with an external USB support. Because of that he decided to move all of his data to one of the two partitions on the drive. After that he attempted to install Windows on that very same drive. He reported that the second partition (where the data were) wasn’t listed during the installation. Nonetheless he performed the installation formatting the first partition, and here the magic happened. The installation wasn’t successful and the data in the second partition was lost. That’s when I told him to bring me this disk.
Analysing
The disk was a Seagate 4TB drive. The first thing I did was check the SMART data. I haven’t got the log with me, but I clearly remember that current pending sector count and offline uncorrectable sector count were both showing 8 sectors. That’s when I asked my friend if he remembered what size the partitions were. He replied “1TB and 3TB, because a 4TB partition wouldn’t be allowed”. Now that struck me because of the known 2TB limit (not 3TB limit). I connected the drive to a Windows computer and it showed something like partition – unallocated – partition. Now if you feel uneasy with the concept of partition, give this article a look. That’s when I decided to switch to a better suited tool: TestDisk. TestDisk is a great open source command line tool that enables the so-called painless data recovery. Normal data recovery works like this: you scan for leftovers on the drive and try to put the pieces back together, if the pieces are still there and were not overwritten you’ll get the file back (and that’s for each file you want to recover). Painless data recovery works on partitions rather than actual data. For example if you accidentally erased the partition table of the drive you could potentially fix it by knowing where the partitions are and rebuild the partition table. When you start TestDisk you’ll be greeted with this screen:
TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <[email protected]> http://www.cgsecurity.org TestDisk is free data recovery software designed to help recover lost partitions and/or make non-booting disks bootable again when these symptoms are caused by faulty software, certain types of viruses or human error. It can also be used to repair some filesystem errors. Information gathered during TestDisk use can be recorded for later review. If you choose to create the text file, testdisk.log , it will contain TestDisk options, technical information and various outputs; including any folder/file names TestDisk was used to find and list onscreen. Use arrow keys to select, then press Enter key: >[ Create ] Create a new log file [ Append ] Append information to log file [ No Log ] Don't record anything
You’ll be able to log everything you do/discover. Be careful: the option Create will overwrite the existing log. Also the log will be saved in the current directory rather than where the executable is. The next step is select the disk you want to repair:
TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <[email protected]> http://www.cgsecurity.org TestDisk is free software, and comes with ABSOLUTELY NO WARRANTY. Select a media (use Arrow keys, then press Enter): Disk /dev/sda - 128 GB / 119 GiB Disk /dev/sdb - 1000 GB / 931 GiB Disk /dev/sdc - 500 GB / 465 GiB Disk /dev/sdd - 3000 GB / 2794 GiB >Disk /dev/sde - 4000 GB / 3726 GiB >[Proceed ] [ Quit ] Note: Disk capacity must be correctly detected for a successful recovery. If a disk listed above has incorrect size, check HD jumper settings, BIOS detection, and install the latest OS patches and disk drivers.
In my case the disk was /dev/sde, the next step is to select which partition table type you expect. The program will try to hint you about what partition type, in my case it had suggested EFI GPT type, and that was strange, since with it you wouldn’t potentially have the 2TB limit. Nevertheless I searched (and later performed a deep search) using a GPT partition table. I found many partitions, but none of them was readable (you can read data inside recovered partitions using the p key). That’s when I switched to Intel PC partition type (a.k.a. MBR), and voilà! I found two unrecoverable partitions and many recoverable ones. The two unrecoverable partitions aren’t really existent (I’d never think my friend would use FAT16 or FAT32 at all for his system; also he would follow the Windows installer). In the second snippet you can see the partition that had data on (and fortunately they were there).
TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <[email protected]> http://www.cgsecurity.org Disk /dev/sde - 4000 GB / 3726 GiB - CHS 486401 25 The harddisk (4000 GB / 3726 GiB) seems too small! Check the harddisk size: HD jumpers settings, BIOS The following partitions can't be recovered: Partition Start End S > FAT16 >32M 329715 91 2 522498 134 36 3097061639 FAT32 LBA 422746 163 7 500898 44 63 1255504440 3 1255504440 1585 GB / 1476 GiB
TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <[email protected]> http://www.cgsecurity.org Disk /dev/sde - 4000 GB / 3726 GiB - CHS 486401 255 63 Partition Start End Size in sectors D HPFS - NTFS 0 1 1 219050 254 63 3519054252 D HPFS - NTFS 0 32 33 219051 187 16 3519064064 D HPFS - NTFS 0 32 33 486401 53 52 7814033408 D HPFS - NTFS 12 223 20 237766 254 56 3819520000 D HPFS - NTFS 12 223 20 267349 89 4 4294760448 D HPFS - NTFS 12 250 15 267349 24 3 4294754656 D HPFS - NTFS 138068 224 35 138405 155 53 5409577 D FAT32 146619 228 48 378372 212 59 3723110949 >D HPFS - NTFS 267366 12 39 486400 243 51 3518795776 D HPFS - NTFS 267366 12 46 486400 243 51 3518795769 Structure: Ok. Use Up/Down Arrow keys to select partition. Use Left/Right Arrow keys to CHANGE partition characteristics: *=Primary bootable P=Primary L=Logical E=Extended D=Deleted Keys A: add partition, L: load backup, T: change type, P: list files, Enter: to continue NTFS, blocksize=4096, 1801 GB / 1677 GiB
I was happy and immediately restored the partition table, however I couldn’t read its content after that. That was strange. After a while I had realized the partition was over the boundaries of an MBR partition table, so decided to convert its CHS start/end to LBA in order to use it along with GPT. In order to do so you need to know how to map CHS to LBA. Thanks to Wikipedia, the free Encyclopedia.
A = (c ⋅ Nheads + h) ⋅ Nsectors + (s − 1)
This was the disk geometry: 486401 255 63 And this the boundaries of the partition: Start 267366 12 39 End 486400 243 51 (267366 * 255 + 12) * 63 + (39 - 1) = 4295235584 (486400 * 255 + 243) * 63 + (51 - 1) = 7814031359
After calculating this and running again TestDisk in GPT mode I entered manually the LBA and everything worked like a charm.
Unraveling
What I can presume happened is the following:
- The power failure resulted in the drive marking sectors as bad.
- The sectors rendered the system unbootable for whatever reason.
- The installation of Windows failed probably because of the bad PSU still being used.
- The installation erased the partition table.
So, if for whatever reasons you happen to have a faulty PSU never try to use it “one last time”. Be sure to have backups ready. And never try to write data on the drive you had data on (if you still hope to recover them). At the bottom, don’t mess with installations of operating systems if you’re not skilled enough to handle complex situations (like having another partition full of data). On the other hand, if you’re the one trying to recover the data always remember to make a whole copy of the disk using tools like dd.
Image thanks to Jaymis Loveday.
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments