Data Recovery Case File · NAS & Network Storage · The First Hour Matters
Take the Share Offline Before Anything Else
His enquiry describes a deletion across a working system that other people are still using. An archive share on a server: "one folder has had over seven subfolders deleted and there is no backup. Additionally, some other files have been deleted throughout the archive share. The files comprise many scanned images and documents." A live share is being written to continuously by everybody connected to it — and that, rather than the deletion, is what determines how much comes back.
| Media | Server archive share on a Linux filesystem — multiple subfolder trees and scattered individual files deleted; no backup available; share in continued use |
| Reported situation | Archive share holding thousands of scanned image and document files · more than seven subfolders deleted from one folder · additional individual files deleted across the share · no backup in existence · share remaining in service |
| Fault class | Deletion on a journaling filesystem with continued write activity — extent tree removal complicating reference recovery; signature carving the primary route |
| Equipment used | Share taken offline before any recovery step · snapshot and versioning sources established first · volume imaged write-blocked before any carving · signature carving across unallocated space · recovered documents validated by rendering and reconciled against folder records |
The decode: the two things that matter, in order
First — stop the writing, and this is more urgent than anything technical. A share in service is being written to constantly: by the server's own logging, by indexing, by every user saving a file, by any process that touches it. Deleted content survives only until something is written over it, and a live share is generating exactly that, continuously, while the enquiry is being written.
Why that outranks the recovery method: no technique recovers content that has been overwritten. An hour of continued service can cost more than any choice of tooling saves, and taking the share read-only or offline costs nothing but inconvenience.
Second — check for snapshots before assuming there is no backup. He says there is none, and that may be true of deliberate backups while missing something else entirely. Many server filesystems and storage layers keep automatic point-in-time copies that nobody configured and nobody remembers, retained for days or weeks. If one exists from before the deletion, the entire case is a file copy.
Why that check comes before anything else: it is free, it takes minutes, and it either solves the problem completely or eliminates the possibility.
What makes recovery harder on this kind of filesystem: deletion does not merely mark an entry unused. On modern Linux filesystems the records describing where a file's content lives are cleared as part of the deletion — so the usual approach of restoring a reference no longer works, because the reference has been emptied rather than flagged.
Why the file types are nevertheless favourable: scanned images and documents both begin with distinctive byte sequences and have recognisable structure. They are among the most reliably carvable formats there are, so content can be recovered directly from unallocated space without needing the filesystem's help at all.
What carving will not return: names and folder structure. Recovered files come back organised by type rather than as they were, which for thousands of scanned documents is a real practical problem — and it is why the folder records, where they survive, are worth reconciling against.
What to establish alongside: when the deletion happened and by what route. A deletion that occurred an hour ago and one that occurred last month are quite different prospects.
On the bench
The share was taken offline before any recovery step — deleted content surviving only until overwritten, and a live share generating writes continuously through logging, indexing and ordinary use. Snapshot and versioning sources were established first, automatic point-in-time copies frequently existing without having been configured deliberately. The volume was imaged write-blocked before any carving, with signature carving across unallocated space — modern Linux filesystems clearing the records describing content location on deletion, which defeats reference restoration while leaving carvable content intact.
The outcome
The share taken offline first, snapshots checked before any technical work, and content carved from a write-blocked image. 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: take the share offline now — that matters more than any choice of method, because deleted content survives only until something writes over it and a live share writes constantly. Then check for snapshots, which many systems keep without anybody arranging it.
Files deleted from a share people are still using
Take it offline or read-only right now — that single step matters more than any recovery technique, because deleted content survives only until something writes over it, and a share in service is generating writes continuously through logging, indexing and every user who saves anything. Then check for snapshots before accepting that there's no backup: many server filesystems and storage layers keep automatic point-in-time copies that nobody configured and nobody remembers, and one from before the deletion turns this into a file copy. Worth knowing that modern Linux filesystems clear the records describing where content lives, so scanned documents are recovered by signature rather than by reference — which loses names and folders.
Take it offline first — then call Oxford Data Recovery on 01865 593000; snapshots established before any technical work, volume imaged before carving, output reconciled against surviving folder records.
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.