Alas, there is nothing to suggest that there was ever the start of a filesystem there, or anything else that I can recognize. It doesn't look like the result of something wiping that area either, so I don't know what else might have gone on to cause that.

"Migrate Selected Extent(s)" refers to moving all or part of an LV from one PV to another. That's not something you want to be fooling with when things are already broken. Now if you think that might have been something you did before when you were rearranging your storage, that might explain things, but would also greatly complicate recovery.

One final thing to try would be to run testdisk on just /dev/mapper/VolGroup00-LogVol02, tell it that there is no partition table, and let it try to find valid backup super blocks from the ext3 filesystem. It wouldn't have detected those when it was looking at just the one disk because it would see that the start of the filesystem couldn't have been on that disk. You'll need to start testdisk from the command line and include /dev/mapper/VolGroup00-LogVol02 as an argument. It won't show that as a candidate device otherwise.

I started Testdisk. Analysis takes some time. The first comment it threw was "Partition sector doesn't have the endmark 0xAA55".

Current status:

Attached Thumbnails

 

This time Testdisk takes a lot more time to complete. I suppose this means it has found something to study closer.

Strange. Did you not select "None" for the partition table type? It should have defaulted to that.

Shall I stop this run and try again? I cannot recall if it asked partition type...

I stopped it and this was the last screen:

I will start it again by paying attention if it asks something about partition.

Attached Thumbnails

 

Ok, I didn't pay attention to it, because the program warned about selecting "None", while defaulting to "Intel". Now started again with selection "None".

I notice the line at the very bottom of that screen, "EXT3 Large file Sparse superblock Backup superblock, 2000GB / 1863 GiB". That is very promising. You might be able to recover something by running "e2fsck /dev/mapper/VolGroup00-LogVol02", but you really should be doing that on an image of that LV written to another disk. The changes done by fsck will make the filesystem structure consistent, but that can be very much at the expense of the data. For example, you could end up with all of the files moved to lost+found with their original names lost and replaced by names derived from their inode numbers.

You can safely try e2fsck with the "-n" option just to see what it would do if allowed.

Testdisk proceeds still pretty slowly. Now after a few minutes' run it shows like this:

Attached Thumbnails

 

So is it worth running this analysis till completion?

I considered that option for e2fsck too when the SATA disk was outside of LVM, but this disk/partition is bigger than any other disk I have. I cannot fit the image anywhere.

I would let testdisk run, and see what it offers to do. I don't have any experience with testdisk recovering filesystems, but it supposedly has some capability in that regard.

If I were in your position, I'd be getting another 2TB disk to hold a copy rather than risking my data. But, that's up to you.

Yes, that's an option I have been pondering. I guess this run will be ready some time tomorrow...

It looks like there is little point in letting testdisk run. I did a test by zeroing out the first 32MB of an 8GB filesystem, and testdisk just suggests running e2fsck to reconstruct the super block from a backup super block. With that much of the filesystem overwritten, the root directory was clobbered, and testdisk couldn't do much else. 32MB is what was in the overwritten segment on your small disk.

I did run e2fsck on that damaged filesystem, letting it fix all the problems it found, and it was able to recover all but the top-level directory. What had been "home/rnichols" was now "lost+found/#393217/rnichols". Below that, almost everything was still intact -- a few missing files, some files damaged, but most were OK. I did lose the original names (there was just one, "home") for everything in that top level directory.

I still don't recommend doing that without a backup copy.

I think I can live with the result of a fair recovery attempt, whatever the result is. I would just like to do it correctly.
How does the correct command look like? Shall I use just the LVM PV or shall I add one of the suggested backup super blocks?

I tried the -n option (but without -b) and seems there's a lot to fix. Eventually that test ended with a segmentation fault!