A veterinary clinic’s 6-bay Asustor Lockerstor NAS started restarting endlessly instead of booting, locking away years of patient records and invoices. Asustor support suggested a reset — which would have risked the lot. The disks were healthy; only the NAS’s own operating system had corrupted. Because the data lives in a standard Linux RAID separate from that OS, we rebuilt the array outside the box and recovered everything.
A veterinary clinic ran its practice on a 6-bay Asustor Lockerstor NAS configured as RAID 10 — patient records, treatment histories, appointment schedules and invoices, all in one place. One day it stopped booting and instead cycled endlessly: powering up, starting to load, and restarting again before the storage ever came online. The web interface was dead, so nothing could be reached remotely, and the manufacturer’s first suggestion was to reset the unit. With the clinic’s entire record system on the line, that reset was — rightly — not attempted, and the NAS was sent to us instead.
A NAS is a small computer, and like any computer it runs an operating system. On units like the Asustor Lockerstor that OS — the firmware — lives in a small system area, and when part of it becomes corrupt (through a bad update, a power cut mid-write, or a failing system partition) the NAS can no longer load itself. What you see is a boot loop: it tries to start, fails, and reboots, over and over, never reaching the point where it presents your files. It looks catastrophic. But a boot loop is a failure of the NAS’s software, not necessarily of your data — and on this unit the two turned out to be entirely separate problems.
This is the key to almost every NAS recovery, and it’s widely misunderstood. On the great majority of NAS units — Asustor, Synology, QNAP and others — your files are not stored in some proprietary format tied to the box. They sit in a standard Linux software RAID (Linux’s mdadm) formatted with a standard Linux file system such as ext4 or Btrfs. The NAS OS is essentially just a friendly front end that assembles that array and shares it on your network. So when the OS corrupts and the box won’t boot, the data array underneath is usually completely intact — and it can be assembled and read on a separate Linux system, without the NAS working at all. That is exactly what makes NAS recovery possible even when the unit itself is dead.
The reason a reset is so dangerous is that it targets the same disks your data is on. Depending on the model and the option chosen, a reset or reinitialise can rewrite the system area, recreate the storage pool, or re-lay the RAID — any of which can overwrite or discard the very array metadata and data that a recovery depends on. It is being offered as a way to fix the OS, but it can destroy the data in the process. When a NAS won’t boot and the files matter, the safe sequence is always the same: power it off, don’t reset it, and don’t let it try to repair or rebuild its own pool.
All six disks were removed, kept in bay order, and imaged individually to healthy storage through write blockers; a health check confirmed every disk was sound with no significant bad sectors, which matched the diagnosis of a software-only failure. Working entirely from the images on a Linux workstation, the RAID 10 array was reassembled outside the NAS: the mirror pairing and stripe layout were re-derived and the mdadm array brought up read-only, independent of the corrupt Asustor OS. Where the RAID metadata was inconsistent, the geometry was confirmed by analysing the data itself rather than trusting the damaged configuration, so the reconstructed array matched exactly how the NAS had originally laid the data down.
With the array assembled, its Linux file system was mounted read-only and, where the abrupt failures had left it slightly inconsistent, repaired on the image. The clinic’s data then came back in its original folder structure — patient medical records and treatment histories, appointment schedules, and the financial documents and invoices — and each set was checked for completeness and integrity before sign-off. Everything was written to a fresh external drive and returned, letting the practice restore to a repaired or replacement NAS and carry on without losing a single record. The standing advice went with it: RAID 10 protects against a disk failing, but not against firmware corruption, ransomware or accidental deletion, so a NAS still needs its own separate backup.
Per-disk imaging in bay order, write-blocked · off-NAS mdadm RAID 10 reassembly on a Linux workstation · RAID geometry analysis · ext4/Btrfs file-system repair, read-only · structured extraction and verification. All work in-house at our Belfast lab.
Don’t reset it — power it off and send us the disks for a free, no-obligation diagnostic. A dead NAS very rarely means dead data. We’ll tell you what can be recovered and put a fixed price in writing before any work starts, and on most jobs it’s no fix, no fee. We recover Asustor, Synology, QNAP and other NAS units for customers across the UK.
Usually not. A boot loop is normally the NAS operating system failing, not the disks. On most NAS units your files sit in a standard Linux RAID that’s separate from that OS, so the data can be reassembled and read on another system even when the NAS itself won’t start. The important thing is not to reset the unit while you still need the data.
Not if the files matter. A reset targets the same disks your data lives on and can recreate the storage pool or re-lay the RAID, overwriting what a recovery would use. It’s aimed at fixing the software, but it can destroy the data. Power the NAS off, leave the disks in order, and get a diagnostic first.
Usually just the disks, kept in their bay order and labelled if possible, since the recovery is done by reassembling the array off the unit. If you’re unsure, send the lot — but the disks are what hold your data, and it’s the disks we image and rebuild from.