Data Recovery Case File · NAS & RAID · Logical / Overwrite

Synology data recovery after a new DSM install: two 8TB IronWolf Pros, one missing migration prompt

This is the most common serious NAS accident we see, and it doesn't involve anyone dropping anything. A unit fails, a replacement arrives, the drives go in — and instead of the promised migration, the new system initialises. The customer here did two things that materially improved his outcome, and one thing that nearly cost him his largest folder.

The enquiry

“My Synology had a power supply failure and I was told to buy a replacement unit. I should have had a migrate option when I put my two 8TB IronWolf Pro drives in — it wasn't there, and it set them up as a new NAS. The files are clearly still there: at one point it let me download folder by folder, and I got some data off that way. But the biggest folder now won't open. I'm pretty sure the more I try to fix it, the harder I'm making the job.”

That last sentence is the one that mattered. He stopped. Not everyone does.

What a "new NAS" setup actually overwrites

When DSM initialises drives, it isn't erasing eight terabytes — it's rewriting the small structures that define them: partition tables, the RAID metadata that describes how the members form an array, and fresh, empty filesystem structures at the head of the data volume. The bulk data extents — the terabytes of actual file content — are untouched at that moment. That's why his files were briefly visible and downloadable: enough of the old structure had survived, or been re-adopted, for partial access. But a re-initialised volume is a demolition site with the lights still on. Every boot, every index rebuild, every downloaded folder had the new system writing housekeeping into space the old volume considered its own — and the growing damage is precisely why the largest folder went from listed-and-openable to listed-and-dead.

The recovery

Rule one in any overwrite case: the patient stops being a computer. Both IronWolf drives were imaged in parallel on the Atola TaskForce 2, write-blocked, and the originals shelved; sixteen terabytes of member images became the only thing anyone touched.

Reconstruction then ran in Data Extractor's RAID tooling against the images. The new install's partition and array metadata described the wrong, empty world, so it was disregarded; the old volume was recovered by locating its structures directly — identifying the original data-partition geometry, confirming the two members' mirror relationship, and assembling a virtual volume from the image pair. On that virtual volume, the old filesystem's surviving metadata trees were located and walked. Where the new system's writes had punched through — including the region behind his largest folder's index — recovery shifted from reading directory structures to reconstructing them: rebuilding the folder's contents from deeper metadata copies and, for the fraction where no metadata survived, signature-level recovery of the underlying files with names lost but content intact.

Outcome

The overwhelming majority of the volume was recovered with structure and names, including nearly all of the critical largest folder; a small remainder came back as content without original filenames, and a smaller remainder still — the blocks the new DSM had physically reused — was gone, as overwritten data always is. Both of the customer's good instincts paid: stopping early limited the overwrite, and being able to tell us which folder mattered let verification concentrate where it counted.

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.