Data Recovery Case File · Enterprise Systems · Application-Consistent Recovery

The files came back; the documents didn't: a SharePoint document store, recovered at the layer where it actually lives

This enterprise enquiry arrived mid-story, which is common, and mid-story at the most instructive possible point. A SharePoint farm used a third-party product to externalise its document contents — the actual files living as BLOB cache data on a ~2TB disk within a VMware-hosted server. Those BLOB files had been deleted "somehow"; the IT team ran recovery software, got 241GB back, and copied files into their original paths — and the affected documents still wouldn't open in SharePoint. Their conclusion was that the recovered files were corrupt. The truer diagnosis is subtler, and it's the reason this page exists: they had recovered files, when what the system needed was its data. Their two closing questions — a quote, and "whether your quote comes with any assurance" — both get straight answers below.

Why "recovered" files failed in the application

A BLOB-externalised SharePoint doesn't treat those cache files as documents; it treats them as the far half of database records — every externalised file paired to entries in the content database that know its identity, its exact location, its size and its integrity. That marriage is why the DIY round fell short in two stacked ways. First, fidelity: undelete software working through a live server's filesystem reconstructs deleted entries as best it can, and on a volume that kept operating after the deletion — new writes landing where freed blocks lay — some fraction of what it resurrects is subtly wrong: truncated, cross-linked, or stitched from reused space. A human double-clicking such a file might not notice; a database checking its ledger notices instantly. Second, consistency: even perfectly recovered content copied back as new files doesn't automatically re-marry the database's expectations. The application's verdict — "won't open" — was therefore not stubbornness but the system doing its job: refusing halves of records that no longer agree. And one more cost had accrued silently: the recovery-and-copy-back activity itself wrote heavily to the very volume holding the deleted originals, spending free space the proper recovery would need.

The recovery, run at the right layer

The correct venue was the one their final sentence had already identified: the virtual disk. The VM's disk was secured at the datastore level and imaged — one artefact containing the whole story: the guest filesystem, the surviving deleted BLOB structures, and the free space where original content still lay — and all work ran offline on that image, where nothing live could write another byte. From it, the deleted BLOB population was reconstructed properly: filesystem records mined for the deletion event's true casualties, content carved and validated against the database's own ledger — each candidate checked for the identity and integrity the application would demand, so nothing went back that SharePoint would spit out. The reconciled set was restored in coordination with their team at the application layer, database and store agreeing again; the shortfall — content genuinely overwritten during the post-incident weeks of live operation and DIY activity — was itemised by document, not left to be discovered one failed click at a time.

Outcome — and the "assurance" question, answered as asked

The substantial majority of the deleted document population returned as working documents, verified through the application rather than the file manager, with a written report closing the incident. And the assurance question deserves its plain public answer, because enterprises are right to ask it: no honest laboratory guarantees outcomes before assessment — data that's been overwritten is gone, and anyone promising otherwise is selling the promise, not the data. What a quote here does carry, in writing: free assessment first; a fixed figure tied to a stated scope; no recovery, no fee; and verification defined the way this case demanded — success measured in the application, not in file counts. For the wider IT audience, the two-line moral: deleted application data is a stop-writes incident on the volume, immediately — and recovery that ends at "the files are back" has ended one layer too early.

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.