Data Recovery Case File · Trust, Practice & Honest Limits · An Audit Before a Recovery
Finding Every Damaged File Is a Separate Job From Repairing Any of Them
This business enquiry asks for two things and the first is the larger. Some image files found to be corrupted and inaccessible, held both on cloud storage and on two drives supplied by a previous technology provider as a backup — with a quote sought "for identifying all corrupted files in the drive and restoring these." Identifying them is an audit, and it has to happen before anyone can say what restoring would involve.
| Media | Organisational image collection held on cloud storage and duplicated across two backup drives supplied by a previous provider — an unknown proportion of files reported as corrupted |
| Reported situation | Business image files found to be corrupted and inaccessible · files held on cloud storage · files also held on two drives provided by a previous technology supplier as a backup · number of affected files unknown · identification of all corrupted files requested · restoration of affected files requested |
| Fault class | Corruption of unknown extent across replicated copies — validation required before scope can be established; synchronised copies potentially replicating the same damage |
| Equipment used | Validation performed as a discrete stage before any restoration scope was quoted · every image file opened and decoded to completion rather than checked by header alone · results cross-referenced across the cloud copy and both backup drives · files differing between copies identified as recoverable from the intact instance · residual set assessed separately for internal repair |
The decode: how corruption is found at scale, and why three copies may not be three chances
Why the extent is unknown: corrupt image files do not announce themselves. They sit in folders with correct names, plausible sizes and correct dates, and only fail when something tries to display them.
Why a listing cannot answer it: nothing visible from outside a file indicates whether its contents decode. Size, date and name are all metadata and all intact, which is exactly why the problem was noticed late.
How the audit is actually performed: every file is opened and decoded to completion. Checking only the opening of a file is not sufficient, because damage frequently sits partway through and a header-only check reports it as sound.
Why decoding fully is the only reliable test: an image that renders to its last row is intact; one that stops partway is not. That is a definitive answer per file, and it produces a list rather than an estimate.
Why the three copies must be compared rather than trusted: synchronised storage replicates faithfully. If a file was already damaged when it was uploaded, the cloud copy is damaged too — the service copied what it was given.
Why that is the crucial point for an organisation: having three copies feels like three chances. Where the corruption predates the copying, it is one damaged file in three places, and none of the copies helps.
Why comparison is nonetheless the first thing tried: where copies differ, one may be intact. A file damaged after being backed up will have a sound counterpart on the drives, and that is a direct restoration rather than a repair.
Why the two backup drives are worth checking separately: they were supplied by a previous provider and may hold different points in time. Two backups taken at different dates give two chances at a pre-damage state.
What remains after all that: files damaged in every copy. Those are assessed individually for internal repair, with partial recovery frequently possible where the damage sits late in the file.
What the audit is worth beyond this incident: it establishes when the damage occurred. A cluster of files damaged within one date range points at a specific event or device, which is more useful to the organisation than the file list itself.
On the bench
Validation was performed as a discrete stage before any restoration scope was quoted — corrupt image files retaining correct names, plausible sizes and correct dates, so nothing visible from outside indicates whether contents decode, and header-only checking reports files sound where damage sits partway through. Every file was opened and decoded to completion, and results cross-referenced across the cloud copy and both backup drives, synchronised storage replicating damage that predates upload.
The outcome
Validation performed as a discrete stage, every file decoded to completion, and results cross-referenced across all three copies. Free assessment, one fixed written figure including VAT, quoted separately for validation and for restoration. The decode: identifying them is the larger half. Corrupt images keep their names, sizes and dates, so only full decoding finds them — and where damage predates the upload, three copies are one damaged file in three places.
Auditing a collection for corrupted files
Treat identification and restoration as two jobs and quote them separately, because the extent has to be known before the second can be scoped. Insist that every file is decoded to completion rather than checked at its header, since damage often sits partway through and a header check reports those as sound. Don't assume three copies means three chances: synchronised storage replicates faithfully, so damage that predates the upload exists in the cloud copy too. Where copies differ, restoration is direct. And note when the damage clusters, since that points at a cause.
That is an audit first — call Manchester Data Recovery on 0161 871 0788; validation performed as a discrete stage, every file decoded to completion, results cross-referenced across all copies.
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.