A business tried to expand the volume on a 4-bay Synology RAID server, the operation failed part-way, and afterwards DSM couldn’t mount the volume at all — business documents and project files stranded. A resize touches every layer of the storage stack at once, and an interrupted one leaves those layers out of step. The disks were fine; we imaged them, reconciled the layers offline, and recovered everything.
A business ran its shared storage on a 4-bay Synology holding company documents, financial records and live project files. Needing more room, they started a volume expansion — a routine operation on paper — but it failed before completing. Afterwards, DSM (DiskStation Manager) no longer detected the volume, files appeared missing or fragmented, and the RAID would not mount. With the whole company’s working data at stake and the risk that further DIY attempts would make the fragmentation worse, they stopped and sent the unit to us.
To understand why a failed resize is so disruptive, it helps to know that a Synology volume isn’t one thing. It’s a stack of three:
1. The RAID layer. The disks are combined into a Linux software RAID (mdadm) — in Synology’s SHR this can even be several RAID regions layered together — providing the redundancy.
2. The LVM layer. On top of the RAID sits LVM (the Logical Volume Manager), which carves the RAID space into flexible logical volumes and is what makes ‘expand the volume’ possible in the first place.
3. The file system. On top of LVM sits the actual file system — Btrfs or ext4 — which holds your folders and files.
Your data physically lives in that top layer, but it can only be reached if all three layers agree with each other about sizes and boundaries.
Expanding a volume isn’t a single action — it’s a coordinated resize of all three layers in turn: grow the RAID, grow the LVM volume, then grow the file system to fill it (a shrink runs the same steps in reverse). Each step rewrites size and boundary metadata. If the process is interrupted — a power blip, an error, a disk hiccup — the layers are left out of step: the LVM might believe the volume is one size while the file system still describes another, or the RAID boundaries no longer line up with what LVM expects. DSM sees a volume whose layers contradict each other and, unable to make sense of it, refuses to mount — even though the file data itself is almost entirely intact underneath. That inconsistency, not lost data, is the fault.
The temptation is to ask DSM to repair or to run the resize again to ‘finish the job’. On an already-inconsistent volume that’s dangerous: another in-place metadata operation, run over a stack that’s already contradictory, can overwrite the structures that still describe where your data is and turn a recoverable state into an unrecoverable one. So the resize was left exactly where it had stopped. Every disk was removed and imaged, and the whole stack was rebuilt on a separate system where nothing we did was ever written back to the originals.
All four disks were imaged sector by sector to healthy storage, write-blocked; a health check confirmed no mechanical faults and no significant bad sectors, consistent with a purely logical failure. Working from the images, the layers were rebuilt and reconciled from the bottom up: the mdadm RAID was reassembled read-only and its geometry confirmed by analysis; the LVM metadata was examined to establish the volume’s true extent; and the Btrfs file system was then repaired against that, resolving the mismatch the failed resize had left between what LVM claimed and what the file system expected. Btrfs keeps multiple copies of its core trees, which gave several consistent reference points to rebuild from.
With the layers back in agreement, the file system mounted read-only and the company’s data came back in its original structure — documents, financial records, client project files, reports and archives — each checked for completeness and integrity before sign-off. The full set was delivered on fresh storage so the business could rebuild its Synology and restore without losing a day’s work. The advice we left: never run a volume expansion or shrink without a current backup and, ideally, a UPS, because a resize is one of the few routine operations that puts every layer of your storage in motion at once — and a NAS’s redundancy does nothing to protect you if that operation is interrupted.
Per-disk imaging, write-blocked · offline mdadm RAID reassembly · LVM metadata analysis · Btrfs repair against reconciled volume boundaries, read-only · structured extraction and verification. All work in-house at our Belfast lab.
Don’t retry the expansion or let DSM repair it — power the NAS off and send us the disks for a free, no-obligation diagnostic. A failed resize is usually a logical problem, not lost data. We’ll tell you what can be recovered and put a fixed price in writing before any work starts. We recover Synology, QNAP and other NAS units for businesses across the UK.
Usually not. A failed resize typically leaves the storage layers (RAID, LVM and the file system) out of step with each other, so the NAS won’t mount the volume — but the file data underneath is generally intact. Rebuilding and reconciling those layers offline, from images of the disks, brings the volume back. The key is not to retry the resize in the NAS.
Not if the data matters. Another in-place operation over an already-inconsistent volume can overwrite the very metadata a recovery needs. The safe approach is to stop, image the disks, and reconcile the layers on a separate system where the originals are never altered — which is how we handle it.
No — if anything Btrfs helps, because it keeps multiple copies of its core structures, giving more consistent reference points to rebuild from. SHR is just layered Linux RAID and LVM, which reassembles off the NAS like any other. What matters is imaging the disks and rebuilding the stack correctly, not the specific Synology layout.