Getting to the point: testdisk is able to navigate the filesystem and hierarchy (apparently as if it was intact) and individually recover files. Is there a way to have it do all of them, automatically?

The story:

I'm working from a dd clone of an immutable gddrescue clone (sector to sector copy) of a flaky external USB 3TB drive used on an ~2016 rPI until Oct 2017. I believe it contained 2 partitions: 6GB and ~3TB (??). The 6GB has been recovered and mounted. In the cloning, ddrescue wasn't able to scrape ~1MB (total) across 25 areas of the drive.

My goal is to salvage as much of large partition file organization, files and modification times as possible. Foremost has been used, but loses the organization (most of the value).

I'm now working with Ubuntu 16.04.03LTS, the immutable clone partition table has the wrong boundaries and I've used testdisk to write a plausible one to the recovery drive - and have recovered the filesystem of the first small partition. Interestingly, fdisk reports the drivelabel type as DOS and mentions a limit (2^32 sectors?), and the large partition written by testdisk is show as only 2TB. With parted, I changed it to GPT and now its the full ~3TB as ~5.86Gsectors.

The 2nd partition filesystem is navigable with testdesk, and I can individually save files. But there are likely in excess of a million.

The question: This tells me that some of the filesystem is present and partially intact - but I don't know how to use testdisk to automatically capture the file structure and files that are present.

Can testdisk do this? Or is there another tool that can make use of whats good in the file system? Possibly adding code to testdisk to perform this automatically it a reasonable approach?

Another approach : After 'fixing' the partition table w/testdisk, e2fsck on partition 2 (~3TB) reports :

""The filesystem size (according to the superblock) is 730993525 blocks The physical size of the device is 536870911 blocks Either the superblock or the partition table is likely to be corrupt!""

Running mke2fs -S followed by e2fsck results in errors everywhere and leaves nothing of value.

Its likely that in Oct 2017, mke2fs -S was run on the 2nd partition, but using the original corrupted partition table.

A 3rd approach : Testdisk is rather opaque to me, so I've written a program to find superblocks, and have verified their last mount point, etc. Thus I'm confident that the drive does contain intact superblocks from the large partition. If I have one of those superblocks, could I make use of it somehow such that e2fsck could do the rest? I imagine that the superblock however, would only have block address relative to the start of the partition. Since the superblock had to be at one of several locations (and has a known skip pattern), maybe I could use that info to assign the correct start of partition location?



You're looking for e2fsck with the testdisk-discovered superblocks? Under >[ Advanced ] Filesystem Utils the >[Superblock] command should "Locate ext2/ext3/ext4 backup superblock" similar to this:

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>

Disk 1 - 104 MB / 100 MiB - CHS 13 255 63

     Partition                  Start        End    Size in sectors

  ext2                     0   0  1    12 190 50     204800
superblock 0, blocksize=1024 []
superblock 8193, blocksize=1024 []
superblock 24577, blocksize=1024 []
superblock 40961, blocksize=1024 []
superblock 57345, blocksize=1024 []
superblock 73729, blocksize=1024 []

To repair the filesystem using alternate superblock, run
fsck.ext2 -p -b superblock -B blocksize device

>[  Quit  ]
                            Return to Advanced menu

And then try the suggested fsck.ext2 / e2fsck command with different superblocks until finding a "good" one.

Also Testdisk seems able to copy entire folders, so if much of the filesystem's still there then it may only be the folders in the root that need manual copying, and all their sub-folders & files will get copied too.

Hopefully there's only a few in root, and not millions, though the : to select files for later copying does move down to the next file, and a selects all files (in that folder)

Here's a "screenshot" just after copying the "Downloads" folder from root (it contains 2 files, and the Copy done! 2 ok, 0 failed message is in green):

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
   P ext2                     0   0  1    12 190 50     204800
Directory /
Copy done! 2 ok, 0 failed
 drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 .
 drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 ..
 drwx------     0     0     12288 17-Jan-2018 07:49 lost+found
 drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 Documents
>drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 Downloads

Use Right to change directory, h to hide deleted files
    q to quit, : to select the current file, a to select all files
    C to copy the selected files, c to copy the current file
  • Wow - I really overlooked the ability to copy directory trees. Its running now. Root has < 10 directorys - so this could be the solution. Testdisk doesn't locate any superblocks in the large partition. My program is much looser on the constraints as to what it calls a superblock. (16 bit magic number @ 0x38, and 0 zeros at 0x19?). It then prints the text fields. But I think the simple directory copy is going to do all that I need. The first tree I've copied has >150k files that foremost found, and testdisk has 6551 ok with 0 fails. Thank you.
    – pathfinder
    Jan 17 '18 at 22:04
  • It's too bad fsck couldn't get it into good enough shape to mount, but getting the data out is all that matters anyway, so mission accomplished :)
    – Xen2050
    Jan 18 '18 at 10:26

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.