Data Recovery Case File · NAS & Network Storage · Stop the Resync
RAID Reinitialised by Accident: What Survives
His enquiry described one wrong click and a great deal riding on it. A QNAP NAS with eight 8TB disks in a RAID 10 array: "which I reinitialised by accident and need to recover some files that are very important from the hard drives — about 18TB of data. Can you recover the files please?" The technical answer is genuinely hopeful, because reinitialising an array does far less than the word suggests. But it comes second, because there is something more urgent that has to be said first and cannot wait for the rest of the page: the unit must be powered down immediately. Not shut down carefully, not after a backup attempt — now. Because a reinitialised array does not sit still. It begins synchronising, and every minute it runs destroys more of what is left.
| Media | Eight-bay network storage unit, eight 8TB disks in a mirrored-and-striped array — reinitialised in error; approximately 18TB of data required |
| Reported situation | Array reinitialised accidentally through the unit's interface · original data required · unit's synchronisation state at time of enquiry unknown · large data volume with corresponding logistics |
| Fault class | Array metadata rewritten and fresh filesystem created over intact data — surviving copies at active risk from automatic resynchronisation |
| Equipment used | Unit powered down before anything else · all eight members imaged individually write-blocked (Atola TaskForce 2) · original array geometry derived from the images rather than the new configuration · previous filesystem located and rebuilt offline · contents verified and delivered |
The decode: what reinitialising did, and why the resync is the emergency
What reinitialising actually does: the hopeful part. On a NAS, reinitialising an array rewrites the array metadata — the records describing how the disks are combined — and creates a fresh, empty filesystem on top. What it does not do, in the overwhelming majority of cases, is write across the disks' entire capacity. Eighteen terabytes of data cannot be erased in the seconds the operation appears to take; the operation is fast precisely because it only writes structures. So his files are almost certainly still physically present, sitting underneath a new and empty filing system that claims the space is free.
Why the resync is the emergency: and this is the part that turns a recoverable accident into a loss. A RAID 10 array is built from mirrored pairs which are then striped together. When an array is created or reinitialised, the unit begins synchronising each pair — copying one member over its partner so that both hold identical content. After a reinitialise, what is being copied is the new, empty state. So the synchronisation methodically overwrites the surviving half of every mirrored pair with blank structures, pair by pair, in the background, while the unit sits there looking idle. Before the resync completes, half the members still hold the original data and the recovery is straightforward. After it completes, that redundancy has been used to destroy rather than protect. This is the one situation in this archive where hours genuinely matter, and where the correct action is to pull the power rather than shut down politely.
What recovery involves: all eight disks come out, labelled by bay, and each is imaged individually and write-blocked. The reconstruction then does something specific: it derives the original array geometry rather than accepting the new one — member order, chunk size, mirror pairing and offsets as they were before the reinitialise — and locates the previous filesystem beneath the empty one now sitting on top. That earlier filesystem's structures are usually intact and can be rebuilt, returning folders, filenames and dates rather than a flat carve. It is careful work rather than exotic work, and it is done entirely on copies.
The scale, practically: eighteen terabytes across eight members means imaging time measured in days rather than hours, and delivery media that has to be planned rather than assumed. Both belong in the written figure at the outset rather than appearing later.
On the bench
The first instruction went out before anything else: power removed from the unit, immediately, to halt any synchronisation in progress — the single most valuable action available in this case and one only the owner could take. All eight disks were then removed, labelled by bay, and imaged individually and write-blocked on the Atola TaskForce 2, securing every member before any interpretation. The reconstruction derived the array's original geometry from the images by testing candidate layouts against the previous filesystem's own structures, rather than accepting the configuration the reinitialise had written, and the earlier volume was rebuilt offline from the copies. The contents were verified by opening and delivered on media sized for the recovered set.
The outcome
The unit stopped before synchronisation could complete, all members imaged, the original geometry derived and the previous filesystem rebuilt offline. 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, for anyone who has reinitialised an array by mistake: the operation rewrites the array metadata and creates an empty filesystem — it does not erase your data, which is why it completes in seconds on a volume that would take days to overwrite; the emergency is the automatic synchronisation that follows, because on mirrored pairs it copies the new empty state over the surviving half of every pair while the unit appears idle; so pull the power immediately rather than shutting down carefully; and the recovery works by deriving the array's original geometry and rebuilding the previous filesystem underneath the new one, entirely from images.
Array reinitialised, created or reset by mistake
Pull the power out of the unit now — before reading the rest of this, before trying to copy anything off, and without shutting down politely. Reinitialising rewrites the array's configuration and puts an empty filesystem on top; it does not erase your data, which is why it finishes in seconds on an array that would take days to overwrite. Your files are almost certainly still there. What destroys them is what happens next automatically: the unit begins synchronising the array, and on mirrored configurations that copies the new empty state over the surviving half of every pair, quietly, while the box looks like it is doing nothing. Stopping that is the whole game. Then take every disk out and label its bay position before anything else. Don't let the unit rebuild, don't re-create the array to "put it back", and don't write anything to any member.
Pull the power out now, then call Leeds Data Recovery on 0113 322 3083; every member imaged write-blocked, the original geometry derived, the previous filesystem rebuilt 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.