Data recovery: what works, what makes it worse

Stop writing to the drive. That one decision settles more outcomes than any tool you pick afterward: on a hard disk a deleted file stays intact until something else lands in its sectors, and on a drive with a mechanical fault every extra minute of spinning damages what you want back. What you do second depends on whether the failure is logical or physical, and whether the drive is a hard disk or an SSD. The second question is often decisive, because TRIM makes deletion on an SSD permanent in a way it never was on a platter.

Powering it down is the first diagnostic step

Seagate's support article on drive noises draws the line. Chattering and clicking during reads and writes are "reassuring sounds indicating that the drive is active," but "if a hard clicking persists or is accompanied by any kind of repeating clunking (or grinding) sound, then there is likely a physical issue with the drive." For grinding, Seagate says stop rather than diagnose: continued use "could mean that physical damage is being caused to the drive's platters," so "contact Data Recovery Services immediately before troubleshooting."

Logical loss is quieter and easier to ruin for that reason. Datarecovery.com puts it plainly: "Operating your storage device may overwrite the data," and with DIY software "you'll only get one chance to recover your files." No chkdsk, no accepting the OS repair prompt, no installing the recovery tool onto the volume you are recovering from. If that volume is the system drive, shut down and pull it rather than booting again.

Physical and logical failures are not the same problem

Datarecovery.com classifies loss as "physical, which is a hardware issue, or logical, which is a software issue." Its physical list: head crashes, bad sectors, spindle failure, PCB failure, fire or water damage, usually announced by clicking, whirring or grinding. Its logical list: accidental deletion, corruption from software errors or an improper shutdown, firmware issues, malware and accidental repartitioning.

The tempting assumption is that logical means cheap and physical means expensive. The same page pushes back: "Recovering a deleted file or lost partition could require more resources than physical data recovery, depending on the scenario." One deleted folder on a healthy NTFS volume is free-software work. A corrupted RAID set is not.

The useful test is behavioural. If the drive is detected normally, spins up quietly and does not vanish mid-copy, you probably have a logical problem and DIY tools are reasonable. If it is undetected, reports the wrong capacity, disconnects during reads or makes noise, software cannot help.

Sorting a physical failure from a logical one by how the drive behaves A decision path with two branches, taken from how the drive behaves rather than from what you think happened. A drive that is detected, spins quietly and survives a full copy is a logical problem, where DIY tools are reasonable and the safe order is to clone it with ddrescue 1.30 first and then work on the clone. A drive that is undetected, reports the wrong capacity, drops mid-read or makes noise is a physical problem, where software cannot help and SalvageData publishes a range of 300 to well over 3,000 dollars. Both branches share one rule: stop writing to the drive, because with DIY software you get one chance. Which failure you have, read off the drive's behaviour How does the drive behave? Detected, spins quietly survives a full copy Logical problem DIY tools are reasonable clone it with ddrescue 1.30 first, then work on the clone Undetected, wrong capacity drops mid-read, or noisy Physical problem software cannot help power it down now; SalvageData publishes $300 to well over $3,000 Either branch, same first move: stop writing to the drive. You get one chance. No chkdsk, no OS repair prompt, and never install the tool onto the volume you are recovering.
The fork is settled by observation, not by what you think you did. Passing the left-hand test still does not mean cheap: a corrupted RAID set is logical loss that can cost more than a physical recovery.

Why undelete works on a hard disk and rarely on an SSD

On a magnetic disk, deletion removes the filesystem's pointer to the data. The sectors keep their contents until the drive writes something else there, which is why signature-scanning tools do so well on hard disks. Flash does not work that way. NAND has to erase a whole block before it can rewrite any page inside it, so operating systems send a TRIM command on delete to mark the blocks free. DiskDigger's developers, who sell recovery software, describe the consequence anyway: "once the drive purges those stale blocks, the actual contents of the file will be wiped permanently from the drive." Their bottom line for an internal SSD on a modern OS: "the overall prognosis for recovering the files is unfortunately not good."

Rossmann Group's explainer walks the same pipeline and shows why money does not fix it. TRIM marks the pages invalid, garbage collection consolidates surviving data elsewhere, and the controller erases the emptied block, which "sets every bit in the block to 1 (the erased state). The operation is irreversible." The conclusion: "If the NAND blocks that held your files have been erased by garbage collection, no lab on earth can recover them." A clean room answers a wrecked head assembly, not an erased block.

What one delete does on a hard disk and on an SSD with TRIM Two rows of three steps, sharing the same delete. On a hard disk the pointer to the data is removed, the sectors keep their contents, and undelete works until something overwrites them. On an SSD with TRIM the same delete makes TRIM mark the pages invalid, garbage collection then erases the block and sets every bit in it to 1, and the file is gone permanently at any price. The hard disk row stops and waits at step two; the SSD row runs to the end on its own. You delete a file. What the drive does next. the delete itself what happens next what is left for you Hard disk magnetic The pointer to the data is removed The sectors keep their contents Undelete works until overwritten signature scans do well here SSD TRIM enabled TRIM marks the pages invalid Garbage collection erases the block every bit set to 1 Gone permanently at any price Still recoverable Erased, gone for good TRIM shipped in Windows 7 and Windows Server 2008 R2 in October 2009, and in Linux kernel 2.6.33. Exceptions: a USB bridge that never passed TRIM through, or power lost right after the delete.
The hard disk row stops at step two and waits, which is the only reason undelete ever worked. The SSD row runs to the end on its own schedule, which is why every exception below is a case where something interrupted it.

TRIM is also not something you forgot to switch on. Microsoft's Optimize-Volume documentation for Windows Server 2025 lists the cmdlet's default per drive type, and for flash the entry is "SSD with TRIM support. -Retrim," a switch that "generates TRIM and Unmap hints for all currently unused sectors of the volume." Support is old: Windows 7 and Windows Server 2008 R2 in October 2009, and on Linux the ATA TRIM command in kernel 2.6.33 (the earlier 2.6.28 discard support covered FTL NAND devices, not ATA SSDs).

Exceptions worth checking first: an enclosure or USB bridge that never passed TRIM through, a controller that failed before garbage collection ran, power lost right after the deletion, or TRIM disabled in the OS. If the file lived on an SSD in a cheap USB caddy, your odds improve.

Clone first, then recover from the clone

Running recovery software directly against a drive throwing read errors turns a recoverable case into an unrecoverable one. Image it first. GNU ddrescue "copies data from one file or block device (hard disc, cdrom, etc) to another, trying to rescue the good parts first in case of read errors," and refuses the destructive fallback: it "does not write zeros to the output when it finds bad sectors in the input." You get a partial, resumable image instead of a corrupted one, and can then hammer it with as many tools as you like. The current release on ftp.gnu.org is 1.30, dated 2026-01-02.

DiskInternals, which sells such a tool, states the boundary on its own sales page: "No software can heal physical damage." Buy a tool for a deletion, a quick format or a lost partition on a drive that still reads cleanly, not for a clicking drive.

ToolPrice (2026-07-27)PlatformBest for
GNU ddrescue 1.30Free, open sourcePOSIXImaging a failing drive
TestDisk / PhotoRec 7.2Free, open sourceWindows, macOS, Linux, DOSLost partitions, signature carving
RecuvaFree tier; Professional EUR 24.95WindowsUndelete on FAT/NTFS
R-Studio$79.99 base, $59.99 NTFS, $49.99 FAT, $899.99 TechnicianWindows, macOS, LinuxRAID reconstruction
DiskInternals UneraserFrom $29.95WindowsGuided undelete

TestDisk and PhotoRec 7.2 shipped on 22 February 2024 and remain the current stable release; the download page also offers 7.3-WIP builds, warning that "WIP files may change over time." The free pair covers most of what the paid tools do, minus the wizard. Pay for R-Studio only for a RAID set or a filesystem it cannot read.

What a clean-room service costs

SalvageData is one of the few labs that publishes numbers. Its cost page puts recovery of a single hard drive at $300 to well over $3,000, plus a part fee that can "range up to $500 per part" and an attempt fee that "can be up to $1000 and are non-refundable." Read that last item carefully before you ship anything.

Nobody else names a figure. Gillware says an accurate estimate is not possible "without speaking with an experienced staff member." Secure Data Recovery quotes after a free diagnostic, behind its "No Data, No Recovery Fee" guarantee.

LabPublished pricingTurnaround (standard)Clean-room claim
SalvageData$300 to well over $3,000, plus part and attempt fees5 to 7 business days"certified ISO-5 cleanroom"
Secure Data RecoveryQuote only, no data no fee5 to 9 business days"Class 10 ISO 4 Cleanroom Certified"
GillwareQuote onlyNot published"ISO 5 Class-100 certified modular cleanroom benches"
OntrackQuote onlyAverage of 7 to 14 business daysNot stated

Those labels agree with one another. Under ISO 14644-1, ISO Class 5 corresponds to the old US FED-STD-209E "Class 100" and ISO Class 4 to "Class 10." FED-STD-209E was cancelled by the General Services Administration on November 29, 2001, but the labels persist in marketing, so "Class 100" and "ISO 5" mean the same air. Get two quotes, and treat a lab that wants a large non-refundable fee before telling you what is recoverable as the expensive one.

The wiping advice in older articles is formally out of date

A guide citing NIST SP 800-88 Revision 1 is citing a withdrawn document. The warning notice on the Rev. 1 PDF gives a withdrawal date of September 26, 2025 and states that "NIST SP 800-88r1 is withdrawn and superseded in its entirety by NIST SP 800-88r2," published September 2025.

Revision 2 dismantles the multi-pass overwrite folklore. It records that the old pattern-based passes, "e.g., based on DoD 5220.22-M," ranged "from a single pass to as high as 39," and that for "SSDs with overprovisioning" such practices "should be avoided as very little confidentiality protection is achieved." A footnote adds what wiping utilities have ignored for two decades: "In 2006, DoD removed overwriting specifications from NISPOM." Degaussing gets the same treatment. It "should not be used for non-magnetic ISM (e.g., flash storage, such as SSDs)," and "at the time of this writing, degaussing is not considered an approved destroy sanitization technique."

The reason is the controller behaviour that also destroys deleted files. Because flash devices "contain spare cells and perform wear levelling," NIST calls it "infeasible for a user to sanitize all previous data" through the native read and write interface. That cuts both ways: you cannot reliably recover data, and you cannot reliably scrub it.

What replaces overwriting is cryptographic erase: destroy the key and the remaining ciphertext is meaningless. NIST calls it "noteworthy in its ability to rapidly sanitize target data" and, citing ISO/IEC 27040, requires the algorithm and mode used to encrypt the data be "at least 128 bits." Apple's Disk Utility reflects the shift: "With a solid-state drive (SSD), secure erase options are not available in Disk Utility," and Apple instead suggests you "consider turning on FileVault encryption when you start using your SSD drive." Switch encryption on the day a drive enters service, not the day you sell it: the key has to have covered the data from the start for destroying it to mean anything.

Sources