Data Recovery Case File · Desktop Drives · Partition Archaeology

Three new partitions over one old volume: recovering 800GB of research data from a repartitioned IronWolf

The enquiry came from a university physics department and carried the habits of the profession: exact hardware identified, the mistake described without varnish, the mitigation already performed, and an honest statement of where his own competence ran out. An 8TB IronWolf holding a single Linux volume with ~800GB of research data had been repartitioned in error — a boot partition, a 70GB volume, and a large remainder written over it — and about a gigabyte of new data saved before the mistake surfaced. He had already cloned the entire disk with dd, and his hypothesis was the correct one: "the data is largely still there; the filesystem indexing has been lost."

What the repartition actually destroyed — bounded precisely

His hypothesis deserved its confirmation with the boundaries drawn in. Repartitioning rewrote the map at the front of the disk and — the part that matters — the new filesystems' formatting wrote fresh structures where their designs demanded: the small boot partition's contents near the disk's start, and the new 70GB volume's skeleton of management structures scattered through its own span, plus his gigabyte of new files within it. Everything else — the overwhelming majority of eight terabytes — was untouched shelving. The complication a Linux volume adds is that the old filesystem's furniture wasn't all in one place either: this filesystem family distributes its records and their redundant copies across the whole disk by design, which giveth and taketh — its primary headers at the front were casualties of the new scheme, while its many backup copies, spread far beyond the overwritten zone, survived to testify. The recovery, in other words, was archaeology with excellent surviving records and a precisely bounded demolition site.

Working from his clone — after auditing it

His dd clone was exactly the right first move and was treated with the respect of verification rather than the courtesy of assumption: spot-hashed against the source drive across sampled regions, confirmed faithful, and adopted as the sole working medium — his original drive powered down for the duration, a second safety his own procedure had made possible. On the clone, in Data Extractor, the original volume was rebuilt: its true boundary re-established, its structure reconstructed from the surviving distributed copies, and the old directory tree rising essentially whole — research directories, names, dates, permissions. The demolition site was then audited file by file: content that had lain beneath the new formatting's footprint and his gigabyte of writes was identified by name, so the loss report was a specific, short list rather than a percentage — and the list, when it came, was as small as the arithmetic promised: a fraction of a percent of the 800GB, most of it recoverable in content from the volume's redundancy even where its primary copy had been struck.

Outcome

The research data delivered effectively complete, with an itemised account of the near-misses — to a customer whose own two decisions had authored the result. Cloning before asking preserved every option; stopping after one gigabyte kept the demolition footprint measurable in decimals. For everyone else who ever answers a partitioning prompt too quickly: the mistake is survivable in almost exactly the proportion that what happens next is restrained. Stop writing, clone if you're able, and bring the clone — the drive's history can be rebuilt from records far better than nerves ever manage from memory.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.