Synology NAS Recovery Singapore

Synology NAS units layer DSM over SHR (Synology Hybrid RAID) and an advanced filesystem — usually Btrfs, sometimes ext4. When DSM reports a "crashed volume" or a degraded array, the data underneath is typically intact and recoverable, but the DSM interface will offer to "repair" or "reinitialise" — actions that can overwrite what we need.

CBL reconstructs SHR/SHR-2 and the Btrfs/ext4 filesystem directly from the member disks in our lab, so your shared folders and backups come back safely.

Why each of these destroys data

None of these actions look destructive in DSM. Every one of them writes to the member disks, and writing is the only thing that turns a recoverable Synology into a lost one.

• Reinitialise or factory reset. DSM writes fresh partition tables and new RAID superblocks to every disk in the chassis. The record of which slice of which disk belonged where in the array is overwritten in seconds. This is the single most common reason a case comes to us unrecoverable.
• "Repair" the volume onto a replacement disk. A repair starts a full resync that writes parity across the whole array. If a second member had already dropped out quietly, the resync calculates from incomplete data and writes wrong blocks over good ones — across the entire volume, not just the failed disk.
• Running btrfs check --repair or fsck by hand. These rewrite filesystem metadata trees in place. On a damaged Btrfs tree a wrong repair is permanent, and it happens on the original disks rather than on a copy.
• Expanding or migrating the pool after a fault. Synology Hybrid RAID expansion reshapes the array by physically relocating data across every member disk. Starting that on an array that is already unhealthy is the worst possible time.
• Leaving a clicking disk powered in its bay. DSM will keep retrying the failing member for hours. Each retry drags damaged heads across the platters and turns a straightforward head swap into partial data loss.

If the volume is degraded but still mounts, copy your critical folders off now — that window often closes without warning. If it has already crashed, power the unit down and book a free diagnosis.

Warning signs, and what each one usually indicates

A Synology rarely dies without notice. It signals for days or weeks first, usually in ways that are easy to dismiss.

• Long beeps and an amber status LED. A member disk has dropped out of the array. The volume is degraded, not dead — this is the best moment to act, because the data is still readable.
• A bay LED that has gone dark or turned orange. That disk is no longer seen by the controller. Note which bay it is and leave the disk in place until you have labelled it.
• Shared folders vanish, but DSM still logs in. The system partition is fine and the data volume has gone offline. Almost always a volume or filesystem problem, not a whole-unit failure.
• Copies start fast then stall at a few MB/s. One disk is struggling with bad sectors and the array is waiting on every read. Continuing to copy accelerates the failure.
• Storage Manager reports "Volume 1 crashed" or "Storage Pool degraded". Stop here. This is the screen where DSM offers to repair or reinitialise.
• The unit reboots repeatedly or never finishes booting. Often DSM or the system partition, which is mirrored across all disks and separate from your files.
• Clicking, buzzing or a rhythmic tick from one bay. Mechanical failure in that drive. Power the NAS down — this symptom worsens every minute the disk spins.

People describe a failed Synology in a dozen different ways. Whether you searched for Synology data recovery, Synology NAS recovery Singapore, DiskStation recovery or SHR recovery, you are describing the same job: getting shared folders back off a set of member disks. The phrase you use changes nothing. What has already been done to the unit changes everything.

"Synology data recovery" or "Synology repair"?

These two pull in opposite directions, so it is worth knowing which you actually want. Repair means handing you back a working NAS. Recovery means handing you back your files. The fastest way to make a Synology work again is to reinitialise it and create a fresh volume — which is precisely the action that erases what we would otherwise read. We do the second job: image every member disk, rebuild the volume in the lab, and return the data on separate media you keep. If the unit still works afterwards, that is a bonus, not the objective.

"SHR recovery" and "RAID recovery" — the same job with an extra layer

Synology Hybrid RAID is not a new RAID level. Underneath, DSM cuts each disk into matched partition slices, builds standard Linux md RAID arrays across those slices — mirrored on two disks, parity-based on three or more — then joins the results with LVM so drives of different capacities can be mixed without wasting space. SHR-2 keeps two disks' worth of redundancy instead of one. So SHR recovery is RAID reconstruction plus that mapping layer, which is why generic RAID software — which assumes one uniform stripe running across whole disks — usually reads an SHR array as noise.

"Volume crashed", "degraded", "system partition failed"

DSM uses three warnings that sound equally serious and are not:

• Degraded. The pool has lost redundancy but still mounts. Your data is readable right now. Copy what matters off before anything else.
• Volume crashed. Too many members are missing, or the filesystem refused to mount, so the volume goes read-only or offline. Usually still recoverable — and this is exactly the screen where people reinitialise and lose it.
• System partition failed. DSM's own partition, mirrored across every disk, is separate from your data volume. Alarming to read, and on its own harmless to your files.

"DiskStation recovery", "RackStation recovery", "NAS server recovery"

Same lab work in all three cases. A DS-series DiskStation and an RS-series RackStation differ in bay count, expansion options and where they are mounted — not in how the data sits on the disks. For other brands see NAS data recovery, or QNAP recovery if your site runs both.

We work on the whole Synology range, from single-bay home units to rack-mounted arrays with expansion shelves. The model matters less than the layout it created — but a few hardware details change how a case is handled.

• Single-bay DiskStations (DS1xx families). No SHR, no parity — just a Btrfs or ext4 volume on one disk. If that disk has failed, this is a straight hard drive recovery, handled the same way as any external drive.
• Two-bay units (DS220j, DS220+, DS223 and similar). SHR on two disks is a mirror underneath. One healthy member is often enough to rebuild the whole volume, so send both disks even if one is obviously dead.
• Four-bay and larger (DS420+, DS920+, DS1621+, DS1821+). SHR here is parity-based across partition slices; SHR-2 tolerates two failures. Bay order and the full set of disks both matter for reconstruction.
• RackStation (RS-series) and expansion units (DX and RX shelves). A pool can span the main chassis and an attached shelf. If yours does, the volume is incomplete without the shelf disks — bring every disk, labelled by unit and bay.
• M.2 NVMe SSD cache. A read-only cache can be ignored. A read-write cache holds writes that were never flushed to the array, so if you ran one, bring the cache SSDs too.
• The drives themselves. WD Red and Red Plus, Seagate IronWolf, Toshiba N300 and Synology's own HAT-series are what we see most. SMR drives, where tracks overlap like roof tiles, are slower to image and are a common cause of rebuilds timing out mid-way.

Encrypted shared folders are recoverable, but only with the passphrase or the exported key file. Without one of those, nobody can help — not us, not Synology.