Partial Recovery Possible?

[Bridgebrain]

I have a 5tb seagate drive which got deallocated. It has 2 partitions, one is NTFS and is 4.5tb, one is Fat32 and 500mb.
Running Testdisk pulls up the main partition, but freezes halfway through investigating the second with a cylinder error.
The documentation says not to write partition until all partitions are found.

My question is, does it say this because writing the incomplete partition table will most likely make the unfound partition even worse, or is it because an incomplete partition table will corrupt the drive entirely?

[recuperation]

I have a 5tb seagate drive which got deallocated. It has 2 partitions, one is NTFS and is 4.5tb, one is Fat32 and 500mb.
Running Testdisk pulls up the main partition, but freezes halfway through investigating the second with a cylinder error.
The documentation says not to write partition until all partitions are found.

Where, please?
If Testdisk seems to freeze, duplicate your drive before running Testdisk and run Testdisk on the duplicate.
A freezing drive is an indication for some dammage.

[Bridgebrain]

Cylinder 60 I think it was.
Ran it again, haven't gotten the cylinder error, but this is where it seems to be stuck:

What software is currently recommended for the copy?
I tried a few but they don't pull it up.

To rephrase my original question, are partition tables like MBR or GPT, where there's a log of where all the partitions on the disk start and end, or are there discrete begin/end sectors per partition?

[recuperation]

What software is currently recommended for the copy?

Sorry, I failed to mention ddrescue (Linux software) that is described in the Testdisk manual.

To rephrase my original question, are partition tables like MBR or GPT, where there's a log of where all the partitions on the disk start and end,

Yes.

or are there discrete begin/end sectors per partition?

What do mean by "discrete begin/end sectors per partition?"

[Bridgebrain]

We're about 3 layers deeper into hard drive theory than I actually know, so it's entirely possible my understanding is faulty.
The way I understand hard drive tables working, there is some form of initial data pack at the beginning of the drive that says how big the drive is, manufacture data, ect, and (with your confirmation) a quick log of where the partitions are. If this log has to be 100% accurate because it's how the computer understands the structure of the drive, writing just the in/out points of the first partition would cause the entire drive to be unreadable, as there's a second unaccounted partition.
If, on the other hand, the log is just a register, and the partitions contain their own data of how they're structured, or if the log can be only mostly accurate, I could write the in/out to the first partition, and while this could cause other problems with the second partition (such as overwriting a sector or two near the edge between the partitions), the first can then be accessed.

I'll go figure out where I hid my 'nix boot drives and see if ddrescue will work out, thanks!

Update: This is the cylinder error, don't know where I remembered cylinder 60 from.

[Bridgebrain]

Where, please?

Oh, you meant where in the documentation.

In the troubleshooting guide: https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Code: Select all

If all partitions are listed and only in this case, confirm at Write with Enter, y and OK.

[recuperation]

We're about 3 layers deeper into hard drive theory than I actually know, so it's entirely possible my understanding is faulty.
The way I understand hard drive tables working, there is some form of initial data pack at the beginning of the drive that says how big the drive is, manufacture data, ect,

No, that is handled by system calls as far as I know. There are no reserved sectors for THIS purpose.

and (with your confirmation) a quick log of where the partitions are.

Yes, but depending on the number of partitions the old MBR partition table structure relies on intermediate partition tables in between partitions.

If this log has to be 100% accurate because it's how the computer understands the structure of the drive, writing just the in/out points of the first partition would cause the entire drive to be unreadable, as there's a second unaccounted partition.
If, on the other hand, the log is just a register, and the partitions contain their own data of how they're structured, or if the log can be only mostly accurate, I could write the in/out to the first partition, and while this could cause other problems with the second partition (such as overwriting a sector or two near the edge between the partitions), the first can then be accessed.

I did not unterstand you. Simplified the partition table is a register of sector ranges plus info on the file system used in each partition.
The old style MBR may be distributed all over the disk depending on the number and type of partitions.

Testdisk always starts with a quick analysis at the beginning. Deeper search becomes necessary if the quick search does not seem to provide all partition information you were looking for.