Data Recovery Case File · Formatted & Logical Faults · Verify First, Act Second
The Second Step Was the Damaging One
His enquiry describes a sequence with a hinge in the middle. "I accidentally deleted the wrong volume while trying to add additional drives to a storage pool. I then set the drives back up into a new pool before discovering my backup was incomplete and I was missing data. I turned the machine off and removed the drives." The first step was recoverable and the third was exactly right. The second one happened because he believed something he had not yet checked.
| Media | Multiple drives from a server storage pool — original pool volume deleted in error; drives subsequently reconfigured into a replacement pool; machine powered down and members removed |
| Reported situation | Storage pool being expanded with additional drives · incorrect volume deleted during that operation · drives reconfigured into a new pool immediately afterwards · backup subsequently found to be incomplete · machine powered down · drives removed from service · original content required |
| Fault class | Volume definition removal followed by pool metadata replacement — original layout partially overwritten; extent of new pool writing determinative |
| Equipment used | New pool write extent measured against member capacity before any conclusion · all members imaged individually write-blocked · original pool metadata located from surviving regions · volume assembled offline and structures rebuilt from surviving copies |
The decode: three steps, and which one cost
The first step, deleting the wrong volume: among the more recoverable mistakes there is. Deleting a volume removes a definition — a record saying that a region of storage contains a filesystem — and marks the space as available. It does not visit the content, which sits exactly where it was, describable again as soon as the definition is reconstructed.
Why that would have been straightforward: with the drives untouched, the original pool's metadata is still present on them, the filesystem is still present within it, and the reconstruction is a matter of reading what is there.
The second step, creating a new pool: this is the one that cost. Pool creation writes fresh metadata to every member, describing a new arrangement, and depending on the implementation it may also initialise regions or write a new filesystem. So the record of how the previous pool was arranged — the thing a reconstruction reads — is precisely what was written over.
Why he did it, and this is the general point: he believed he had a backup. Acting on that belief was reasonable and the belief was wrong, and he found out in the wrong order. Verifying the backup takes minutes; rebuilding a pool takes minutes; and doing them the other way round would have cost nothing at all.
Why that sequence is worth naming as a rule: verify the backup before acting on the assumption of one. Not after. This archive contains a large number of cases where the destructive action was taken confidently because a backup was believed to exist, and the belief was tested only once it mattered.
The third step, stopping: powering down and removing the drives was correct and probably decisive. A pool left running writes continuously — logs, indexes, metadata updates — and every hour of operation lands more data on the regions holding the previous contents.
What is likely recoverable: new pool metadata is a bounded quantity, so the great majority of the members' surfaces are untouched. Where the new pool was created and immediately abandoned, the original filesystem structures frequently survive substantially intact — and where they do not, content is carved directly from the images.
On the bench
New pool write extent was measured against member capacity before any conclusion — pool creation writing fresh metadata to every member and potentially initialising regions, which is a bounded quantity leaving the majority of each surface untouched where the pool was abandoned promptly. All members were imaged individually write-blocked, original pool metadata located from surviving regions, and the volume assembled offline with structures rebuilt from their surviving copies.
The outcome
The new pool's write extent measured first, every member imaged, and the original layout recovered from surviving regions. 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: deleting the volume removed a definition rather than content, and would have been straightforward. Creating the new pool wrote fresh metadata over the record of the old arrangement. Powering down when you did was right and probably decisive.
Before acting on the assumption that you have a backup
Check it first — open several files from it and confirm they render. That single habit is the difference between a recoverable mistake and a serious one, because a great many losses in this field happen when somebody takes a destructive step confidently on the strength of a backup they hadn't verified. Deleting a volume in error is among the more recoverable things you can do: it removes a definition saying a region holds a filesystem, and never visits the content. What costs is what you do next. Rebuilding a pool writes fresh metadata to every member, over the record of how the previous one was arranged. Stopping and removing the drives was the right call.
Keep the drives out — call Oxford Data Recovery on 01865 593000; write extent measured against capacity, every member imaged individually, original layout recovered from surviving regions.
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.