A twelve-disk RAID 10 was initialised during routine maintenance. That single action wiped the RAID metadata, and DiskStation Manager promptly lost sight of every virtual machine and database on it. The data came back — and the reason it could is the thing worth taking away from this page.
← All case files · from £500 + VAT
The damage was self-inflicted, during RAID maintenance: a twelve-disk RAID 10 got initialised. DSM restarted with no configuration to show — the logical layer had vanished, taking with it all visibility of the virtual machines, databases and working documents the business depended on. Nothing was backed up.
Of all the words in a NAS or RAID menu it’s the one to fear most, and it sits cheek by jowl with perfectly innocent options.
Here’s the part that made the job winnable, and it repays understanding. Initialising an array usually lays down new RAID headers and stops there — it leaves the data region alone. So what actually gets wiped is the description of how the disks interlock; the stripes, the genuine blocks of your genuine files, remain on the platters exactly as they were.
Destroy the map and the territory is still there. Recovery then comes down to reconstructing the geometry from the data that survived — demanding, but wholly achievable. The thing that would have made it impossible is the obvious next step: allowing the NAS to run the full initialise-and-resync through to completion, which is the point at which it begins overwriting the data region.
leaving DSM with no array it could recognise.
scattered across all twelve disks, just no longer described anywhere.
which is why nothing could rebuild on its own.
Every one of the twelve disks was cloned read-only before anything else, so the surviving data was safe from any further change, and the entire rebuild ran on those clones. With no headers left to consult, we derived the RAID 10 layout straight from the data on the disks — establishing the stripe size, the order of the members and which pairs mirrored each other — then built the array virtually to that recovered design and mounted the file system to pull everything off. Not a byte was written to the originals.
With the geometry reconstructed, the volume was reassembled from the clones and the virtual machines, databases and working files all came back.
An overwrite that touches only the metadata sits among the more recoverable of the serious failures, exactly because the data region is untouched. The single thing that governs the result is how much got written after the slip. Powered down at once, the array is in good order; left running a resync through the night, or rebuilt into a new volume with data copied back on, it becomes a wholly different and far bleaker prospect.
The instant it lands that you’ve initialised, formatted or rebuilt the wrong thing, cut the power. Don’t shut it down nicely — a clean shutdown flushes the writes still in the queue. Yank it.
And then keep it off. Every extra minute powered up is the NAS faithfully finishing the job you gave it, and all that stands between you and your files is how little of that job it got through.
One more thing, before you ever touch a live array for maintenance: photograph the bays. It’s free, and it spares us solving a variable we’d otherwise have to work out.
Drop the drive at our Guildford Business Park reception, or post it to us — it costs nothing to find out what happened. You get a written figure from the fixed bands before any work begins.