ddrescue to create a sector-by-sector copy to an external Hard Disk Drive. This method bypasses the operating system’s file layer, allowing you to recover files even if the filesystem is corrupted or the SSD controller is struggling with bad blocks. By working on a cloned image rather than the original hardware, you prevent further degradation of the failing NAND flash memory during the recovery process.
Preparing the Environment
Before attempting any recovery, ensure that your Fedora system has the necessary utilities installed. The primary tool for this task is GNUddrescue, which is more robust than standard dd because it handles read errors gracefully and can resume interrupted transfers. You should install it via the terminal:
sudo dnf install ddrescue
Connect your external HDD to a USB port. It must have sufficient capacity to hold the entire contents of the failing SSD. Identify both drives using the lsblk command. Look for the failing SSD and note its device identifier, such as /dev/sda. Similarly, identify the external HDD, for example, /dev/sdb. Be extremely careful here; writing to the wrong device will result in permanent data loss. If the SSD is internal, ensure the laptop or desktop is powered off before physically connecting it, unless you are using a SATA-to-USB adapter that supports hot-plugging for 3.5-inch or 2.5-inch SATA drives. Note that NVMe drives typically cannot be easily connected externally without specific M.2 enclosures, so this guide assumes a standard SATA interface for maximum compatibility.
Creating a Bit-for-Bit Image
The first critical step is to create an exact copy of the failing SSD. Do not attempt to copy files using a file manager, as this can trigger heavy I/O operations that may kill a dying drive. Instead, useddrescue to map out the sectors. The syntax involves specifying the input source, the output file, and a log file that tracks progress.
sudo ddrescue -f -n /dev/sda /path/to/external/hdd/ssd_image.img /path/to/external/hdd/logfile.log
The -f flag forces overwriting of the output file, while -n skips the initial scraping phase, which attempts to read every sector quickly. For a failing drive, you might want to run this command multiple times. The first pass copies all good sectors. Subsequent passes target the bad sectors. You can retry the bad sectors with:
sudo ddrescue -d -r3 /dev/sda /path/to/external/hdd/ssd_image.img /path/to/external/hdd/logfile.log
The -d flag enables direct disk access, and -r3 sets the number of retries for bad sectors to three. This iterative approach maximizes data retrieval from degraded NAND cells. Once completed, verify the size of the .img file matches the size of the original SSD.
Analyzing the Image Filesystem
With the image created, you can now safely analyze it without risking further damage to the physical SSD. Mount the image file as a loop device to inspect the filesystem structure. Fedora usesext4 by default, but Windows partitions often use NTFS or exFAT.
sudo mkdir -p /mnt/recovery
sudo mount -o loop,ro /path/to/external/hdd/ssd_image.img /mnt/recovery
The ro flag mounts the image as read-only, ensuring no accidental writes occur. If the mount fails, the filesystem may be corrupted. In such cases, do not attempt to repair it immediately. Instead, use testdisk or photorec on the image file to recover lost files based on their signatures. These tools scan the raw binary data for known file headers, ignoring the broken directory structure.
Recovering Specific Files
If the filesystem mounts successfully, browse/mnt/recovery to locate your important documents, photos, or configurations. Copy these files directly to your external HDD or another healthy storage medium. Avoid copying them back to the same drive where the image resides if space is tight; use a separate destination if possible.
For large datasets, consider using rsync for efficient transfer with checksum verification:
rsync -av /mnt/recovery/home/user/Documents/ /path/to/backup/drive/
This ensures that every byte transferred is verified against the source image. After recovery, you can unmount the image:
sudo umount /mnt/recovery
Consider replacing the failing SSD soon, as NAND flash wear is cumulative. Even after successful recovery, the drive is likely near the end of its lifespan. For related scenarios involving dual-boot setups or BIOS detection issues, see BIOS No Longer Detects Second Drive in Dual Boot Windows-Linux Laptop. Additionally, if you need to clone a healthy drive later, refer to SSD Cloning from Windows 10 to USB: SSD Read-Only in Linux for best practices on handling read-only states.
Frequently Asked Questions
Can I use dd instead of ddrescue?
Yes, but dd is risky for failing drives because it stops immediately upon encountering a read error, potentially leaving large gaps in your image. ddrescue logs errors and retries them, maximizing the amount of recovered data.
What if my SSD is NVMe and I don't have a compatible enclosure?
NVMe drives require specific M.2 to USB adapters that support the PCIe protocol. Standard SATA adapters will not work. If you lack this hardware, remove the drive from the laptop and install it internally in a desktop PC running Fedora to perform the imaging.
How do I know if the SSD failure is logical or physical?
If ddrescue reports thousands of bad sectors quickly, it may indicate physical degradation of the NAND cells. If the drive disappears intermittently from lsblk, the controller firmware might be failing. Physical failures often require professional lab services, but imaging first is always the correct first step.
Why does mounting the image fail with "wrong fs type"?
This usually means the partition table within the image is damaged, or the filesystem metadata is corrupted. Use fdisk -l ssd_image.img to check if partitions are still visible. If not, use testdisk to rebuild the partition table within the image before attempting to mount.
Should I repair the filesystem on the image before copying files?
No. Running fsck or chkdsk on a damaged image can sometimes worsen corruption by rewriting metadata. Always copy recoverable files first using read-only methods or photorec. Only attempt repairs if you have a second identical backup and need to restore serviceability.