Recovering SSD Files - No Partition and Testdisk Takes Long with Errors

Understanding Why TestDisk Fails on SSDs

When you lose a partition table on a mechanical drive, the data remains physically static until overwritten. However, SSDs operate differently. When a file is deleted, the operating system sends a TRIM command to the SSD controller, telling it which blocks are no longer in use. The SSD then garbage-collects these blocks, erasing them to prepare for new writes. This process can happen almost immediately after deletion or during periods of low activity.

TestDisk attempts to read every sector sequentially to find signature headers for file systems like NTFS, exFAT, or ext4. On an SSD, this sequential read can take hours because the controller must translate logical block addresses (LBAs) to physical NAND pages. Furthermore, if the TRIM command has already invalidated those sectors, TestDisk will return empty data or I/O errors, leading to the "long with errors" scenario described in your problem. Continuing to run TestDisk directly on the failing drive risks further degradation or accidental overwrites if the system tries to mount the drive as raw storage.

Step 1: Create a Bit-for-Bit Image with DDRescue

The safest way to recover data from a damaged SSD is to never write to the source drive again. Instead, you should create a complete image file on a separate, healthy storage device. ddrescue is superior to standard dd because it handles read errors gracefully, skipping bad sectors and retrying them later without stopping the entire process.

1. Identify your devices: Use lsblk or fdisk -l to identify the SSD you want to recover (e.g., /dev/sdb) and the destination drive where you have enough space to store the image.
2. Run ddrescue: Execute the following command, replacing /dev/sdb with your SSD and /path/to/image.img with your destination path:

sudo ddrescue -f -n /dev/sdb /path/to/image.img /path/to/logfile.log

The -f flag forces overwrite of the output file, -n skips the initial scraping phase (which is slow and unnecessary for SSDs since bad reads are usually permanent), and the log file allows you to resume interrupted sessions. Once this completes, you have a safe copy of the drive's current state.

Step 2: Analyze the Image with TestDisk

Now that you have an image file, you can run TestDisk against it instead of the physical hardware. This eliminates the I/O bottlenecks caused by the SSD controller and prevents any risk of writing to the original drive.

1. Launch TestDisk: Run sudo testdisk.
2. Select Create: Choose to create a new log file.
3. Select Image File: In the device selection menu, choose "Image File" instead of "Processor".
4. Point to your .img: Navigate to the .img file you created with ddrescue.
5. Choose Partition Type: Select "Intel/PC" for standard MBR/GPT structures.
6. Analyze: Choose "Analyse" and then "Quick Search".

TestDisk will now scan the image much faster than the physical disk. If it finds previous partition tables, it will list them. You can press P to list files within a found partition to verify integrity before proceeding.

Alternative: Using Photorec for Raw Data

If TestDisk cannot find a valid partition table, the metadata may be too corrupted. In this case, photorec, which comes bundled with TestDisk, can recover individual files based on their content signatures rather than file system structures. While this method loses filenames and directory structures, it is highly effective for recovering photos, documents, and videos from SSDs where TRIM has partially wiped the index.

To use it, launch testdisk, select "Write" only if you are sure about partition restoration, otherwise select "Search" and then choose "PhotoRec" from the main menu. Follow the prompts to select your image file and specify an output directory on a different drive to avoid overwriting other recovered data.

Related Resources

If you are unsure about the health of your drive or need to troubleshoot why the SSD is not being recognized properly, consider reviewing our guide on SSD Not Recognized on Windows and Linux. Additionally, for detailed steps on using DDRescue for complex recovery scenarios, see Recovering Files from SSD using DDRescue.

Frequently Asked Questions

Will running TestDisk delete my data?

No, TestDisk is a read-only tool when performing analysis and search operations. It only writes to the disk if you explicitly choose the "Write" option to restore the partition table. However, running it directly on a failing SSD can stress the drive, so creating an image first is safer.

Why is my SSD showing as RAW in Windows?

A RAW file system indicates that the operating system cannot recognize the partition table or file system structure. This usually happens after a crash, power loss, or failed partitioning operation. You should not format the drive, as this will destroy existing data; instead, use recovery tools like TestDisk or PhotoRec.

Can I recover files if TRIM has already run?

Recovery is significantly harder and often impossible if TRIM has fully executed on the affected blocks. TRIM tells the SSD to erase those cells, making the data unrecoverable at the hardware level. However, if TRIM was delayed or incomplete, some data fragments might still be accessible via forensic imaging.

Is it safe to boot from the SSD while trying to recover data?

It is risky. Booting from the drive can trigger background maintenance tasks or cause the OS to write temporary files, potentially overwriting deleted data. Always disconnect the SSD and attach it as a secondary drive to another system for recovery operations.

What if ddrescue fails to read certain sectors?

If ddrescue encounters unreadable sectors, it will skip them and continue, logging the errors. You can run ddrescue again with the -r flag to retry reading those specific areas multiple times. If the data remains unreadable, it is likely physically damaged or permanently erased.