Rescue Failing SSD using Fedora and an External HDD without overwriting current contents

To rescue data from a failing SSD on Fedora without overwriting its contents, connect the drive to an external HDD via a USB adapter or SATA port. Use lsblk to identify the device, then create a sector-by-sector image using ddrescue rather than copying files directly. This method preserves the raw structure and allows for retries if read errors occur, ensuring maximum data preservation before any recovery operations begin.

Preparation and Safety Precautions

Before attempting any data recovery, it is critical to understand that writing to a failing drive can accelerate its death. The primary rule of digital forensics is never write to the source media. Instead, you must create a bit-for-bit copy (an image) of the failing SSD onto a healthy storage medium, such as your external HDD. This image file becomes your working copy. If the original SSD fails completely during the imaging process, you still have the partial image saved on the external drive. Ensure your external HDD has sufficient free space. A 500GB SSD requires at least 500GB of free space on the destination drive, plus some overhead for metadata. Connect the failing SSD to your Fedora system. It is best to use a direct SATA connection if possible, as USB adapters can sometimes introduce latency or drop connections, which complicates error handling. If you must use USB, ensure the cable is high-quality and short.

Assumption: This guide assumes the failing SSD is detected by the kernel but may have unreadable sectors. If the drive is not detected in lsblk, hardware failure may be too severe for software recovery.

Identifying the Devices

Open a terminal and run the following command to list all block devices:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

You will see output similar to this:

NAME        SIZE TYPE MOUNTPOINT
sda         1TB  disk 
├─sda1      512M part /boot/efi
└─sda2      999G part /
sdb         500G disk 
└─sdb1      500G part [failing]
nvme0n1   1TB  disk 
```

In this example, sdb is likely the failing SSD. Identify the target device carefully. Mistaking the external HDD for the source device will result in catastrophic data loss. Verify the size matches the failing SSD. Do not rely solely on names like sda or sdb, as these can change between reboots. Check the model name using lsblk -d -o NAME,MODEL to confirm identity.

Once identified, unmount any partitions mounted automatically by GNOME Disks or the file manager. You cannot image a mounted partition safely. Run:

sudo umount /dev/sdb1

If the drive has multiple partitions, unmount all of them. If the system refuses to unmount because a process is using it, find the process with fuser -vm /dev/sdb1 and terminate it, or reboot into a live environment if necessary.

Installing ddrescue

The standard dd command is risky for failing drives because it stops at the first error. ddrescue (GNU ddrescue) is designed specifically for this task. It skips bad sectors on the first pass and returns to retry them later, maximizing data extraction. Install it using DNF:

sudo dnf install ddrescue

Verify the installation by checking the version:

ddrescue --version

This tool provides robust logging capabilities, allowing you to pause and resume the imaging process if the system crashes or the drive disconnects temporarily.

Creating the Disk Image

Create a directory on your external HDD to store the image file. For example:

mkdir -p /run/media/user/ExternalHDD/recovery

Now, run ddrescue. The syntax is:

sudo ddrescue -f -n /dev/sdb /run/media/user/ExternalHDD/recovery/ssd_image.img /run/media/user/ExternalHDD/recovery/ssd_log.log

Breakdown of flags:
- -f: Force overwrite of the output file if it exists.
- -n: Skip the initial scraping phase. This makes the process faster by copying good sectors first and leaving bad ones for later.
- /dev/sdb: The failing source device.
- .../ssd_image.img: The destination image file.
- .../ssd_log.log: The log file. This is crucial. It records which sectors were copied and which failed.

Monitor the progress. ddrescue does not provide a percentage bar by default, but you can check the log file periodically:

cat /run/media/user/ExternalHDD/recovery/ssd_log.log

Look for the "Non-trimmed" section. These are sectors that could not be read. Once the initial pass completes, you can attempt to recover more data by running the command again without the -n flag:

sudo ddrescue -f /dev/sdb /run/media/user/ExternalHDD/recovery/ssd_image.img /run/media/user/ExternalHDD/recovery/ssd_log.log

This second pass attempts to read the previously skipped bad sectors. Repeat this step until the number of non-trimmed sectors stabilizes. Do not obsess over every single bad sector; focus on recovering the filesystem structures and important files.

Recovering Data from the Image

Once the image is created, you can work on the .img file instead of the physical drive. Mount the image loopback:

sudo mkdir /mnt/recovery_mount
sudo mount -o loop,ro /run/media/user/ExternalHDD/recovery/ssd_image.img /mnt/recovery_mount

Use the -o ro flag to ensure the image is mounted read-only. Browse the directory structure and copy valuable files to another safe location. If the filesystem is corrupted, use tools like testdisk or photorec on the image file to recover lost files based on signatures.

For detailed guidance on accessing data from external drives with specific partition tables, refer to our article on How to Access Data on an External SSD Drive with MBR Only?. This resource explains how to handle legacy partition schemes that might complicate mounting.

If you encounter issues where the drive is not recognized due to USB controller problems, check our troubleshooting guide for Fedora 40 Doesn't Recognize USB 3.0 Ports on Gigabyte Motherboard, as hardware compatibility can sometimes mimic drive failure.

Frequently Asked Questions

What if ddrescue reports many bad sectors?
It indicates significant physical damage to the SSD's NAND flash. Continue running ddrescue with multiple passes to maximize data retrieval, but expect some files to be unrecoverable. If the number of bad sectors increases rapidly, stop immediately to prevent further degradation.

Can I use rsync to copy the failing SSD?
No, rsync operates at the filesystem level and will fail when encountering unreadable blocks. It also writes to the drive indirectly through the OS cache. ddrescue works at the block level, bypassing the filesystem entirely, which is essential for damaged drives.

Do I need to zero-fill the external HDD before starting?
No, zero-filling is unnecessary and wastes time. ddrescue handles existing data on the destination drive gracefully by overwriting only the sectors it writes. Ensure there is enough free space, but pre-clearing the drive offers no benefit.

How do I know if the SSD is dead or just the controller?
If the drive appears in lsblk but shows 0 bytes or repeated I/O errors, the controller may be locked. Try changing the USB-SATA adapter or connecting via a different motherboard port. If the drive spins up (if mechanical) or lights up but is invisible in Linux, it may require specialized hardware tools beyond Fedora software solutions.

Is it safe to power off the computer during ddrescue?
Yes, because ddrescue uses a log file. When you restart the command, it reads the log and resumes exactly where it left off, skipping successfully copied sectors. Always include the log file argument in your command to enable this resume capability.