The NAS glows red, beeps, and you can’t access your business data. In a rush of adrenaline, you think of clicking “Repair” or swapping a disk and starting a rebuild. At that moment, a routine hardware failure can turn into permanent data loss. In our workshop, we see that the greatest damage is not caused by the original disk failure, but by hasty DIY attempts. Let’s talk about what to do and what to avoid at all costs.
Quick verdict
- STOP signals: the disk is knocking, grinding, squealing, or you smell burning → shut down immediately and do not test further. Every further attempt can worsen the situation.
- Do not do a blind rebuild: if you don’t know exactly what happened (e.g., two disks dropped from RAID 5), a rebuild can overwrite metadata and parity.
- Copies first: a bit copy of every disk onto healthy media. Always work on copies, never on the originals.
- When the chances are good: disks are readable and only the configuration has broken down, or the array is
degradedand data is still accessible.
For RAID/NAS, disk order and working on copies are decisive. The fewer attempts made before diagnostics, the better the chance of recovery.
Quick answer: what to do right now
When a NAS reports Degraded, Crashed, Missing volume, Not Initialized, or a server suddenly can’t see shared data, the most valuable thing is to preserve the original state. RAID can often be reassembled, but only if no unnecessary writes were made to it in the meantime.
The first minutes are decisive. Stop attempts, label disks, do not format, and work only on copies.
Practically:
- If a disk is knocking, squealing, scratching, or you smell burning, turn the device off.
- Do not click
repair,rebuild,initialize, orcreate new volume. - Label the disk order by bay and take a photo of the current administration status.
- If data is still accessible, copy only the most important files and do not write anything else to the NAS.
- For unclear failures, arrange data recovery before making further attempts.
Disk order is often just as important for reconstruction as the disks themselves. Taking them out, mixing them up, and experimenting is the worst option.
How to recognize a RAID/NAS problem
It doesn’t always have to be a total collapse. The problem often announces itself gradually, and it’s good not to ignore these signals.
A degraded state isn’t the end of the world, but it is a state with no spare. Another disk error or a bad rebuild can be decisive.
- Light signals: Orange or red LED on the NAS (Synology, QNAP) or server. It may be solid or blinking.
- Audible alert: Regular beeping that warns of array degradation.
- Array status: In the administration, you see the status
Degraded,Crashed,Read-Only,Missing volume, orNot Initialized. - Reduced performance: Extremely slow copying, system hangs, files cannot be opened.
- SMART errors: Warnings in the administration for bad sectors, high temperature, or read errors.
- Unusual sound: Clicking, knocking, scratching, or squealing. This is already a critical mechanical state.
What NOT to do
Here in the workshop, we see recurring error scenarios that turn a solvable problem into a complicated and sometimes impossible recovery.
When you see any of these states, do not proceed by trial and error. For RAID/NAS, it is important to preserve the original state of the disks.
- Blind rebuild/repair: If more disks fail than the array tolerance, or one of the disks is mechanically damaged, a rebuild stresses the remaining disks with reading and can overwrite metadata. This is a common reason why arrays arrive to us in a significantly worse state.
- Disk initialization: When the system reports “uninitialized disk”, never click initialize. You will overwrite the beginning of the disk with critical RAID metadata.
- Swapping order: You take the disks out of the NAS, clean them, and then put them back in a different order. For the controller, it is chaos that can lead to array breakdown.
- Further writing: If you can still access the array, stop writing anything immediately. Every new file or change can overwrite blocks you need to save.
- Repeated power-ons: The disk is clicking? Turn it off and do not turn it on again. Every attempt to spin up can irreversibly destroy the data layer with the head.
- Recovery software on the originals: Running filesystem scanning directly on sick disks is gambling. If a disk is dying, scanning will finish it off.
RAID 0/1/5/6/10: what each level can survive
Each RAID level has a different tolerance for disk failure. Here is an overview that we work with daily in the workshop.
How many disk failures each RAID level can survive — and where there is no spare left.
| RAID | What it survives | Practical comment |
|---|---|---|
| RAID 0 | 0 disks | No redundancy. Failure of a single disk breaks the entire array. Data is striped; without all members, it’s a puzzle missing half the pieces. |
| RAID 1 | 1 disk (mirror) | Survives one disk failure. Beware: deleting a file or a ransomware attack is immediately mirrored to the second disk. RAID 1 protects only against hardware failure, not user error. |
| RAID 5 | 1 disk | In degraded mode, you no longer have any spare. If a second disk fails or a read error occurs during rebuild, the array is critically endangered and data may become inaccessible. With today’s large disks, rebuild is long and risky. |
| RAID 6 | 2 disks | More resilient variant. Even when one disk fails, you still have parity on the second. Rebuild is extremely long and demanding, however; read errors on the remaining disks can thwart it. |
| RAID 10 | Depends on the pair | A combination of mirroring and striping. Survives failure of multiple disks as long as they are not from the same mirrored pair. If both disks from one pair fail, the array is dead. |
When data can be saved and when the chance is low
The following table shows typical scenarios we encounter. We don’t promise miracles, but it shows what plays a role.
| Scenario | Chance of recovery | What is needed |
|---|---|---|
| Broken configuration (disks OK, array not detected) | Very high | Correctly determine array parameters (order, stripe size, offset) and assemble it in software over copies. |
| Degraded array, disks readable | High | Make copies of all disks, verify their health, and only then address replacement and rebuild. |
| Faulty NAS/controller, disks OK | High | Data can often be read on a standard Linux machine. But always from copies, not originals. |
| Reformatting without heavy overwrite | Moderate to high | Depends on the format type and filesystem. Metadata is overwritten, but data often remains. |
| Repeated failures, bad sectors | Moderate to low | Laboratory work is necessary. Reading across bad sectors is slow and risky, requiring specialized hardware. |
| Unfinished or incorrectly started rebuild | Low to very low | Metadata and some data have been overwritten. Data is often fragmented and without a logical structure. |
| Clicking/knocking mechanics | Low (depends on the extent of damage) | Intervention in a cleanroom is necessary, read head replacement. Every additional power-on reduces the chance. |
Real scenarios we often deal with
Not every NAS crash is the same. Two cases may look similar on screen but are technically handled completely differently.
Synology SHR or RAID 5 after one disk failure If the array is only degraded, data is readable, and the other disks are healthy, a standard replacement of the faulty disk can make sense. But as soon as SMART errors appear on another disk, it ceases to be a standard service repair and becomes data recovery.
QNAP after an unsuccessful rebuild This is a worse situation. The rebuild stressed the remaining disks, may have overwritten part of the parity, and metadata may no longer match the original state. Here it is crucial not to try another repair, but to make disk images and analyze exactly what was overwritten.
RAID 0 in an external box RAID 0 has no redundancy. When one disk is missing, part of the data is missing. The chance depends on whether the disk can still be at least partially read and whether we know the array parameters. For important data, RAID 0 is a bad choice.
NAS after ransomware RAID does not help if ransomware encrypts shared files. The array remains technically healthy, but the data is logically damaged. In such a case, we address snapshots, backups, shadow copies, or partial recovery depending on the type of attack.
Diagnostics show whether the disk is suitable for further reading or whether it is necessary to proceed more slowly and conserve every attempt.
Safe recovery procedure
When you bring an array to our workshop, we follow a precise procedure to avoid making things worse. Below is the principle by which safe recovery is performed. However, we do not recommend trying it blindly at home with faulty disks or an unclear array breakdown.
A bit copy is the foundation of safe work. Scanning and reconstruction run over the copy, not the original disk.
Safe procedure: first bit copies of all disks, reconstruction and export only over them — we do not touch the originals.
- Documentation and recording: Write down the exact disk order (bay 1, 2, 3…), their serial numbers, and what happened – a timeline of events. This is often crucial for reconstruction.
- Bit copy (imaging): We connect each disk through a hardware write-blocker (write protection) and create a complete bit copy of it onto healthy, empty media. For faulty disks, we use specialized tools that can read across bad sectors.
- Verifying copy readability: We verify that the copies are complete and error-free. We work solely with them.
- Parameter reconstruction: We analyze metadata and search for the correct parameters – disk order, stripe size, offset, parity type and rotation, metadata type (e.g., mdadm, LVM, Intel Matrix).
- Array assembly and data export: We virtually assemble the array in read-only mode, verify the filesystem structure, and export the data to the target media you bring.
The goal is not to “get the NAS running at all costs.” The goal is to get the data out safely onto another medium and only then address new storage.
Synology/QNAP specifics
Each manufacturer has its specifics that we need to know during recovery.
- Synology: Mostly uses Linux software RAID (
mdadm) in combination with LVM (Logical Volume Manager) and theext4orbtrfsfilesystem. Their own SHR (Synology Hybrid RAID) technology is also built on this stack. The advantage is that data can often be mounted and read even on a standard Linux PC, but we repeat – always from copies. - QNAP: Uses its own layers within the QTS or QuTS (ZFS) system. You may encounter storage pools, RAID groups, and specific configurations. Here too, vendor repair is only a legitimate service procedure if you are absolutely certain that the remaining disks are physically healthy and it is just a standard replacement of a faulty piece in a degraded array. In any other, critical situation, it is safer to stop everything and address it via copies.
Price, time, and what affects success
For RAID and NAS data recovery, it is not honestly possible to promise a fixed price upfront without diagnostics. The difference is enormous: a broken configuration with healthy disks is handled differently from an array after an unsuccessful rebuild, bad sectors, or a mechanically damaged disk.
Success is most affected by:
- how many disks physically failed,
- whether someone started a rebuild or initialization,
- whether a current backup exists,
- whether the bays and disk order are known,
- the RAID type, filesystem, and NAS platform,
- whether further writing was done to the array after the crash.
The first assessment starts by determining the condition of the disks and the configuration. Only then does it make sense to say whether it will be a routine recovery, a more complex RAID reconstruction, or a lab intervention.
Why we don’t repair the original array first
In standard service, it makes sense to repair the device. In data recovery, the order is reversed: first save the data, then address the device. The original array may be in an unstable state, and every operation that writes to it can worsen the outcome.
That is why we avoid these steps until the data is safe:
- rebuild on original disks,
- filesystem repair directly on the array,
- initialization or creation of a new volume,
- recovery software scanning on a faulty original,
- repeated power-on of a disk with a mechanical fault.
Once the data is exported, it is time to decide whether to repair the original NAS, build a new storage setup, replace disks, change the RAID level, or set up better backups.
What to bring or send to us
The better the information we receive at the beginning, the less time we lose on reconstruction. It is ideal to bring the entire NAS or server in its original state. If that is not possible, at least accurate documentation helps.
Prepare:
- NAS or server model,
- number of disks and their original order in slots,
- a photo of the administration showing the array status,
- a timeline: what happened first, what you tried next,
- information on whether a rebuild, repair, initialization, or disk replacement took place,
- target media for the recovered data.
After data recovery, it makes sense to immediately set up data backup, because RAID itself is not a backup.
Frequently asked questions
Should I replace the faulty disk and click repair? Only if you are 100% sure that exactly one disk has failed and all others are in perfect condition (no SMART errors, no bad sectors). Otherwise, it is a risky operation that can destroy the array. If you are not sure, do not do it.
Can I connect the disks to Windows? No. Windows natively does not understand filesystems like ext4, btrfs, or software RAID from Linux (mdadm). An attempt to connect may lead to a prompt to initialize the disk, which would have fatal consequences.
The NAS shows data but reports degraded — what now? Immediately back up the most important data to an external drive if possible. Then address the disk replacement. Remember that in a degraded state, you have no protection against another disk failure.
Do I have to bring the whole NAS or just the disks? Ideally, bring the whole NAS. Knowing the model and system version is important for us. If you bring only the disks, it is critically important to have their order precisely labeled (bay 1, 2, 3…). Without it, reconstruction becomes extremely complicated.
Will RAID help if I accidentally deleted something? No. RAID protects against hardware failure but is not a backup. It will not protect you against file deletion, user error, or ransomware. The 3-2-1 backup rule applies to NAS and servers as well.
Official manufacturer guides vs. data recovery
Both Synology and QNAP have official procedures for repairing a degraded array. These make sense when it is clear that exactly one disk has failed, the remaining disks are healthy, and you have a current backup. If you are not sure about that, it is safer to stop and make copies first. For orientation: Synology describes repairing a storage pool, QNAP describes recovering a RAID group with a degraded status. These guides are not the same as data recovery after an unclear crash.
If your NAS or server is reporting an error, stay calm and above all do not try anything blindly. Call us before you start a rebuild. A correctly described disk order and a timeline of events are half the battle. We will take care of the rest as part of data recovery in Brno. And once your data is safe, check out our tips for proper backup, because RAID itself really isn’t a backup.