Case Study 1 — The SSD a Second Opinion Saved

A client is told her deleted family archive is gone because "you can't recover an SSD." A second shop asks one question the first never did — did TRIM actually reach this drive? — and the answer rewrites the verdict. This is a recovery story about why "know your limitations" must never harden into a reflex that refuses to diagnose.

Background

The client was a freelance motion-graphics designer. The device was a bare 2 TB Crucial MX500 SATA SSD that she did not use as an internal drive at all — she had dropped it into a $14 generic USB 3.0 enclosure years earlier and used it as a portable archive she carried between her studio and home. On it lived the things that cannot be re-shot: roughly 1,200 scanned photographs and letters from her late grandmother, digitized over a long winter the year Nana died, and about forty short family video clips. The archive was, she admitted, the only copy — the digitizing project had felt like the backup.

One evening, clearing space for a client deliverable, she deleted a folder named Nana from the external drive, emptied the Recycle Bin, and kept working. She used the drive lightly for about a week — pulling a few project files off it, copying one render onto it — before she went looking for a scanned letter and felt the floor drop out.

She took it first to a shop near her studio. They plugged it in, saw an exFAT volume with the folder gone, and delivered the verdict in under ten minutes: "It's an SSD. When you delete and empty the trash, TRIM wipes it at the hardware level. There's nothing on an SSD to recover after that. Sorry." They charged her nothing, which she appreciated, and sent her home to grieve a second loss. A week later, on a friend's suggestion, she brought it to us for a second opinion.

The recovery

We did not plug it into a workstation to "look." On flash, the look is the damage — a live Windows box auto-mounts an external volume, sees the file system's free space, and can issue TRIM across it. We connected the enclosure through a hardware write blocker and asked the drive and the path a few cheap questions before promising anything.

The first shop's verdict rested on an assumption it never tested: that TRIM had reached this drive. We tested it. The MX500 itself is a modern RZAT drive — hdparm -I confirmed "Deterministic read ZEROs after TRIM" — so if a TRIM had been processed, the first shop would have been right. But this drive had spent its entire life behind a cheap USB-SATA bridge, and that bridge was the whole story:

$ sudo lsblk --discard
   NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
   sdb           0        0B       0B         0      <- no TRIM/UNMAP passthrough on this path

A DISC-GRAN of 0B means the kernel sees no discard support on this device path at all: the enclosure's bridge does not forward UNMAP/TRIM to the drive behind it. Windows had dutifully issued delete-notifications when the folder was emptied — DisableDeleteNotify was 0 on her machine — but those commands died at the bridge. In two years of use, this SSD had very likely never received a single TRIM in its life. The drive could zero a trimmed range on command; it had simply never been told to.

A thirty-second triage of a quick read sample confirmed the optimism: the unallocated region read as ordinary data, not a sea of zeros.

$ python3 trim_triage.py /cases/mx500_sample.dd
   all-zero       : 6.81%    <- nowhere near a trimmed-RZAT footprint
   verdict        : substantial non-zero data survives -- carving is worth attempting

That single number told us the deleted clusters were almost certainly still there. The remaining risk was not TRIM but ordinary overwrite — a week of light use on a 2 TB drive that was ~85% empty, where the exFAT allocator had ample free space and little reason to reuse the freed clusters.

The discipline now was specific to flash: image fast, and image through the path that preserved the data. We did not shuck the bare SSD out of its enclosure and into a faster modern UASP adapter — a UASP enclosure can pass UNMAP, and connecting the bare drive to a TRIM-capable path could have trimmed on mount the very data the cheap bridge had been quietly protecting. We imaged it through its own enclosure, behind the write blocker, hashed it, and powered down — minimizing the powered window because even idle, the controller can run housekeeping.

$ sudo dcfldd if=/dev/sdb of=/cases/mx500_archive.dd hash=sha256 \
              hashlog=/cases/mx500_archive.sha256 bs=1M conv=noerror,sync
   1,907,729 MB in / 1,907,729 MB out
   Total: sha256 7b2e4f...c0a9

All further work happened on the copy. Logical recovery of the exFAT volume found the Nana directory's deleted entries intact: the entry set's in-use bits were cleared and the allocation bitmap had freed the clusters, but the cluster runs still pointed at live data the controller happily returned, because no TRIM had ever told it otherwise. For the handful of files whose directory entries had been partially clobbered by the week's writes, we carved by signature — JPEG (FF D8 FF E1, Exif), TIFF, PDF, and the clips' MP4 ftyp boxes — recovering their bodies from intact clusters.

The tally: of roughly 1,240 items in the folder, we returned about 1,190 fully intact and a dozen more partially (a few scans with a corrupted lower third where a render had landed on their tail clusters). Every video clip came back. The grandmother's letters — scanned as PDFs — were whole. About 96% recovered, three weeks after a deletion an experienced shop had pronounced unrecoverable.

We sent her home with the archive on two new drives and a cloud sync configured, because the cheapest recovery we sell is the one that means she never needs us again. The deletion had not destroyed the data; it never could have, because the command that would have destroyed it never arrived.

The analysis

  1. "Know your limitations" cuts both ways. The first shop applied a true principle — TRIM on an RZAT drive destroys data — without checking whether its precondition held. Over-claiming recoverability is malpractice; so is over-claiming impossibility. The professional move is the same in both directions: diagnose, then conclude. One untested assumption nearly cost an irreplaceable archive.

  2. The path is part of the diagnosis, not just the drive. The MX500 was RZAT; in an internal slot it would have been the hopeless case. What changed the verdict was the bridge — lsblk --discard showing no passthrough. On external SSDs, you diagnose the whole acquisition path, because that is what decided whether TRIM ever reached the silicon.

  3. Image through the path that preserved the data. Shucking the bare drive into a modern UASP adapter to "image it faster" could have trimmed on mount the very data the cheap enclosure had protected for two years. The discipline — acquire through the same non-TRIM bridge, behind a write blocker — was what made the optimistic diagnosis collectible.

  4. On flash, the original is sacred and fragile. There was no "let me just plug it in and look." A live OS auto-mounts, sees free space, and can TRIM it. Every choice — write blocker, image fast, minimize powered time — assumed the drive could harm itself the moment it was powered on a careless machine.

  5. The triage number sets honest expectations in seconds. A ~7% zero fraction said "the data is there, carve"; a ~78% fraction would have said the opposite. Measuring it up front turned a hopeful conversation into a grounded one before a single hour was billed — the same tool that would have told a different client, kindly, to stop spending money.

Discussion questions

  1. The first shop's statement — "you can't recover an SSD after TRIM" — is true in general. Explain to a non-technical client, in plain language, the one thing that shop failed to check, and why it flipped the outcome.

  2. The lab deliberately imaged the drive through its own cheap enclosure rather than a faster modern adapter. Give the flash-specific reason that was the right call, and describe what a UASP-capable adapter might have done on connection.

  3. The MX500 is itself an RZAT drive — it would zero a trimmed range. Reconcile that fact with the successful recovery. What had to be true about the drive's history, not its capabilities, for the data to survive?

  4. ⭐ Suppose that, before bringing the drive to you, the client had taken the first shop's advice that it was hopeless and, to "wipe it before donating the drive," had connected it to her Windows laptop and run a quick format. Walk through what would likely have happened at the bridge and the controller, whether your recovery would still have succeeded, and how you would explain the difference between "deleted while behind a non-TRIM bridge" and "formatted while connected to a TRIM-passing path."

  5. This was a recovery job, so the deliverable was simply the files. If this had instead been evidence — the same external SSD in a workplace-misconduct matter — name two things you would have had to do differently in acquisition and documentation, and one thing that would have been identical.