NAS Symptom Recovery
QNAP Status Light Flashing Red and Green
Your QNAP status LED is alternating red and green & you never started a firmware update or a format. That pattern means the box is running a background operation, & the system logs tell you which one. A rebuild is one that can start without you: when a disk in a RAID group fails & a hot spare is assigned, QTS starts rebuilding onto the spare by itself.
A RAID 5 or RAID 6 rebuild reads every sector of every surviving drive, & those drives are already one failure short of redundancy. Power down & image the drives read-only before you let it finish. No data, no fee.
What does a flashing red and green light mean on a QNAP NAS?
A flashing red and green status LED on a QNAP NAS means the system is running a background operation. Blinking red and green, flashing red and green, and alternating red and green all describe the same LED behavior. If you didn't start a firmware update, format, or capacity expansion, the system logs show which operation is running. A rebuild of a degraded RAID array onto a hot spare starts on its own. A RAID 5 or RAID 6 rebuild reads every sector of every surviving drive, so image the array read-only before you let it finish.
What the QNAP Status LED Colors Actually Mean
Your QNAP's status LED has more than three states, but these three are the ones you need to know. A solid red light is a critical error. A flashing red light is a degraded array. Alternating red and green is a background operation, one of which is the rebuild of that degraded array.
The official QNAP references list the alternating red and green pattern as an important operation & group it with formatting, initialization, capacity expansion, & firmware updates. A rebuild is different: it only runs after the array has already lost a member.
| Status LED | Documented meaning | What it means for your data |
|---|---|---|
| Solid red | Several faults, including two-drive degraded read-only mode, a full volume, a failed fan, or a disk read/write error. | Stop & diagnose before writing anything. |
| Flashing red | Degraded mode: a member failed in a RAID 1, 5, or 6 group. | One member has already failed. |
| Flashing red and green | Important background operation: rebuild, format, firmware update, initialization, capacity expansion, or RAID level migration. | If you did not start one, check the system logs for the operation. If it is a rebuild, image before it finishes. |
The transition matters. A drive drops out, the array goes degraded, & the LED flashes red. When a hot spare is assigned, QTS starts rebuilding onto it & the LED shifts to alternating red and green. Nobody pressed a button.
The box did it because that is what redundant arrays are built to do, & that automatic behavior is exactly where the risk lives.
If the LED is a steady solid red instead of alternating between red and green, you are looking at a different critical-error state, which we walk through on the dedicated QNAP red light error diagnosis page.
Which Light on the Chassis Is the System Status LED?
A QNAP chassis carries several indicators, & only one of them is the system status LED. The rest report narrower things: an indicator sitting with a drive tray is reporting that bay, an indicator at the network port is reporting that link, & a front USB port with a one-touch copy button has an indicator of its own.
Match a light to what it sits beside before you act on it. A bay indicator tells you about one disk. The system status LED tells you about the whole unit.
How Do You Find Out Which Drive Failed?
Not from the chassis light. A single system status LED is an assembly-level indicator; it carries one condition for the entire unit, so it has no way to name the member that is implicated. Per-disk answers come from the per-drive indicators, from the Storage & Snapshots manager inside QTS, & from the system logs.
At the block layer, the answer is in the member metadata. On QTS that is the Device Role in the mdadm superblock on partition 3 of each drive. On QuTS hero it's the ZFS vdev labels on the pool members. Reading membership off the disks instead of off the chassis is where any RAID array recovery starts.
An aggregate indicator cannot name the member for you, so the read-only imaging decision follows from the array's own state: degraded, a member already gone, or a reconstruction already running.
Why Is My QNAP Flashing Red and Green When I Did Not Start Anything?
QTS doesn't need you to start a rebuild. When a disk in a RAID group fails & a hot spare is assigned, it starts rebuilding onto the spare by itself. It can also install firmware updates automatically when that setting is on, so check the system logs to see which operation is running.
A genuine firmware update is one of the legitimate causes of the alternating red and green light, but a firmware update that stalled or failed mid-write is its own separate problem that we handle on the QNAP firmware update failure recovery page.
A drive drops out for reasons that have nothing to do with you clicking anything:
- A bad sector run
- A cable or backplane glitch
- A drive that stalls too long on a write
- A member from the same manufacturing batch aging out at the same time as its siblings
When the array loses that member, it goes degraded & keeps serving data on the remaining drives. If a hot spare is assigned, the rebuild kicks off & the LED goes red and green.
If the logs show a RAID 5 or RAID 6 rebuild, that's a full read pass across drives in an array that has already lost a member. Waiting is the dangerous option, not the safe one.
A flashing red and green rebuild light also proves that RAID is about availability. It was never a backup. The array is doing its job by staying online through one drive loss. While it rebuilds, your data is exposed to a second failure during a full read of the surviving disks. What survives a cascade like that is a discrete, offline copy of your files.
How a QTS RAID 5 Rebuild Reads Every Sector of Every Surviving Drive
QTS uses mdadm, LVM, & ext4, with the user data on partition 3. When a member fails, md marks it faulty & keeps running on the remaining devices. If a spare is present, md starts recovery onto it. In RAID 5 or RAID 6, rebuilding one drive means reading the corresponding block from every other member, which is a full end-to-end read of every surviving disk.
QTS is not proprietary silicon. It is the Linux md driver, managed by the mdadm tool, with the Logical Volume Manager (LVM) stacked on top & an ext4 filesystem above that. Nobody needs a QNAP controller to read it. It also means a degraded RAID 5 rebuild on QTS runs the same parity math as a rebuild on any other mdadm array.
Read errors during a degraded rebuild destroy the data they touch
A RAID 5 array survives one drive loss by calculating the missing data from parity. To rebuild the missing member, mdadm has to read every sector of every remaining drive & recompute the parity. Here is the problem: consumer drives are rated for roughly one unrecoverable read error per 12.5 TB of data read (a URE rate of one per 10^14 bits). A large array can have to read more than that during a single rebuild.
The array is already degraded, so there is no spare parity left. What a read error does next depends on the controller:
| Controller | What happens on a read error mid-rebuild |
|---|---|
| Linux mdadm (what QTS runs) | Records the unreadable address in its Bad Block Log & calculates the missing data from parity, so the rebuild continues & the array is not necessarily taken offline. |
| HP Smart Array P-series and E-series | Reliably aborts a rebuild on a single read error. |
| Low-end consumer controllers such as Intel RST | Reliably aborts a rebuild on a single read error. |
On mdadm the data covering that region is permanently lost, & the pass is still reading every sector of drives that have no redundancy left to give.
The safe QTS workflow
A RAID 5 rebuild is a full read of every surviving drive, so we don't let it run on the originals until we've imaged them. We clone each surviving member read-only first. All later work happens on the copies.
Then we read the mdadm superblocks directly from the partition 3 clones to reconstruct the RAID geometry: level, chunk size, member order, & data offset. We read the LVM metadata above the array from the same clones. We assemble the array read-only with mdadm --assemble --readonly.
If a cloned member has weak sectors, we re-read them under imaging rather than letting a live rebuild slam into them. The same offset discipline carries across every Linux mdadm array we rebuild, QNAP or not.
QuTS Hero: Why a ZFS Resilver Is Not the Same as a Scrub
On QuTS hero, rebuilding a degraded pool onto a replacement disk is a resilver, which examines only the data ZFS knows to be out of date. A scrub examines all data, verifies each block's checksum, & repairs any damage it finds on redundant vdevs.
That difference tells you how worried to be. A resilver runs because the pool is degraded, & ZFS is writing reconstructed data onto a disk to put the redundancy back.
Transaction group rollback when pool metadata is damaged
ZFS writes its state in numbered transaction groups (TXGs), & every vdev label keeps a ring of uberblocks pointing at recent TXGs. When the pool metadata is damaged, standard ZFS recovery rolls the pool back to a previous transaction group by importing an older uberblock.
We pick the rollback target offline, from cloned member images, before any import. A read-write import on the live disks would write new transaction groups over the oldest slots of the ring. The array reconstruction & destriping runs on Data Extractor Express RAID Edition against the images, never the originals.
What does deduplication cost a recovery host?
If the QuTS hero pool ran deduplication, holding the deduplication table in ARC takes roughly 1 to 5 GB of RAM for every 1 TB of deduplicated data. OpenZFS keeps the table on disk and reads it on demand, so a pool whose table outgrows RAM still imports. You pay for that in time. iXsystems says loading the table on demand can take days after an import.
Because ZFS transaction rollback & uberblock analysis are a separate discipline from QTS mdadm reassembly, we keep the full procedure on our QNAP QuTS hero ZFS recovery walkthrough.
Where Your Data Lives While the Light Is Flashing
Your files are on partition 3 of the member drives, isolated from the small configuration database that QTS keeps on partition 1. The rebuild is a threat because of the read stress it puts on weak drives.
QNAP keeps its configuration database on /dev/md9, the mirrored array built from partition 1 of each member. On QTS the user data & its mdadm superblocks live on partition 3. If partition 1 ever desyncs, the user data on partition 3 stays physically intact, which is why a config problem is not the same as data loss.
That separation is exactly why imaging first works. We read the array metadata & the filesystem straight off partition 3 of each cloned drive. The reconstruction never depends on the partition 1 config database being healthy, & it never needs the original QNAP chassis to interpret a standard non-encrypted QTS array. This is a QNAP failure mode that overlaps with our drives-not-recognized recovery work, where the config database is the part that broke rather than the disks.
What Happens to an iSCSI LUN or VM Datastore While the Array Rebuilds?
The target stays up. An iSCSI LUN is not a partition & not a disk of its own; it is carved out of the same storage pool that sits on the array now running one member short of redundancy, so your initiator keeps that LUN mounted & in use the whole time the status LED flashes red and green.
The target keeps answering normally, so it's easy to leave the workload running. The whole time, the reconstruction underneath it is reading across every surviving disk. Power down & image first applies to a virtualized block device for the same reason it applies to a share full of documents. Stop the workload, then stop the box.
Where a QNAP LUN lives on disk
QTS offers three LUN types: block-based, file-based, & VJBOD Cloud. Which one you configured decides the recovery path. A Block-Based LUN is created from the storage pool, & a File-Based LUN sits on a thick volume.
On QuTS hero, a LUN goes through the separate QuTS hero ZFS recovery procedure. The full breakdown of the LUN types sits on our iSCSI LUN recovery page.
If the target drops off your initiator while the box is degraded, or the storage manager shows the pool as empty, treat that as a management-layer symptom rather than proof the LUN contents are gone.
QNAP keeps the configuration database that maps storage pools to the underlying mdadm arrays on partition 1 of the member drives; the pool & everything carved from it live on partition 3. A partition 1 problem breaks the map while the payload stays where it was.
Extraction adds a layer above the array
A LUN holds a guest filesystem of its own inside the storage stack, so there is one more layer to get through than a share full of files. Every stage runs on clones.
- Image every member drive, so the important operation the LED is reporting never runs on the originals again.
- Reassemble the array read-only from those clones with
mdadm --assemble --readonly. - Take the LUN itself out of the storage pool for a Block-Based target, or out of the volume, mounted read-only, for a File-Based one.
- Attach the extracted LUN as a block device so the guest filesystem inside it, such as a VMware VMFS datastore, can be read.
A LUN carries no protection separate from the pool it was carved from, which is the same reason the redundancy in that pool was never a backup.
Why Moving the Drives to a New QNAP Can Overwrite Your Data
The reflex when a NAS starts flashing red and green is to pull the drives & drop them into a spare QNAP. If the crash came from metadata trouble, the new chassis can offer to initialize or repair the drives, & accepting that prompt rewrites the system partitions & can overwrite the intact user data on partition 3.
- Initialize overwrites partition 3. Letting the new box initialize the disks writes fresh metadata over the array, severing the map to your data. The sectors that held your files get reused.
- Do not force a degraded array back online. Forcing the RAID to resync in read-write mode or re-adding a dropped member over the CLI writes to failing disks. On QuTS hero, a read-write pool import writes new transaction groups over the oldest uberblock slots & pushes out the historical transaction groups that recovery depends on.
If the original chassis is electrically fine, moving drives gains you nothing & risks everything. Power the unit off, label each drive with its bay number, & get the array imaged. The data is recoverable at that point.
The Rebuild Advice That Puts a Flashing QNAP at Risk
QNAP's own procedure for a degraded RAID group is to click Rebuild. That, or forcing the array online from the command line, puts the full rebuild read load on disks that are already one failure short of redundancy. On drives you care about, neither is safe before the array is imaged.
The official walkthrough tells you to select the degraded RAID group, open Manage, choose Rebuild RAID Group, & click Rebuild. It does not ask you to verify the health of the surviving members first. On a small mirror with healthy disks that is fine. On a large RAID 5 built from aging, same-batch drives, clicking Rebuild starts the full read pass that can hit an unrecoverable read error.
Forcing the array to resync in read-write mode, then re-adding the dropped member, writes over failing disks & destroys the very state a lab needs to reconstruct the array cleanly. The safe answer is the opposite of both: stop, power down, & image read-only. When the data is irreplaceable & there's no verified backup, clone the degraded array member by member before anyone attempts a rebuild.
None of this means QNAP hardware is proprietary or unreadable. A standard non-encrypted QTS array reassembles on a vanilla Linux workstation using ordinary mdadm metadata, no QNAP controller involved. The danger is not the format; it is the rebuild running against weak drives before anyone captured a clean copy.
Imaging before reassembly is not a QNAP-specific rule. Chunk size, member order, & parity rotation are written into the mdadm superblocks on the member drives rather than into the chassis, so NAS data recovery on any mdadm-based box runs in the same order: clone every surviving member read-only, then assemble the array from the clones.
How We Recover a QNAP That Is Flashing Red and Green
Every QNAP recovery follows an image-first workflow. All RAID assembly, ZFS import, & filesystem extraction happens on cloned images. Work is performed in-house at our Austin, TX lab; nationwide service is mail-in.
- Free evaluation & model identification. There's no diagnostic fee.
- Imaging. We image each member with the PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager. Drives with weak heads or bad-sector runs get imaged under controlled re-reads, or receive mechanical work in our 0.02 micron ULPA-filtered clean bench first, so the rebuild stress never touches the originals.
- Array metadata capture. For QTS we read the mdadm superblocks from partition 3 of each clone to capture chunk size, parity rotation, member order, & data offset, & the LVM metadata above them. For QuTS hero we read the ZFS vdev labels & the uberblock ring to find the last consistent transaction group.
- Offline array reconstruction. We assemble the virtual mdadm array from the clones in read-only mode, with Data Extractor Express RAID Edition handling the destriping. The original drives stay untouched.
How Much Does QNAP Degraded Array Recovery Cost?
QNAP recovery uses our standard NAS model: a per-drive imaging fee based on each drive's condition, multiplied by the number of drives that need imaging, plus an array reconstruction fee. A rebuild case where the drives are still healthy sits at the lower tiers because no mechanical work is needed. Drives that were ground down by a rebuild, or that failed mechanically, move up the tiers.
- Low complexity
Simple Copy
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$100
3-5 business days
- Low complexity
File System Recovery
Your drive isn't recognized by your computer, but it's not making unusual sounds
File system corruption. Accessible with professional recovery software but not by the OS
Starting price; final depends on complexity
From $250
2-4 weeks
- Medium complexity
Firmware Repair
Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond
Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access
CMR drive: $600. SMR drive: $900.
$600–$900
3-6 weeks
- High complexity
Head Swap
Bench diagnosis found the read/write heads have to be replaced. Clicking can also come from firmware, the preamp, or the spindle
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
$1,200–$1,500
4-8 weeks
- High complexity
Surface / Platter Damage
Your drive was dropped, has visible damage, or a head crash scraped the platters
Platter scoring or contamination. Requires platter cleaning and head swap
50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.
50% deposit required
$2,000
4-8 weeks
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
- Rush fee
- +$100 rush fee to move to the front of the queue
- Donor drives
- Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
- Target drive
- The destination drive we copy recovered data onto. You can supply your own, or we'll provide one. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.
Sealed helium drives are on their own price list, $200–$5,000+. When a head swap or platter repair opens one, we refill it with helium. That adds $400–$800, and the donor has to be an exact match. Helium drive prices
Each evaluated member is priced by its own condition, so a four-bay array with two clean drives & two weak drives generates a separate line item for each drive we image. Putting a NAS array back together adds an array reconstruction fee per array on top of the per-drive imaging. Need it fast? +$100 rush fee to move to the front of the queue. Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available. If we recover nothing, there is no recovery fee. There are no diagnostic fees.
Data Recovery Standards & Verification
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.
Localized Clean Zone
Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.
Transparent History
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Media Coverage
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Aligned Incentives
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Technical Oversight
Louis Rossmann
Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.
See the particle counter test at the benchQNAP Flashing Red and Green FAQ
What does a flashing red and green light mean on a QNAP NAS?
An alternating red and green status LED means the NAS is running a background operation: a RAID rebuild, formatting, initialization, capacity expansion, RAID level migration, or a firmware update. If you didn't start one of those tasks, the system logs show which operation is running. A rebuild onto a hot spare starts on its own after a member drive fails. A RAID 5 or RAID 6 rebuild reads every sector of every surviving drive. A QNAP blinking red and green is the same symptom under a different word: blinking, flashing, and alternating all describe the same status LED behavior.
I did not start anything. Why is my QNAP flashing red and green?
QTS starts a rebuild automatically when a disk in a RAID group fails and a hot spare is assigned. QTS can also install firmware updates automatically when that setting is on. If it's a rebuild, the array was already degraded before the light changed color. A flashing red light is the degraded warning. When the box begins reconstructing the missing drive, the LED shifts to alternating red and green. Nobody has to press a button for this to run.
Should I let the QNAP rebuild finish?
Not on drives you care about, and not before the array is imaged. A RAID 5 rebuild reads every sector of every surviving member. If one of those drives hits an unrecoverable read error during that read, mdadm logs the unreadable block and finishes, but the data covering that region is gone for good, and a second member dropping out during the pass ends the array outright. Consumer drives are rated for roughly one unrecoverable read error per 12.5 TB read, so a large array can hit the limit mid-rebuild. Power down, label the drives, and image them read-only first.
Is a flashing red and green light the same as a solid red light on QNAP?
No. A solid red light covers several faults, including two-drive degraded read-only mode, a full volume, a failed fan, and a disk read/write error. A flashing red light is degraded mode, meaning a member failed in a RAID 1, 5, or 6 group. Alternating red and green means a background operation is running, and a rebuild of that degraded array is one of them.
Can I stop the QNAP rebuild once it has started?
The safest way to stop the wear on your drives is to power the unit down. Do not keep letting it run for hours in the hope it finishes. Every hour of rebuild is another hour of sustained read stress across drives that are already one failure into a redundancy loss. Once the unit is off, remove the drives, label each with its bay number, and get them imaged before any further reconstruction.
My QNAP runs QuTS hero with ZFS. Is the flashing light the same problem?
It works differently underneath. On QuTS hero, rebuilding a degraded pool onto a replacement disk is a ZFS resilver. It only examines the data ZFS knows is out of date. A scrub examines all data, verifies each block's checksum, and repairs any damage it finds on redundant vdevs. Image the drives before you let the resilver finish.
Can I just move the drives to a new QNAP enclosure?
If the crash came from metadata trouble, a new chassis can offer to initialize or repair the drives, and accepting that prompt can overwrite the intact user data on partition 3. If the original chassis is fine electrically, moving drives gains you nothing and risks everything. Image first, then decide.
Does the flashing light mean my data is already lost?
No. A flashing red and green light means an operation is in progress, not that your files are gone. On QTS your data lives on partition 3 as an ext4 volume over LVM over an mdadm array. On QuTS hero it is a ZFS pool. The risk is what the rebuild does to already-weak drives, not the color of the LED.
Can you read QNAP drives without the original NAS?
QTS is built on Linux mdadm, LVM, and ext4. We assemble the md array from cloned images with stock mdadm. You don't need any QNAP hardware for that. QuTS hero pools need ZFS-aware handling of the vdev labels and transaction groups. Either way we image every member first and work only on the copies.
Is RAID not enough to protect my QNAP data?
A flashing red and green rebuild light is the proof that RAID is availability, not backup. Redundancy keeps the box online through a single drive loss, but it does nothing against a second failure during the rebuild, ransomware, accidental deletion, or a controller fault. Only a discrete, offline copy of your files protects against those. RAID buys you uptime, not safety.
Can I leave my VMware datastore online while the QNAP rebuilds?
Not on data you care about. An iSCSI LUN is not a separate disk. On QTS a Block-Based LUN is created from the storage pool, and a File-Based LUN sits on a thick volume. Either way, it's on the same array that's now one member short of redundancy. Your initiator keeps that target mounted and in use for the whole rebuild. That's why you image first on a LUN, same as you would for a share. Shut the guests down, power the NAS down, and get every member imaged read-only. The array is then reassembled offline from the clones, the LUN is taken out of the rebuilt storage pool, and it is attached as a block device so the VMFS datastore inside it can be read.
Which light on my QNAP is the status light?
The system status LED is the chassis indicator that reports the unit as a whole. It is not the indicator sitting with a drive tray, which reports that bay, and it is not the indicator at the network port, which reports that link. A front USB port with a one-touch copy button has an indicator of its own. Match a light to what it sits beside before you act on it, because a bay indicator and the system status LED are answering different questions.
Does the QNAP status light tell me which drive failed?
No. A single system status LED is an assembly-level indicator: it carries one condition for the entire unit, so it has no way to name the member drive that is implicated. Per-disk answers come from the per-drive indicators, from the Storage & Snapshots manager inside QTS, and from the system logs. At the block layer, the answer is in the member metadata. On QTS that's the Device Role in the mdadm superblock on partition 3 of each drive. On QuTS hero it's the ZFS vdev labels on the pool members.
Since 2008
Established
As Featured In
Related services
Need Recovery for Other Devices?
All NAS brands and RAID types
QTS, QuTS hero, ZFS pools
DOM brick and config-DB desync
Backplane and config-DB faults
Resilver, TXG, and uberblock rollback
Solid red LED and failed-drive diagnostics
RAID 0, 1, 5, 6, 10 arrays
Complete service catalog
QNAP flashing red and green?
Power down before the rebuild finishes, label your drives, and ship them to us. Free evaluation. No data, no fee.