TestDisk 7.2 EFI GPT Deeper Search: Two overlapping MS Data NTFS entries (sector 2048 vs 2054)

[sahukumarsonu]

Hello everyone,

I am running TestDisk 7.2 on an Ubuntu 22.04 live USB to recover a single 2 TB NTFS data partition on a secondary NVMe drive (/dev/nvme1n1, 1863 GiB) whose GPT header was accidentally overwritten when initializing a new disk in Windows Disk Management.

After selecting [EFI GPT] -> [Analyse] -> [Quick Search] and then letting [Deeper Search] finish, TestDisk finds two almost identical MS Data partitions with label [Work_NVMe] shifted by 6 sectors:

Code: Select all

Disk /dev/nvme1n1 - 2000 GB / 1863 GiB - CHS 1907729 64 32
     Partition               Start        End    Size in sectors
 D MS Data                     2048 3907026943 3907024896 [Work_NVMe]
 D MS Data                     2054 3907026949 3907024896 [Work_NVMe]
 D MS Data               3907026944 3907028991       2048

Here is a screenshot of the exact TestDisk 7.2 Deeper Search terminal output:


(Direct terminal screenshot link: https://media2url.com/m/54252792133849)

When I highlight the first entry starting at sector 2048 and press P (list files), TestDisk lists all root folders and files cleanly. When I highlight the second entry starting at sector 2054 (which I assume was detected from the backup NTFS boot sector at the end of the volume) and press P, it says "Can't open filesystem. Filesystem seems damaged."

Before I change the status of the first entry (2048 - 3907026943) from D to P and write the new GPT partition table:
1. Should I leave the trailing 2048-sector entry (3907026944 - 3907028991) marked as D (Deleted), or is that a Windows reserved/protective metadata region?
2. Since listing files (P) works on the 2048-aligned entry, is writing the GPT table directly safe, or is it still recommended to copy the critical directories out via TestDisk's C file copy feature first before writing the partition table?

Thank you in advance for your guidance!

[recuperation]

Partitions are not allowed to overlapp.
If you recover the first partition you have to leave the partition starting at sector 2054 untouched in deleted status.

Checking the directories of a file system with the p-key ("list files") does not guarantee that the underlying file system is healthy.

The word "safe" in data recovery is an undefined weasel word.
The only safe thing is having a clone of your defective (logically maybe physically) disk using ddrescue as described in the manual.

Putting that partition at sector 2048 into "primary" state is only safe to the extent that the entry can be deleted in another TestDisk run.

But once its in primary state and you have Windows or linux accessing it its content, it will be modified which could diminish the chances of recovery if there is dammage inside.

In such a scenario being "safe" because one could put that partition table entry back into the state of "deleted" does not help. The dammage is already done and it might be more difficult for other recovery software to extract data from your partition.