Data Recovery Case File · Business Servers · Targeted Recovery

Everything recovered except the folder that mattered: SQL backups stranded on a dead OS drive

The business had handled its server failure with real competence: when the OS drive on their Windows Server 2012 Essentials machine died, their own people recovered all the company data from the separate data drives, planned the replacement server, and audited what was missing. The audit found exactly one casualty — and it was the sharpest possible one. Their vehicle-maintenance system's SQL database backups, which the software vendor should have directed to the data drives and onward to the cloud, had been quietly writing to a folder on the OS drive all along. The drive that died was the drive holding the safety copies.

The enquiry

“Our OS hard drive has failed on our server running Windows Server 2012 Essentials. I've recovered all of our data except a backup folder which was located on the C: (OS) drive, not the data drives — it's from our vehicle-maintenance software, where the data is stored in SQL and is supposed to back up to the data drives for further cloud backup. This has been a big mistake by the software provider. We're replacing the server anyway — can you recover this backup folder from the failed drive?”

A small target on a hostile surface

Tightly-scoped business jobs like this are welcome and slightly deceptive: "one folder" still means taming the whole drive first, because a degraded disk doesn't take requests — but the scope transforms the imaging strategy. On the TaskForce 2, the failed system drive was imaged with the error-tolerant discipline its condition demanded, and with its priorities inverted from the usual: the filesystem's map was read early, the extents behind the target folder located, and those regions pulled to the front of the queue and secured while the drive gave its best reads — the Windows installation, the page files, the gigabytes of operating system nobody would ever miss relegated to whatever the later passes could gather. The target sat almost entirely on willing surface; it came across early and clean.

Verifying backups as backups

Then the step that separates delivering files from delivering an outcome. A folder of SQL backup sets isn't verified by existing — it's verified by being restorable, and a business about to stand up a new server deserved to know before the courier left, not after the vendor's re-import failed. Each recovered backup set was checked for structural integrity and internal consistency — complete, coherent, spanning the expected dates up to the drive's final healthy days — and the freshest sets flagged for the vendor's restore, with the honest caveat properly stated: the last backup predates the failure by its scheduled interval, so the tail-end of recent entries would need re-keying from paper. They knew their gap to the hour, in writing, before rebuilding began.

Outcome — and the audit finding, gift-wrapped

The folder recovered whole, the backup sets verified restorable, the new server seeded, the business's records continuous but for a known, bounded sliver. And the finding their own enquiry had already drafted, formalised for the file they'll show the vendor: backups that live on the machine they protect are not backups — they're optimism with a folder name. The configuration error here put the safety copies on the single most failure-prone drive in the building, one hop short of the data drives and two short of the cloud, and only a lab visit closed the gap. The fix costs nothing: point the backup path where the design said, and once a quarter, restore one set somewhere and watch it open. A backup nobody has ever restored is a hypothesis.

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.