Partition corruption can render an otherwise healthy storage device inaccessible. In certain cases, while scanning a disk with TestDisk (a widely used open-source tool for partition and filesystem recovery), users may observe two NTFS partitions listed with the same starting Logical Block Address (LBA).
Although this is not among the most common failure modes, it generally indicates inconsistencies in the partition structure or NTFS boot sector that TestDisk’s scanning heuristics interpreted as two possible candidate partitions.
This guide explains the technical cause behind such duplication and the recommended recovery workflow.
Understanding the Storage Layout and Failure Mode
Storage devices use one of two primary partition-table systems:
| Architecture | Table Type | Location | Notes |
| Legacy BIOS | MBR (Master Boot Record) | First sector (LBA 0) | Fixed 4 primary partitions; extended/logical support through an extended partition |
| UEFI | GPT (GUID Partition Table) | Multiple sectors (primary and backup) | Stores redundant headers and entries for reliability |
Each partition entry specifies the starting LBA, ending LBA, or size, and filesystem type.
For NTFS partitions, an additional structure, the NTFS boot sector, is located at the beginning of the partition.
It contains metadata such as sector size, cluster size, and pointers to the Master File Table (MFT). NTFS maintains a backup boot sector farther into the volume.
When corruption affects the partition table, boot sector, or both, TestDisk may detect multiple signatures pointing to NTFS at the same starting offset. As a result, its scan may display two NTFS entries beginning at the same LBA, even though only one is valid.
Typical root causes include:
- Interrupted or failed partition-table modification.
- Incorrect use of partitioning tools or forced resize/delete operations.
- NTFS boot-sector damage is causing TestDisk to detect both primary and backup signatures.
- Partial or overwritten metadata from previous formatting.
The presence of duplicates does not necessarily indicate two actual partitions; rather, it reflects that TestDisk detected more than one possible interpretation of the available metadata.
Before Making Any Changes: Safety and Preparation
Work on a recoverable copy whenever possible.
- Avoid writing to the affected disk.
- Prefer a live recovery environment rather than running tools from the OS hosted on the same disk.
Create a full sector-by-sector image if feasible: dd if=/dev/sdX of=/path/backup.img bs=4M status=progress
- Substitute /dev/sdX with the correct device after verifying via lsblk or fdisk -l.
If imaging the entire disk is not possible due to storage constraints, at a minimum back up the first several megabytes that contain partition-table structures.
Recovery Workflow Using TestDisk
Launch TestDisk with administrative or root permissions, create a log, select the affected disk, and confirm the correct partition-table type (Intel/PC for MBR or EFI GPT for GPT).
Step A: Quick Search
- Select Analyse > Quick Search.
- Review the partitions returned.
If two NTFS entries appear with the same starting LBA, evaluate each using: p (List files)
- The valid entry typically lists normal directory structures, while a corrupted or irrelevant entry may contain incomplete or garbled listings.
Step B: Deeper Search (if needed)
If Quick Search does not identify the correct partition or multiple candidates appear:
- Select Deeper Search to scan for additional signatures.
- Verify listing (p) for each detected NTFS entry.
- Mark the correct one using:
P (Primary)
L (Logical)
D (Deleted/ignore)
The goal is to produce a partition list that reflects the true, non-overlapping structure of the disk.
Step C: Writing the Partition Table
Once a correct set of partitions has been selected and verified through file listing:
- Press Write to update the partition table.
- Confirm the prompt and restart the system.
Do not proceed unless you are confident the entries are correct.
Boot Sector Repair (Only if Required)
If TestDisk reports a boot-sector problem for the selected NTFS partition:
- Go to Advanced > Boot.
- Review status:
Primary boot sector
Backup boot sector - Options:
Backup BS – Write the backup boot sector over the primary
Rebuild BS – Construct a new sector based on filesystem metadata (used if both primary and backup are damaged)
After updating the boot sector, use List to ensure the directory structure is readable.
Post-Recovery Filesystem Validation
Once the disk becomes mountable again, check filesystem consistency through the operating system.
Example on Windows: chkdsk /f /r X:
Linux equivalent for NTFS: ntfsfix /dev/sdXN
These utilities repair logical filesystem issues but should only be run after successful structure recovery.
If Recovery Fails
- If neither Quick Search nor Deeper Search returns usable partitions, the partition table may be irreparably damaged.
- If individual files rather than the structure need recovery, PhotoRec (included with TestDisk) can extract files directly by signature scanning.
- If the disk shows persistent read errors, data recovery should be attempted only from a disk image; continued operation on the physical drive risks deterioration.
If both Quick Search and Deeper Search fail to produce a usable partition entry or the disk remains RAW/unmountable even after boot-sector repair, the next step is file-level recovery rather than partition-structure repair.
For this purpose, tools that recover files directly from the disk, bypassing the filesystem metadata, can be helpful.
- PhotoRec (from the same developer as TestDisk) performs signature-based carving.
- Remo Recover provides a GUI-based alternative capable of scanning RAW or corrupted NTFS volumes and supports file/folder hierarchy recovery where metadata is intact.
These tools do not reconstruct the partition table. Instead, they rebuild files from accessible data regions and are appropriate when structural repair is no longer viable.
Finally:
Regardless of the tool chosen, file-level recovery should be performed on a sector image rather than the original disk to prevent further data loss.
