Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


When a NAS storage pool is degraded, pause nonessential writes and do not pull a disk based only on an LED color. Record the exact pool, RAID type, bay numbers, drive serials, alerts, and recent events; then verify an independent backup by restoring sample files. Rebuild only after the exact NAS vendor and model documentation confirms the failed member, replacement requirements, and hot-swap procedure.[1][2]
Key Takeaways
- A degraded pool may still be readable, but redundancy is reduced or gone.
- Capture status and physical drive identity before touching a bay.
- Verify a separate backup and sample restore before starting a rebuild.
- Do not run scrub, expansion, updates, and rebuild together.
- Multiple abnormal disks, a crashed pool, or unclear identity calls for vendor support.
The device and app troubleshooting guide provides the general evidence-first method. This guide covers the narrow period after a degraded warning and before a repair or rebuild starts.
“Degraded” commonly means the array is operating without all expected members. It is not interchangeable with crashed, inactive, missing, read-only, rebuilding, or a volume that merely reports low space. Open the storage manager and copy the exact words, pool number, RAID or protection type, affected volume, and drive state.
Create a written bay map before opening the chassis:
| Record | Why it matters |
|---|---|
| NAS make, model, OS, and version | Procedures and hot-swap support differ |
| Pool and volume identifiers | Prevents work on the wrong storage object |
| RAID/protection type and member count | Determines remaining fault tolerance |
| Bay number, model, capacity, and serial | Binds the alert to a physical disk |
| Alert text and timestamps | Preserves the sequence of failure events |
| Recent power, cable, update, or drive changes | Helps distinguish failure from removal or connection loss |
Do not infer the failed disk from front-panel color alone. Bay numbering can start at zero or one, and management order may differ from the view you expect. A mistakenly removed healthy member can turn a recoverable degraded array into a multi-drive failure.
Synology's repair instructions require a compatible replacement and identify supported repair conditions in Storage Manager.[1] QNAP likewise describes selecting the degraded RAID group and following its recovery procedure.[2] Use the documentation for the installed OS version and exact model, not a generic video.
Pause backups into the NAS, media indexing, downloads, camera recording, virtual machines, containers, synchronization, deduplication, and other nonessential writers. Keep only the access needed to copy irreplaceable data or verify backups. Tell other users the pool is in a fragile state so they do not start large transfers.
Do not begin a scrub, filesystem check, expansion, migration, firmware update, package update, or benchmark at the same time. These tasks increase I/O, change state, or complicate failure evidence. If one is already running, capture its status and consult the vendor before forcing it to stop.
Avoid repeated reboots. One controlled shutdown may be necessary for a non-hot-swappable model or unsafe hardware condition, but rebooting does not restore redundancy and can make a marginal disk fail during startup. If there is smoke, burning odor, liquid, abnormal electrical noise, or unsafe heat, cut power according to the vendor's emergency guidance and prioritize safety.
RAID availability is not a backup. It does not protect against accidental deletion, ransomware, filesystem corruption, enclosure failure, theft, fire, or a mistake during repair. A second copy on the same pool is not independent.
Verify the backup in three layers:
Choose samples that reveal hidden gaps: a recent document, an older file, a large media object, a file with permissions or metadata, and an application export. For encrypted backups, verify that keys and credentials are available somewhere other than the degraded NAS.
If no independent backup exists and the pool is readable, copy the most valuable and least replaceable data first. Avoid trying to copy everything in an order that sacrifices critical files to a failing disk. If reads produce errors, drives disappear, or the pool changes to crashed or inactive, stop and seek model-specific support or professional recovery advice.
The NAS backup guide explains backup design, but do not configure a complex new job on the degraded pool. Use the simplest safe path that preserves priority data.
Compare the management alert with the recorded serial number and physical bay label. If the software offers a locate-drive function, use only the vendor-supported method and verify what it indicates. Do not remove any disk while identity is ambiguous.
Check the vendor compatibility list and repair documentation for:
A nominal capacity label is not enough; usable sector count can differ. Do not assume that any disk advertised as the same size will be accepted. Prefer a healthy, compatible replacement intended for the workload, and keep proof of its model and serial.
Synology instructs users to replace the defective drive and repair the pool through Storage Manager under supported conditions.[1] QNAP's recovery path similarly depends on the RAID group and replacement state.[2] Follow only the branch that matches the actual status.
Do not start when two or more disks are abnormal, the wrong disk may have been removed, the pool is crashed or inactive, backup verification failed, the array type is unknown, or the NAS reports filesystem or enclosure faults in addition to a member failure. A rebuild reads heavily from every surviving member; that load can expose another weak disk.
Also stop if drive identities changed after an expansion-unit disconnect, power event, controller error, or migration. Reconnecting a mistakenly removed member may require a different recovery path from replacing a failed drive. Initializing, formatting, or creating a new pool can overwrite metadata needed for recovery.
Contact the vendor with the captured configuration and logs. For unique data, consider professional recovery before trying multiple repair buttons. Do not clone random commands from a forum into a production NAS; model, RAID implementation, filesystem, and member order matter.
Once the backup is verified and the exact procedure is confirmed, replace only the identified member and start the vendor-supported repair. Keep stable power, cooling, and network management access. Do not add workload merely because shares remain available.
Record the start time, selected pool, replacement serial, progress, temperature, and new alerts. A percentage can pause for long periods; do not reboot solely because progress appears slow. Use the vendor's expected behavior and logs to decide whether it is stalled.
After completion, confirm the pool reports healthy, all expected members are present, volumes mount, and representative files open. Review drive health and event history. Schedule, rather than immediately stack, any scrub or update that the vendor recommends. Recheck backups because a repaired array is still not a backup.
For basic architecture, read what a NAS is. For a new system, use the first NAS setup checklist. If the pool is healthy but transfer speed is the issue, use the slow NAS transfer guide.
It may remain readable, but protection is reduced and another failure can cause data loss. Limit use to evidence capture and priority backup work.
No. Confirm the pool, bay, serial number, exact status, and hot-swap support first. LEDs alone are not a safe identity record.
No. RAID can preserve availability after some disk failures, but it does not provide an independent historical copy.
Do not stack scrub and rebuild without explicit vendor guidance. Both can impose heavy reads and obscure the current failure.
Not necessarily. Check usable capacity, interface, technology, and the vendor compatibility rules for the exact NAS.
It varies with capacity, workload, RAID type, drive health, and model. Monitor official progress and alerts rather than using a generic duration.
Do not initialize it or substitute another disk blindly. Preserve the bay map and ask the vendor which reinsertion or recovery branch applies.
Consider it before more writes when data is unique and multiple disks are abnormal, the pool is crashed, reads fail, or drive identity is uncertain.
Sources checked 6 September 2026.
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.