ddrescue vs TestDisk vs PhotoRec

Your drive is making a sound it shouldn’t. A click. A whirring pause. That click-click-click that means your 3 AM is about to get very interesting.

You have three tools in your Linux recovery arsenal: ddrescue, TestDisk, and PhotoRec. Each one solves a different part of the puzzle. They’re not rivals — they’re a workflow. And if you use them in the wrong order, you’ll spend the next week fishing individual JPEG fragments out of a directory named RECOVERED_FILES while your original data sits on a drive that’s getting worse by the minute.

Let’s talk triage.

The Golden Rule: Image First, Operate Never

Before we get into the tools, nail this down: you do not operate on the original drive. Ever. Not even once.

Here’s the physics: a failing drive is a bet against entropy. Every access (read, write, seek) accelerates the failure. ddrescue knows this. TestDisk does not care. PhotoRec will cheerfully spin up a drive that’s halfway dead. The moment your drive makes a noise, you have a window—hours, maybe days—before it’s unrecoverable. You do not waste that window running recovery tools on the drive itself.

The rule: image the drive first, then work from the image.

This is not optional. This is not “best practice.” This is “if you touch the original, you lose the data.”

ddrescue: Cloning a Dying Drive

ddrescue (GNU ddrescue, not the BSD dd rescue mode) is block-level imaging for damaged media. Its job: copy every sector from a failing drive to an image file (or a new drive), and document which sectors it couldn’t read.

When to use ddrescue

• The drive powers on but has bad sectors — clicks, read errors, S.M.A.R.T. warnings screaming
• You need a forensic image — something to work from while the original degrades
• The filesystem is intact but inaccessible — ddrescue doesn’t care about partitions or filesystems; it just copies blocks

How to use ddrescue

sudo ddrescue -n /dev/sdX /path/to/image.img /path/to/mapfile.log

This is the fast pass. ddrescue reads every sector sequentially without retrying. Bad sectors are logged to mapfile.log. This takes 10 minutes for a 1 TB drive on a healthy path, hours if the drive is clicking.

The -n flag skips the scraping phase—if a sector fails, move on immediately. You’re mapping the battlefield, not winning it yet.

Then comes the second pass:

sudo ddrescue -d -r3 /dev/sdX /path/to/image.img /path/to/mapfile.log

Now ddrescue retries bad sectors up to 3 times (-r3), uses direct I/O (-d), and updates the mapfile. It reads from the position where the first pass left off. This is slow—a single bad sector can take 10 minutes if the drive is dying—but you’re maximizing recovery.

Some people run a third pass with higher retry counts:

sudo ddrescue -r10 -d /dev/sdX /path/to/image.img /path/to/mapfile.log

Each pass consumes the drive’s lifespan. Use it only if the first two passes left significant unread blocks.

Reading the mapfile

The mapfile is your recovery report:

# GNU ddrescue mapfile, version 1.14
# ipos    size      status
0x00000000 0x0000D000 +
0x0000D000 0x00003000 ?
0x00010000 0x000F0000 +
0x00100000 0x00020000 -

• + — successfully read
• ? — untried (bad sectors on first pass, but not yet retried)
• - — unreadable after all retries

If you see a sea of ? and -, the drive is toast. If you see small pockets of bad sectors mixed with +, you recovered most of the data. The image file itself will have zeroes in the unrecoverable sectors.

After the image: verify and mount

Once you have an image, work from the image, not the drive:

sudo losetup -f /path/to/image.img
sudo mount /dev/loop0p1 /mnt/recovery

Or if the filesystem is partially corrupted and normal mounting fails, use fsck on the image first:

sudo fsck.ext4 -y /dev/loop0

The original drive goes in a box. You do not power it on again unless you’re escalating to a professional recovery service.

TestDisk: Partition Table Repair

TestDisk is the Swiss Army knife for partition tables and boot sectors. It doesn’t care about file contents—it reconstructs the data structures that tell your OS “this is where the filesystem starts.”

When to use TestDisk

• The drive is recognized, but partitions are gone — fdisk -l shows no partitions, but the filesystem data is still there
• The MBR or GPT header is corrupted — the boot sector is trashed, but the partition table still exists elsewhere
• A partition was accidentally deleted — TestDisk can often recover it from metadata
• The filesystem type is unknown — TestDisk scans and identifies partition boundaries by signature

How to use TestDisk

TestDisk is interactive, but here’s the workflow:

sudo testdisk /path/to/image.img

The menu will ask you:

1. Select image type — Intel (MBR) or Mac (Apple Partition Map) or EFI (GPT)
2. Analyze — TestDisk scans the image and tries to reconstruct partitions
3. Review found partitions — it shows what it found
4. Write — commit the reconstructed partition table

Here’s the thing: TestDisk finds partitions by scanning for filesystem signatures (ext4 superblocks, NTFS boot sectors, etc.). It’s not magic, but it’s surprisingly effective.

Key point: TestDisk works on the partition table itself, not the filesystem inside. If your partition table is intact but the filesystem is corrupted, TestDisk won’t help. That’s where fsck and PhotoRec come in.

When TestDisk saves the day

• Scenario: You accidentally dd the wrong partition, wiping the MBR. The data is still on disk, but the partition table is gone. TestDisk scans and finds the ext4 superblock at sector 2048 (the standard offset). You rebuild the partition table, reboot, and mount the filesystem. Done.
• Scenario: A firmware bug or bad kernel update corrupts the GPT header. TestDisk finds the backup GPT at the end of the disk and restores the primary one.

PhotoRec: Filesystem-Agnostic File Carving

PhotoRec is a sledgehammer. It doesn’t care about filesystems, partition tables, or metadata. It scans the raw image for file signatures (magic bytes) and carves out anything it finds.

When to use PhotoRec

• The filesystem is destroyed — partitions are gone, superblocks are corrupt, no hope for fsck
• The data is heavily fragmented — PhotoRec will find the fragments scattered across the disk
• You need everything, even if it’s in pieces — PhotoRec doesn’t care if a JPEG is split across three noncontiguous sectors
• Time is running out — carved recovery is fast because it doesn’t try to understand structure

How to use PhotoRec

sudo photorec /path/to/image.img

PhotoRec is menu-driven. You choose:

1. Partition — which part of the image to scan (or leave it to scan the whole thing)
2. File system type — just for analysis (PhotoRec doesn’t care; it carves by signature)
3. Output directory — where to dump recovered files

Then it runs. And runs. On a 1 TB image, expect 30 minutes to an hour.

The PhotoRec reality

PhotoRec will find most of your files. But here’s what you get:

RECOVERED_FILES/
  f0000000.zip
  f0000001.jpg
  f0000002.pdf
  f0000003.jpg  ← probably a fragment of the same JPEG as f0000001
  f0000004.jpg  ← another fragment
  f0000005.jpg  ← possibly a full file, possibly another fragment
  [... tens of thousands more ...]

You do not get filenames. You do not get directory structure. You get raw files and fragments, named by position on disk.

Some files are whole. Most are fragmented, especially if the drive was used for a while. A 10 MB video might be 40 fragments scattered across gigabytes of disk. PhotoRec will find them, but they’re not stitched back together.

The aftermath: You’ll spend the next week:

• Sorting through thousands of files
• Deleting duplicates and fragments (PhotoRec sometimes finds the same file multiple times)
• Trying to identify what each file is (JPEG headers look the same; you can’t tell family_photo.jpg from spam_image.jpg)
• Accepting that you lost filenames and directory structure

PhotoRec is recovery of last resort. It works, but the UX is “dig through a dumpster.”

Filesystem-Aware Alternatives

If your filesystem is ext4, ext3, or ext2, consider extundelete instead of PhotoRec. It understands the filesystem and can recover deleted files with their original names and structure:

sudo extundelete --restore-all /dev/loop0p1

Deleted files are restored to RECOVERED_FILES/ with their original names (if the inode still has them).

For more sophisticated recovery, the Sleuth Kit (fls and icat) can carve files by inode:

sudo fls -r /dev/loop0p1 | grep "^\*"

These tools require the filesystem to still be recognizable, but the payoff is much better than raw carving.

The Workflow: What Order?

Here’s the triage decision tree:

Step 1: Image the drive with ddrescue

sudo ddrescue -n /dev/sdX /path/to/image.img /path/to/mapfile.log
sudo ddrescue -d -r3 /dev/sdX /path/to/image.img /path/to/mapfile.log

Step 2: Try TestDisk

• Mount the image. Does it mount normally? Go to Step 4 (done).
• Does fdisk -l show partitions on the image? Go to Step 4 (fsck it).
• No partitions detected? Run TestDisk. It rebuilds them.

Step 3: Try filesystem repair

sudo fsck.ext4 -y /dev/loop0p1

If fsck recovers the filesystem, you’re done. If the filesystem is still corrupted, escalate to extundelete (for ext*) or move to carving.

Step 4: Last resort—PhotoRec If the filesystem is toast and TestDisk can’t recover the partition table, PhotoRec carves files by signature. Prepare for thousands of fragments.

HDD vs SSD: The Playbook Changes

Hard drives fail gradually. Clicks, read errors, bad sectors that get worse over time. You have a window—hours to days—to image them before they become unrecoverable. ddrescue shines here.

SSDs fail differently. A failed NAND cell can cause a sudden, total loss of a block. SSDs often fail catastrophically—one day they work, the next day they don’t mount at all. The window is shorter. ddrescue still works, but if the SSD is electronically dead, you’re looking at a professional recovery service (they’ll remove the NAND chips and read them directly).

For both: image first, operate never. But for SSDs, if it doesn’t power on or recognize, skip the Linux tools and escalate.

The Prevention Tier: What You Should’ve Done

This whole mess is preventable:

RAID 1 (mirror)

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

If one drive fails, the other has your data. No recovery needed.

ZFS with redundancy

sudo zpool create -m /pool pool raidz /dev/sda /dev/sdb /dev/sdc

One drive fails? Replace it. ZFS rebuilds from parity.

Snapshots

sudo zfs snapshot pool/data@$(date +%Y%m%d)

You lose a file? Restore from snapshot.

Offsite backup

rsync -av /data/ backup@remote:/backups/mydata/

House burns down? You still have your data.

SMART monitoring

sudo smartctl -a /dev/sda

Bad sectors? Predictive failure? You see it coming and replace the drive before it dies.

Any one of these beats all three recovery tools combined. The best data recovery is the kind where you never need it.

When to Give Up and Call a Pro

There are limits:

• Clicking drives — ddrescue can often image them, but every read accelerates failure. After two passes, if you’ve still got a sea of bad sectors, the platters are probably physically damaged. Stop. A professional recovery service has clean rooms and heads that can read the platter directly.

• Electronically dead SSDs — the controller is fried, and it won’t even mount. A pro will remove the NAND chips and read them directly. ddrescue can’t help.

• Physically damaged drives — water damage, head crash (you’ll see shiny metal dust around the spindle), burnt circuit board. Not your problem to solve.

• Severely fragmented recovery — PhotoRec finds your files as thousands of fragments. Reassembling them by hand is theoretically possible, but practically it’s a 20-hour nightmare. A pro’s tools can often re-stitch fragments automatically.

Professional recovery is expensive ($500–$3000), but if the data is irreplaceable, it’s worth it. The cut-off: if you’ve run ddrescue twice and PhotoRec is your only option, and the data is critical, escalate.

The Decision Flowchart

Drive is dying
    ↓
[Image with ddrescue: -n pass, then -d -r3 pass]
    ↓
Does the image mount normally?
    ├─ Yes → Done. You recovered everything.
    └─ No → Does fdisk/parted show partitions?
              ├─ Yes → [Run fsck on the image]
              │         └─ Does it mount now?
              │             ├─ Yes → Done.
              │             └─ No → [Try extundelete or PhotoRec]
              └─ No → [Run TestDisk to rebuild partition table]
                       └─ Did TestDisk find partitions?
                           ├─ Yes → [Try fsck]
                           └─ No → [PhotoRec is your last option]

The Bottom Line

• ddrescue = imaging a dying drive before it’s too late. Two passes: fast (-n), then aggressive (-d -r3). Always image first.
• TestDisk = rebuilding partition tables and boot sectors when the filesystem structure is gone. Works like magic if the partition signatures are still readable.
• PhotoRec = filesystem-agnostic carving as a last resort. Slow, produces thousands of fragments, no filenames. But it finds something.

They’re not rivals. They’re a chain:

1. Image the drive (ddrescue)
2. Repair the partition table (TestDisk)
3. Repair the filesystem (fsck or extundelete)
4. Carve by signature (PhotoRec) if step 3 fails

And before you ever need these tools, keep backups. Seriously. RAID, snapshots, offsite copies. The three tools above are tactical recovery. Backups are the strategic win that makes recovery unnecessary.

Your 2 AM self—the one standing next to a clicking drive at 3:47 AM—will thank you.

Full Example: Recovering from a Failing 2 TB Drive

Here’s what it looks like in practice:

sudo ddrescue -n /dev/sdd /var/cache/ddrescue_image.img /var/cache/ddrescue.log
# Output: ... ipos: 2000 GB, non-trimmed: 0 B, bad-sector: 5 GB ...

# Check the mapfile
tail -20 /var/cache/ddrescue.log
# 0xFFFFFFF... 0x... ?  (lots of untried sectors at the end)

Drive is still spinning. Run the second pass:

sudo ddrescue -d -r3 /dev/sdd /var/cache/ddrescue_image.img /var/cache/ddrescue.log
# Runs for 4 hours, reducing bad sectors to 200 MB...

Now you have an image with most of the data:

sudo losetup -f /var/cache/ddrescue_image.img
sudo mount /dev/loop0p1 /mnt/recovery
# Mounts, but the filesystem is clearly corrupted. Files are unreadable.

TestDisk:

sudo fsck.ext4 -y /dev/loop0p1
# Recovers lost+found/ with many of your files intact.

Success. You recovered 85% of your data with the original filenames and structure. The rest is fragmentary and lost. But you have your home directory, your photos, your docs.

This is why backups matter. But when a backup is not available, this workflow is your best hope.

Keep ddrescue close. Hope you never need it.

Related Reading

• Disk Space Tools in 2026: Beyond du and df
• Find out whats taking up all the hdd space
• LVM Advanced: Snapshots, Thin Provisioning, and Not Losing Your Data
• LVM The Linux Sysadmin’s Guide to Flexible Storage
• mdadm Day-2: Grow, Replace, Scrub