Rescue Your Data from a Failing NTFS Drive: Image It, Then Copy It

The safest approach for a failing NTFS drive with thousands of bad sectors is a two-step process: first create a block-level image of the partition with ddrescue or dd, then extract your files from that image onto your ext4 drive. Trying to copy files directly from a degrading disk repeatedly exposes it to read errors, and every extra hour of spinning increases the risk of losing everything.

Why Bad Sectors Change the Strategy

A healthy drive lets you pick any copy method. A drive showing thousands of bad sectors does not. When the read head hits a damaged area, the drive may retry for seconds or minutes, stall entirely, or in the worst cases suffer further mechanical stress. Tools behave very differently under these conditions:

• File managers (copy/paste) typically abort on the first unreadable file, losing all progress if you're not watching.
• rsync is excellent for resumable transfers between healthy filesystems, but a hard read error can terminate the run, and each retry means re-reading the failing region.
• ntfsclone works at the filesystem level and is NTFS-to-NTFS oriented; it is not the right tool for landing data on ext4.
• tar streams files but cannot resume an interrupted archive.
• dd / ddrescue read raw blocks, ignore filesystem structure entirely, and can be configured to skip over bad regions instead of stopping.

Because the disk's condition is uncertain, the guiding principle is: read the source exactly once, save everything recoverable, and do all further work on the copy.

Step 1: Image the Partition Before Anything Else

An image is a byte-for-byte snapshot of the partition, written to a file. The source partition must be unmounted while you image it — otherwise the contents can shift underneath you and you'll capture inconsistent data. The destination does not need to be unmounted; you're writing an ordinary file there.

Check your free space first. The image file will be as large as the partition, not just the data on it, so imaging a 466 GB partition needs 466 GB of free space (tools like ddrescue can optionally produce a sparse file, but plan for the full size). Your laptop's root partition holds ~930 GB, but with ~800 GB of source data you will eventually need room for both the image and the extracted files — another reason to keep the image on external storage if at all possible.

The preferred tool is ddrescue (package gddrescue), which maps bad areas and retries them intelligently:

sudo apt install gddrescue
sudo umount /dev/sdb1
sudo ddrescue -d -r3 /dev/sdb1 /path/to/sdb1.img /path/to/sdb1.map

The -d flag forces direct disk access, -r3 retries bad sectors three times, and the mapfile lets you stop and resume the imaging at any time without redoing work — a critical feature when the drive keeps stalling.

If you use plain dd instead, use sensible flags:

sudo dd if=/dev/sdb1 of=/path/to/sdb1.img bs=64k status=progress conv=noerror,sync

Here noerror keeps going past unreadable blocks and sync pads them with zeros so offsets stay aligned. Note that bs=64 (bytes) is far too small and would crawl; 64K or 1M is a typical choice. Plain dd cannot resume an interrupted run — one more reason ddrescue is worth installing.

Step 2: Mount the Image Read-Only

Once the image exists, never touch the original drive again. Loop-mount the image to browse it:

sudo losetup -f --show --read-only /path/to/sdb1.img
sudo mount -o ro /dev/loop0 /mnt/image

If the image contains partition structures rather than a single filesystem, kpartx -a (from the kpartx package) or losetup -P will expose the individual partitions as loop devices. Use kpartx -d or losetup -d to detach afterwards.

Step 3: Copy Files to ext4

With the image mounted read-only, copy the files to your ext4 filesystem. Now rsync is the right tool: it's fast, resumable, preserves timestamps and permissions as well as ext4 allows, and can be rerun safely if interrupted:

rsync -aAXH --progress /mnt/image/ /path/to/destination/

Any files that were unreadable during imaging will appear as zero-filled gaps in the image — those specific files may be corrupt, but everything else transfers cleanly.

About That Second Partition

Your drive has a second partition (sdb5) that refused to mount. Don't battle it directly. Image it the same way you imaged sdb1, then inspect the image. A partition that won't mount may simply have filesystem damage that tools like ntfsfix or testdisk can address on the copy — never run repair utilities against the original failing disk.

Prevention Going Forward

Thousands of bad sectors mean the drive is ending its life. Treat every successful copy as a temporary reprieve:

• Buy a replacement drive before doing anything else; free space is your bottleneck right now.
• Keep the rescued image until you've verified the extracted files open correctly.
• Going forward, prefer ext4 or exFAT for Linux-side external drives; NTFS on Linux adds a driver layer that complicates recovery.
• Schedule regular backups — the rescue you just performed is exactly the situation backups exist to prevent.

Frequently Asked Questions

Can I skip the image and just rsync directly from the failing drive?

You can, and it's faster if the drive holds up, but every read error interrupts the run and forces re-reads of damaged regions. If the data is irreplaceable, image first. If it's disposable or you have another copy elsewhere, direct rsync is a reasonable gamble.

Why must the source be unmounted for dd/ddrescue?

Block-level copying assumes the data is static. If the filesystem is mounted, background writes can change blocks while you read them, producing an internally inconsistent image. Unmount the source; the destination is just a normal file write and can stay mounted.

Is conv=noerror,sync enough to handle bad sectors?

It prevents dd from aborting and keeps offsets aligned by padding unreadable blocks with zeros, but dd retries badly and cannot resume. ddrescue does both jobs properly and logs a mapfile of damaged regions.

Can ntfsclone convert NTFS to ext4?

No. ntfsclone produces an NTFS image or copies between NTFS targets. It doesn't convert filesystems. Use imaging plus file-level copy for an ext4 destination.

What if my laptop disk doesn't have room for both the image and the extracted files?

Extract the most important files first, verify them, delete the image, then extract the rest — or better, image to a borrowed drive. Never delete the image before confirming your extracted data is intact.