NAS Symptom Recovery
QNAP Dead Chassis Data Recovery
You pressed the power button and nothing happened. The fans stay silent, the front LEDs never light, and the unit never appears on the network. It is a brick with your archive inside it.
A chassis that never comes up has not written a single sector to your drives. Your files sit on partition 3 of each member, exactly where the last healthy shutdown left them. The firmware that died lives on a separate flash chip on the mainboard.
The danger in this failure is not the dead box. It is what happens in the next hour, when the drives get plugged into a Windows PC or dropped into a replacement chassis that offers to initialize them.
Is my data gone if my QNAP won't power on?
No. A dead power supply or mainboard stops the computer that was serving your files; it does not reach the platters. QNAP keeps user data on partition 3 of every member drive and keeps its firmware on a Disk on Module flash chip on the mainboard, so the two fail independently. Recovery images every member read-only, then reassembles the array offline on a Linux workstation: mdadm plus LVM plus ext4 for QTS, a native OpenZFS pool for QuTS hero. Do not connect the drives to a Windows PC and do not click through a setup wizard in a replacement chassis.
What Fails When a QNAP Chassis Goes Dark
A QNAP is a small Linux computer bolted to a drive cage. When it stops powering on, the computer died. The storage is a separate set of parts that the dead computer can no longer talk to.
Every recovery decision you make in the next few hours depends on understanding that the thing that broke and the thing that holds your data are different objects sharing a case.
Power supply and mainboard power sequencing
Desktop QNAP units take power from either an external brick or an internal supply. Either one can die outright, and when it does the unit is completely unresponsive: no fan, no LED, no drive spin-up.
A second pattern looks different from the front. Fans spin, lights come on, and the unit still never reaches a booted state or an IP address. That points at the mainboard rather than the supply: the board is taking power but the sequencing that brings it up is not completing.
From a data standpoint both patterns land in the same place. Neither one is a storage fault, and neither one gives the operating system a chance to write anything to your member drives.
DOM flash holds the firmware, not your files
QNAP boots from an internal Disk on Module: a flash chip on the mainboard that carries the operating system. It is physically separate from the drives in the bays.
That separation is why a dead board is survivable. The board, the supply, and the DOM can all be gone while every byte of user data sits untouched on the member drives, because user data was never stored on any of them.
A DOM that fails on its own is a different symptom with a different starting point. If your unit died during or right after a firmware update rather than going dark on its own, read what a firmware update that never wrote cleanly to the DOM does to a QNAP instead. That path starts at the boot device; this one starts at the power rails.
A dead unit is not a unit that boots badly
Sort your symptom before you act on it, because the three states call for different first moves.
A unit that stays completely dark, with no fan spin and no POST, is the case this page covers.
A unit that boots, reaches the web interface, and then drops a bay or reports an empty pool is a QNAP that still runs but stopped recognizing its drives, where the configuration database on partition 1 and the power path to a single bay are the suspects. A unit sitting on a solid red status LED or alternating red and green has firmware running and is telling you something specific.
The dead-chassis case is the least damaging of the set, because nothing on the unit had the opportunity to write a repair attempt over your metadata.
Where Your Files Actually Live on a QNAP Member Drive
QNAP splits every member drive into system partitions and one large data partition. Partition 1 holds the configuration database that maps your storage pools to the underlying arrays. Partition 3 holds your files.
Those two layers fail independently, which is documented on the other end of the same architecture: a corrupted partition 1 desynchronizes the management interface while the user data on partition 3 stays completely intact. A dead chassis is the friendlier version of the same separation, since neither partition was touched at all.
| Where it lives | What it holds | Effect of a dead chassis |
|---|---|---|
| DOM flash on the mainboard | QTS or QuTS hero firmware, the boot image the unit starts from. | Dies with the board and is irrelevant to extracting your files. |
| Partition 1 of each member | Configuration database mapping storage pools to the underlying mdadm arrays. | Untouched. Nothing wrote to it, and reconstruction does not need it. |
| Partition 3 of each member | Your data. An mdadm array under LVM under ext4 on QTS, or a native OpenZFS pool on QuTS hero. | Untouched, and self-describing enough to reassemble without the chassis. |
Array metadata is written to the member drives themselves, not held hostage inside the enclosure, which is why the original hardware is not required to reconstruct the array. On QTS that metadata is the mdadm superblock on partition 3, carrying the RAID level, chunk size, layout, member order, and data offset. On QuTS hero it is the ZFS vdev labels. Either way it travels with the disks.
Anyone who tells you a QNAP array can only be read by another QNAP, or by one lab's proprietary decoder, is describing a product that does not exist. QTS runs the same Linux software RAID that has been in the kernel for two decades, and a non-encrypted QTS array assembles on a vanilla Linux workstation.
Why Windows Cannot Read QNAP Drives
Windows ships no driver for Linux software RAID or LVM, and it reads neither ext4 nor OpenZFS. Attaching a QNAP member drive to a Windows PC does not get you your files. It gets you a disk that Windows offers to initialize.
The instinct is reasonable. The drives are healthy, you own a computer with SATA ports, and the obvious move is to skip the middleman.
Disk Management offers to initialize the disk
Attach a drive whose partition layout Windows does not recognize and Disk Management opens with a dialog asking you to initialize it, usually offering MBR or GPT. The wording is neutral. The operation is not.
Initializing writes a new partition table to the start of the drive. That partition table is what defines where partition 3 begins and ends, and the mdadm superblock for the data array lives inside those partition boundaries rather than at the raw device level. Replace the table and you have severed the map to the exact structure a reconstruction reads.
The files are still physically present after an initialization. What is gone is the cheap, deterministic path to them. Reconstruction after that point means locating partition boundaries by hand, which is slower and less certain than reading a superblock that was still where it belonged.
If you already clicked it, stop there. Do not format, do not run a repair tool, and do not write anything else to those drives. Power the machine down and get in touch before anything else lands on the disk.
Consumer scanners aim at the wrong layer
Software that scans a single drive for file signatures is looking at one member of a striped or parity set. On a striped or parity QTS array, any given file is spread in chunks across several members according to a layout and rotation recorded in the mdadm superblock. Reading one member in isolation returns fragments.
A RAID 1 mirror or a single-disk static volume is the exception, because one member there carries a complete copy of the filesystem.
The array has to exist again before a filesystem can be mounted, and the filesystem has to be mounted before files can be copied. That ordering does not change because a tool advertises otherwise, and running one of those tools against your original drives spends your safest read pass on the wrong operation.
Moving QNAP Drives Into a Replacement Chassis Risks Initialization
A simple chassis power supply failure with healthy members is where moving drives into another unit can genuinely work. It stops working the moment the destination unit does not recognize what it found, because the flow it offers you next is the one that overwrites the array.
Forum advice to buy a new box and move the disks is not wrong in every case. It is wrong in the cases where the original crash came from metadata corruption, and it is dangerous in every case where the user clicks whatever the wizard suggests.
What a migration flow does to the system partitions
Selecting Migrate or Repair in a destination unit instructs the operating system to rewrite the system partitions and force an import of the arrays it found. When that attempt fails, the system commonly offers a fresh install, and accepting it permanently overwrites the remaining data partitions.
The prompts that end arrays are the ones that offer to initialize the disks or create a new storage pool. Both write new structure over members whose partition 3 data was never touched by the original failure. Your files did not need saving until that click.
There is no undo. A new pool is a new set of superblocks, and on a QuTS hero destination it is a new set of vdev labels over the old ones.
QTS members do not migrate into a QuTS hero unit
These are two different filesystems, not two settings of one. QTS writes an mdadm array with LVM and ext4 on partition 3. QuTS hero replaces that entire stack with a native OpenZFS pool on partition 3, with no mdadm and no LVM underneath it.
A QuTS hero unit handed a set of QTS members has nothing it can import. What it does have is a setup flow, and that flow ends in the initialization prompt. Buying a replacement without checking which operating system your dead unit ran is how people arrive at that screen.
The reverse direction fails for the same structural reason. If you are not certain which side you are on, our QuTS hero ZFS page covers the pool-side stack in detail, and the QNAP recovery hub covers the split across both product lines.
A safer order of operations if you own a second chassis
Image the members first, then try the chassis. Once read-only clones exist, a migration attempt costs you an afternoon rather than an archive, because the wizard can only write to the originals you kept out of it.
If you go ahead without images and the destination unit shows the array as degraded, as unrecognized, or offers any prompt to initialize, restore, or create: power the unit off at that screen. Do not click through to see what happens next.
QTS and QuTS hero Take Different Recovery Paths
Which operating system your dead unit ran decides every command that follows. QTS reconstruction is an mdadm and LVM job. QuTS hero reconstruction is an OpenZFS job. There is no shared procedure between them past the imaging step.
QTS offline assembly on mdadm and LVM
Working from clones rather than originals, we read the superblock on partition 3 of each member with mdadm --examine. That single read reports the RAID level, chunk size, layout, member order, and data offset, and it does not write anything.
The array then comes up read-only with mdadm --assemble --readonly, the volume group is activated with vgchange -ay, and the ext4 logical volume is mounted read-only so files can be copied off. On a dead-chassis case with healthy members, that sequence usually runs without a fight, because nothing interrupted the array before the power died.
When event counts disagree between members and mdadm refuses to auto-assemble, the geometry is reconstructed with Data Extractor Express RAID Edition on the PC-3000 Express rather than forced together with a create command. We do not write new superblocks onto a recovery target.
QuTS hero offline assembly on OpenZFS
QuTS hero members carry a native ZFS pool on partition 3, so the ext4 and LVM tooling above has nothing to act on. We start by reading the vdev labels off the clones with zdb -l to confirm pool identity and topology.
The pool is then imported read-only, against images, on a Linux or FreeBSD workstation running OpenZFS. A pool that lost power cleanly at the wall usually imports without argument, because ZFS is transactional and the state already committed to disk is consistent by construction.
Where metadata corruption is in play, recovery means extracting historical transaction groups and performing an uberblock rollback to the last consistent point. That is a different job from the one this page describes, and it is the one our QuTS hero page walks through.
Which operating system did your unit run?
The model name is the first clue and the invoice is the second. If you cannot establish it from either, we determine it from the drives during evaluation: a member with an mdadm superblock on partition 3 was a QTS unit, and a member carrying ZFS vdev labels was a QuTS hero unit. Both reads are non-destructive and happen on the clones.
Tell us what you know and let the drives settle the rest. Guessing matters only if you are about to buy a replacement chassis, which is precisely the decision worth deferring until the members are imaged.
Safe Handling Steps Before You Ship the Drives
Leave the unit off and pull the drives cold, with the bay numbers written on them before they move. Everything on this list protects the one advantage a dead chassis handed you, which is that nothing has written to your data since it died.
- Unplug it and leave it unplugged. A supply that is failing rather than failed can deliver an unstable rail to healthy drives. Repeated power-button attempts are repeated opportunities for the dying part to take a drive with it, and a unit that flickers on once is not a unit that is recovering.
- Label every drive with its bay number. Masking tape and a marker, written before the drive leaves the cage. Member order is recorded in the metadata, so this is belt and braces rather than the only record, but it removes ambiguity from the reconstruction and from any attempt to reinstall the set later.
- Do not attach the drives to a Windows PC. Windows cannot read any of these layouts and will offer to initialize the disk instead. That prompt is the failure mode, not the fix.
- Do not click through a setup wizard in another chassis. If you have already put the drives in a replacement unit and it is asking to initialize, restore, or create a storage pool, power it off at that screen without answering.
- Ship the drives, not the enclosure. Wrap each drive individually in antistatic packaging and pack them so nothing shifts in transit. Our mail-in instructions cover packing, and every step of the work happens at our Austin, TX lab.
The array in that chassis was never a backup. RAID provides hardware availability and uptime; it does not provide data protection, and every member of your set shared one power supply and one backplane. Once your files are back, a discrete offline copy somewhere else is the part that was actually missing.
How We Recover a QNAP That Never Powers On
Every member drive is imaged read-only through a write-blocker before any assembly is attempted. All reconstruction happens against those images. Your original drives are never written to and never mounted read-write.
- Free evaluation and stack identification. We record the model, the member count, the bay order you labelled, whether the unit ran QTS or QuTS hero, and anything already attempted on the drives. Prior attempts change the plan, so tell us about them rather than around them.
- Read-only imaging of every member. Each drive is cloned through a hardware write-blocker with DeepSpar Disk Imager or PC-3000 Portable III. In a dead-chassis case the members are usually healthy, so imaging runs clean and finishes fast. A member that turns out to have bad sectors gets handled with the appropriate tier of work before it holds up the array.
- Metadata capture from partition 3. For QTS we read the mdadm superblocks off the clones to capture RAID level, chunk size, layout, member order, and data offset. For QuTS hero we read the ZFS vdev labels to establish pool identity and topology.
- Offline assembly on a Linux workstation. QTS arrays assemble read-only, then the volume group is activated and the ext4 volume mounted read-only. QuTS hero pools are imported read-only under OpenZFS. No QNAP hardware participates in either path.
- Extraction, verification, and delivery. Files are copied off the mounted volume, checked against what you told us to look for, and written to your target media. Working copies are securely purged on request.
All of it happens in one building. Rossmann Repair Group has been doing board-level and data work since 2008 out of a single lab in Austin, Texas, with no franchises and nothing shipped to a third party. If a member drive does turn out to need platter or head work, it gets that work here, on our own clean bench, rather than being forwarded somewhere.
How Much Does Dead-Chassis QNAP Recovery Cost?
Cost is per member drive for imaging, multiplied by the number of drives imaged, plus a flat $400-$800 array reconstruction fee for the offline assembly. A dead chassis usually leaves healthy members behind, which puts most of these cases at the simple-imaging tier of From $100 per drive.
Each evaluated member gets its own line item at the tier its condition earns, so a set where one drive has bad sectors and the rest read clean is priced accordingly rather than at a single flat rate. Helium-filled enterprise members start at From $200 per drive instead. +$100 rush fee to move to the front of the queue.
- 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
Most Common
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 provide one at cost plus a small markup. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.
The prices above are for standard hard drives, which covers most jobs. Helium-sealed drives (for example WD or HGST Ultrastar He and Seagate Exos X) must be resealed and refilled with helium in-house after the chamber is opened, so they price higher, in the $200–$5,000+ range. See helium drive pricing.
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.
There is no diagnostic fee to evaluate the array, and there is no recovery fee if we recover nothing. Pricing is published rather than quoted after the fact.
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.
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 Dead Chassis Recovery FAQ
My QNAP won't power on at all. Is my data gone?
Almost certainly not. A chassis that never comes up has not issued a single command to your drives, so nothing has been written to them since the last time the unit was alive. QNAP keeps user data on partition 3 of every member drive, and the firmware lives on a separate Disk on Module flash chip on the mainboard. A dead power supply or a mainboard that stops bringing the board up kills the computer around your data, not the data.
Can I just plug my QNAP drives into a Windows PC and copy the files off?
No, and the attempt is where most of these cases turn into real losses. QTS puts Linux software RAID (mdadm) under LVM under an ext4 filesystem on partition 3, and QuTS hero puts a native OpenZFS pool there instead. Windows reads none of those layouts. What Windows does instead is open Disk Management and offer to initialize the disk. Accepting that prompt writes a fresh partition table over the start of the drive and severs the exact metadata a reconstruction reads.
Can I move the drives into a replacement QNAP chassis?
A straight power supply death with healthy members is where a chassis move can work, and QNAP publishes a migration path for it. It is disastrous where metadata corruption caused the crash. What ends arrays is the wizard that appears when the destination unit does not recognize what it found. That flow offers to initialize the disks or create a new storage pool, and accepting it overwrites the array configuration on members whose partition 3 data was never touched. If the array matters more than the convenience, image the members first and treat the chassis move as optional.
Will drives from a QTS unit work in a QuTS hero unit?
No. QTS writes an mdadm array with LVM and ext4 on partition 3. QuTS hero writes a native OpenZFS pool on partition 3 and does not run the mdadm and LVM stack at all. They are different on-disk formats, so a QuTS hero unit has nothing to import from a QTS member set. A destination unit that finds a layout it cannot read is exactly the unit that offers to initialize.
Do I need another QNAP to read my array?
No. The structural metadata that describes a QNAP array is written to the member drives themselves, not held inside the chassis. On QTS we read the mdadm superblocks on partition 3, assemble the array read-only, activate the LVM volume group, and mount ext4 read-only. On QuTS hero we inspect the ZFS vdev labels and import the pool read-only. Both happen on a Linux workstation with no QNAP hardware involved.
Should I keep pressing the power button to see if it comes back?
Stop. A power supply that is failing rather than failed can put your drives on the wrong end of an unstable rail, and repeated attempts are repeated chances to take a healthy drive with it. If the unit came up once and then died again, that is not encouragement. Leave it off, unplugged, and pull the drives with the unit cold.
Does it matter which bay each drive came out of?
Yes. Label every drive with its bay number before it leaves the chassis. Member order is recorded in the mdadm superblock on QTS and in the ZFS vdev labels on QuTS hero, so order is recoverable from the metadata, but a labelled set removes an entire class of ambiguity from the reconstruction and from any later attempt to put the drives back. Masking tape and a marker are enough.
My QNAP powers on but never finishes booting. Is that the same failure?
No, and it changes what we look at first. A unit with fans spinning and lights on is a unit whose firmware is running or trying to, which means the boot device and the configuration database on partition 1 are both in play. A unit with no fans, no lights, and no POST has not reached any of that. This page covers the second case. If the unit powers up and then reports empty or uninitialized storage pools, the failure sits at the boot device or the config database instead.
My drives are encrypted. Does a dead chassis change that?
It changes nothing about the encryption and everything about who can unlock it. QTS supports per-shared-folder eCryptfs and per-volume AES-256; QuTS hero inherits ZFS native encryption with per-dataset keys. The ciphertext sits on partition 3 and survives the chassis. What has to survive with it is your passphrase or exported key material. Tell us the unit was encrypted before you ship it, because the reconstruction and the unlock are separate steps.
Did RAID not protect me from this?
RAID protects against a member drive dying while the array keeps serving. It provides availability and uptime, not data protection. A dead chassis, a deleted directory, ransomware, or a batch of drives that all age out together will take every member of the array at once because they all live in the same box on the same rails. Redundancy inside one enclosure was never a backup. An offline copy stored somewhere else is.
What does recovery from a dead QNAP chassis cost?
Pricing is per member drive for imaging, multiplied by the number of drives that get imaged, plus a flat array reconstruction fee of $400-$800 for the offline assembly. Because a dead chassis usually leaves healthy drives behind, most of these cases sit at the simple-imaging tier, From $100 per drive. Helium-filled enterprise members start at From $200 per drive instead. +$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.. There is no diagnostic fee, and there is no recovery fee if we recover nothing.
How do I ship a NAS full of drives to you?
Ship the drives, not the box. Label each one with its bay number, wrap each drive individually in antistatic packaging, and pack them so nothing shifts in transit. The dead chassis stays with you unless we ask for it. Mail-in instructions and packing guidance are on our mail-in page, and every step of the work happens in our Austin, TX lab.
Related services
Need Recovery for Other Devices?
QTS, QuTS hero, ZFS pools
Unit boots but a bay drops out
Unbootable after a DOM flash write
Solid red status LED on the chassis
Alternating LED during an active operation
Pool import, uberblock rollback
All NAS brands and RAID types
RAID 0, 1, 5, 6, 10 arrays
QNAP won't power on?
Leave it off, label the bays, and ship the drives. Free evaluation. No data, no fee.