Data Recovery Case File · NAS & Network Storage · The Order of Two Actions
Verifying a Backup Before Destroying the Original Is the Whole of the Procedure
His enquiry sets out a sequence in which every step was reasonable and the order was not. A three-drive storage pool deleted deliberately, "thinking I had a complete backup", then reconfigured into a new pool with additional drives — and only then, "went to copy data from the backup to discover my backup wasn't complete." He stopped immediately and pulled the drives, which is the reason there is a case at all.
| Media | Three-drive storage pool on a server platform — pool deleted deliberately and members reconfigured into a new pool with additional drives; machine powered down and members removed on discovery |
| Reported situation | Storage pool deleted by the administrator · backup understood at the time to be complete · original members reconfigured into a new pool alongside additional drives · backup subsequently found to be incomplete · machine shut down immediately on that discovery · drives removed and retained · recovery of the original pool content sought |
| Fault class | Pool metadata replaced by reconfiguration — original layout descriptors overwritten with content regions largely retained; recoverability governed by writing performed after the new pool was created |
| Equipment used | Prompt shutdown credited as bounding the damage · each member imaged individually write-blocked before any interpretation · original pool geometry reconstructed from residual metadata and content patterns rather than from the platform · original volume assembled offline from the images · content carved by signature where structures did not reconcile |
The decode: what deleting a pool does, and what the reconfiguration cost
What deleting a storage pool actually removes: the description. The platform writes a small set of descriptors recording which drives belong to the pool, how data is distributed and where each portion sits — and deletion removes those.
Why that alone would have been recoverable: the content stays. Terabytes of data are not erased by removing a few kilobytes of description, and the layout can be reconstructed from what the members themselves contain.
What the reconfiguration did that deletion had not: wrote new descriptors. Creating a pool marks the members as belonging to it and writes fresh metadata across each, which lands on the regions the old descriptors occupied.
Why that is worse but not fatal: the new metadata is also small. It replaces the old description without touching the great majority of each drive.
Why the additional drives matter to the reconstruction: the new pool has a different membership and a different geometry. The original arrangement cannot be inferred from the current one, so it is derived from the members' own content instead.
How that derivation works: by pattern. Data distributed across members leaves recognisable structure — repeating boundaries, filesystem markers at predictable intervals — from which the original stripe arrangement and member order can be established.
Why his shutdown is the decisive action in the whole account: a new pool begins using its space. Had he copied the incomplete backup onto it, or left it running to synchronise, the content regions would have been consumed.
Why pulling the drives was right as well: it stopped any background activity. Storage platforms perform maintenance on their own schedule, and a powered pool is never entirely idle.
What the honest limit is: whatever the new pool wrote is gone. Anything landing in the same regions cannot be recovered, and the extent is established from the images rather than estimated.
What the procedural lesson is, in one line: restore from the backup to somewhere else, and confirm it, before deleting anything. A backup is not verified until something has been read back out of it.
On the bench
Prompt shutdown was credited as bounding the damage — pool deletion removing only the descriptors recording membership, distribution and placement, while reconfiguration writes fresh metadata across each member, replacing the old description without touching the bulk of the drives. Original geometry cannot be inferred from the new pool and was instead reconstructed from residual metadata and content patterns — repeating boundaries and filesystem markers at predictable intervals establishing stripe arrangement and member order.
The outcome
Prompt shutdown credited as bounding the damage, each member imaged individually, and the original volume assembled offline from the images. Free assessment, one fixed written figure including VAT, charged per drive, with 50% of parts and labour upfront where a drive has to be opened. The decode: deleting the pool removed the description and not the data. Reconfiguring wrote a new description over the old one — and shutting down when you did is what stopped the new pool consuming the rest.
Before you delete a pool or an array
Restore from the backup to somewhere else and confirm it opens, before destroying anything — a backup isn't verified until something has been read back out of it, and "I thought I had a complete backup" is the commonest sentence in this kind of case. If it has already happened, do what you did: shut down immediately and pull the drives. Deleting a pool removes only the small descriptors recording its layout, and reconfiguring writes new ones over them, but the content itself survives until the new pool starts using the space.
Shut it down and pull the drives — call Cambridge Data Recovery on 01223 655015; members imaged individually, original geometry reconstructed from content patterns, volume assembled offline.
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.