Data Recovery Case File · Trust, Practice & Honest Limits · A Copy in the Same Place
A Backup Stored Beside the Original Protects Against Mistakes and Not Against the Disk
This enquiry contains a detail offered almost apologetically and it is the crux. A drive not found by the machine's firmware and not booting, holding a property management database, where "a backup was purportedly made last Friday but only to the same drive." That backup is real and it is on the failed disk — which means there are now two copies of the database to recover rather than one, and both share the same fate.
| Media | 320GB hard drive not detected by host firmware — holding a property management database and a recent backup of that database written to the same volume |
| Reported situation | Hard drive not found by the machine's firmware · machine consequently not starting · drive tested as a secondary device in a second machine · property management database held on the drive · a backup reported as taken days earlier · that backup written to the same drive · recovery required |
| Fault class | Device-level failure with primary and backup copies co-located — two recoverable targets on one failing volume; application-level integrity required beyond file recovery |
| Equipment used | Backup co-location identified as providing a second target rather than a separate source · current draw measured across the start-up cycle on a controlled bench supply · imaged write-blocked under strict per-sector timeouts with database and backup regions taken in priority · both copies extracted and compared · database integrity verified by opening in its own application before delivery |
The decode: what the co-located backup is worth, and what it is not
What that backup does not protect against: the drive. A copy written to the same disk shares every hardware risk the original faces, so a drive failure takes both at once.
Why it was nonetheless worth making: it protects against the commoner dangers. Accidental deletion, a corrupted record, a bad update or a mistaken change are all recovered from a copy in the same place, and those happen far more often than disks fail.
Why that is worth saying rather than treating as an error: a same-disk backup is not useless, it is incomplete. It covers the failure modes it was designed for and not this one, which is a gap rather than a mistake.
What it genuinely offers here, and it is a real advantage: a second copy of the same data in a different place on the surface. Damage affecting the live database may not affect the backup file, and vice versa.
Why that improves the odds materially: the two copies occupy different regions. Localised surface damage that ruins one may leave the other complete, which is genuine redundancy against everything except total device failure.
Why both are captured in priority: they are the objective. Locating the database and the backup and imaging their regions first spends a failing drive's reading where it matters.
What makes this harder than ordinary file recovery: a database must open in its own application. Returning the file is not sufficient if the application refuses it, because a database carries internal consistency requirements a photograph does not.
Why that raises the standard for success: a partially recovered document is partly useful. A partially recovered database frequently opens with nothing missing visible, or refuses to open at all.
Why verification therefore has to be part of the work: the file is opened in the application before it is delivered. Anything else leaves the customer to discover the problem.
What should change afterwards, and it is one sentence: the same backup, written to a different device, would have made this an inconvenience. The routine was right and the destination was not.
On the bench
Backup co-location was identified as providing a second target rather than a separate source — a copy on the same disk sharing every hardware risk the original faces while genuinely protecting against deletion, corruption and mistaken changes, which are commoner than device failure. The two copies occupy different surface regions, so localised damage affecting one may leave the other intact. Database integrity was verified by opening in its own application before delivery.
The outcome
Co-location identified as a second target, database and backup regions captured in priority under capped timeouts, and integrity verified in the application before delivery. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: that backup was not wasted effort. It protects against deletion and mistakes, which happen more often than disks fail — and here it gives a second copy in a different place on the surface.
A backup written to the same disk as the original
Keep making it and change where it goes — the routine is right and the destination isn't. A copy on the same disk genuinely protects against deletion, corruption and bad updates, which happen far more often than drives fail, so it isn't wasted. It just doesn't cover the one thing that's happened. If you're recovering now, say where both the database and the backup sit so their regions can be captured first, and insist the file is opened in its own application before delivery — a database can come back looking complete and still refuse to open.
It is still worth recovering — call Manchester Data Recovery on 0161 871 0788; co-location identified as a second target, both regions captured in priority, integrity verified in the application before delivery.
Request a quote online →
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.