Case Study 1 — The Clicking Drive and the Dozen Power-Ons

A wedding photographer's only working copy of three years of shoots begins to click. What happens between the first click and the drive reaching a clean-room lab determines how much comes back. This is a recovery story, and a cautionary one: the drive was recoverable, but it was made less recoverable by good intentions.

Background

The drive was a 2.5-inch Seagate ST1000LM035, 1 TB, the kind that lives in an external enclosure on a desk and gets plugged in every working day. It held a photographer's active library — roughly three years of weddings, engagement sessions, and the in-progress edits for two couples whose albums were due that month. The archive workflow, as the photographer put it with a tight smile, "was on the to-do list." There was no second copy.

One Monday it made a sound on power-up: click … click … click-click … pause … click. Windows offered to format it. The photographer declined, unplugged it, and did what almost everyone does — tried again. And again. A computer-savvy nephew was summoned over the weekend; he plugged it into three different machines, tried a different cable, booted into a recovery USB, and at one point started dragging the most recent wedding folder to the desktop "to at least save that one" before the copy stalled at 4%. By the time the drive crossed our counter the following Tuesday, it had been powered on, by the photographer's own count, "a dozen, maybe fifteen times."

The recovery

We did not plug it in. The first step was an interview, not a power-on: model, symptom, and — critically — how many times it had been powered since the trouble started. The answer (a dozen-plus, with a file-copy attempt) told us two things before we touched it. First, this was almost certainly a head problem: clicking that begins and persists, across multiple known-good machines and cables, is the actuator recalibrating because the heads cannot read the servo data. Second, the head budget had been spent hard. Every one of those power-ons asked weak heads to load, seek, and retry; the file-copy attempt was the worst of all, because dragging a folder forces random seeks across the platter — exactly the motion that finishes marginal heads.

We ruled out the cheap stuff for form's sake and for the record: pulled the bare drive from its enclosure, inspected the USB bridge (fine), and confirmed by gentle feel that the spindle was free (it spun up — this was not a seized motor). The clicking reproduced on a bench power supply. That was enough. We did not attempt to image it as-is; a clicking drive does not get a ddrescue session in the open — it gets opened in the clean room, because the heads that are clicking are the heads you must replace before you can read anything.

Inside the laminar-flow clean bench, with the lid off, the diagnosis confirmed itself: one of the two heads showed physical wear, and there was a faint, narrow burnished band on the upper surface — the beginning of a head touchdown. Not a deep gouge, not yet a full crash, but contact. Some of those dozen power-ons had cost real estate.

We sourced a matched donor — same model family, compatible firmware revision, compatible head map — and performed a head-stack swap using head combs to keep the head pairs apart and off the platters during the transfer. Reassembled, the patient went onto a PC-3000 with its Data Extractor module rather than a normal host controller, because swapped heads have a short, uncertain life and we wanted defect-aware, head-by-head imaging under our control, not the OS's:

   PC-3000 Data Extractor — session (paraphrased)
   ─────────────────────────────────────────────
   Drive: ST1000LM035   FW: LCM2   Family: Rosewood
   Heads detected: 0,1 (donor stack installed)
   Head 0: OK    Head 1: ELEVATED ERROR near outer zone -> read last
   Building head map ......... done
   Imaging by heads [0, then 1] ...
     Head 0 surface ........ 100.00% sectors OK
     Head 1 surface ........ 98.7% OK; 1 region UNREADABLE
       ~ LBA 690,180,000 – 690,260,000 (burnished band)
   -> Image complete. 99.61% of LBA space captured.

The unreadable band — the patch the heads had touched during those repeated power-ons — fell across roughly 80,000 sectors. We imaged everything else cleanly, retired the patient drive to a static bag, and did all further work on the image. We hashed the image on creation (sha256sum recovery.img) and recorded the value in the job notes; that hash certifies the image, which is the only stable artifact in the story — the original was changing with every read and is now retired.

Logical recovery (Chapter 6) on the image rebuilt the file system and returned the overwhelming majority of the library intact. For files whose directory entries landed in the unreadable band, we carved by signature (Chapter 7); JPEG and Sony RAW (.ARW) headers and footers let us reconstruct most of them from their bodies in readable sectors. The final tally: about 99.6% of the drive imaged, and at the file level, every wedding fully recovered except one — a session whose images happened to sit, in part, exactly where the burnished band cut across the platter. Of that session, we returned roughly 60% whole, a handful of partially-decoded JPEGs, and an honest list of what was gone.

The photographer cried, mostly with relief. Then we had the other conversation: the one wedding that was partial, and the band on the platter that had grown with the power-ons. We were careful and we were honest — those particular images might well have survived if the drive had been brought in after the first click instead of the fifteenth. Not to assign blame, but because the lesson is the whole point. The job ended with a 3-2-1 backup setup and a standing offsite sync, which is the cheapest data-recovery service we sell: the one that means they never need us again.

The analysis

  1. The interview is part of the diagnosis. Before any power-on, how many times has it been powered since the symptom started is one of the most valuable questions you can ask. It estimates the remaining head budget and often identifies the failure family. A clicking drive that has been cycled fifteen times is a different, worse drive than the same drive cycled once.

  2. Restraint is the technique. Nothing the nephew did was malicious or even unreasonable-sounding to a layperson — and all of it spent a finite, non-renewable resource. The file-by-file copy attempt was the single most damaging act, because random seeks are the worst possible motion for marginal heads. The correct first move for any physical symptom is to stop and image (or escalate), never to "save the important folder real quick."

  3. A clicking drive does not get an open-air imaging attempt. Clicking means the heads cannot read; the fix is replacing them in a clean room before imaging, not running ddrescue against heads that are actively failing. Knowing which tool the situation calls for — and that ddrescue was the wrong one here — is the judgment the chapter is built around.

  4. "Recovered" is rarely 100%, and honesty about the gap matters. A 99.6% image and one partial wedding is a genuine success — and the missing 0.4% is a real loss to the one couple it touches (theme six). The professional deliverable includes an accurate accounting of what did not come back, not a quiet hope the client won't notice.

  5. Physical recovery is the failure of backup. The entire emergency — the clean room, the donor, the PC-3000, the partial loss, the bill — existed only because there was no second copy. The most valuable thing handed back was not the files; it was the 3-2-1 setup that ensures this never happens again.

Discussion questions

  1. The nephew's instinct — "let me at least copy the most recent wedding off" — feels responsible. Explain to a non-technical client, in plain language, why it is one of the most damaging things they can do to a clicking drive.

  2. The lab chose PC-3000 Data Extractor over a host-attached ddrescue session. Give two concrete reasons that was the right call for this specific drive, referencing what had just been done to it (the head swap) and the OS storage stack's behavior on errors.

  3. The hash was taken on the image, and the original was retired. A client asks, "How do I know these are really my files and not altered?" Answer them — and explain what the hash does and does not prove here.

  4. ⭐ Suppose this had been an evidence drive in a forensic matter rather than a photographer's library, with the same clicking symptom and the same history of being powered on fifteen times by a non-examiner before it reached you. What new problems does that history create, what must your report disclose about the head swap and the unreadable band, and how would you defend the recovery's integrity on cross-examination?

  5. Calculate and judge: the imaging captured 99.61% of a 1 TB (1,000,204,886,016-byte) drive. Approximately how many bytes were unreadable, and roughly how many 512-byte sectors does that represent? Would you describe this outcome to the client as "99.6% recovered" or in some other way — and why does the framing matter when one whole wedding is inside that 0.4%?