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?
TIA!
