NAS Symptom Recovery
QNAP Drives Not Recognized Recovery
Your QNAP NAS stopped recognizing one or more drives. The QTS web interface shows "Disk Unplugged," "No Disk Detected," or the storage pool is missing.
In most cases the drives themselves are fine. The failure is either a dead 4957AGM power-sequencing MOSFET on the SATA backplane or a corrupted partition 1 configuration database. Your data sits on partition 3 and is intact.
We remove the drives, image each one through a write-blocker, reconstruct the array offline, and extract your files. No data, no fee.
Why are my QNAP drives not recognized?
QNAP drives show as unrecognized because the 4957AGM power MOSFET on the SATA backplane failed, cutting 5V and 12V to the bays, or because the partition 1 configuration database corrupted. The actual data on partition 3 is intact in both cases. Recovery means imaging every drive first, then reassembling the mdadm or ZFS array without the original chassis.
What Actually Fails When QNAP Stops Recognizing Drives
QNAP drive recognition failures fall into two categories: hardware backplane power failure and logical configuration database corruption. Both leave partition 3 untouched.
The 4957AGM MOSFET Backplane Fault
QNAP SATA backplanes on the TS-453, TS-251, TS-473, TVS-873, and related families use a 4957AGM dual P-Channel MOSFET to sequence 5V and 12V power to each bay. This chip delays spin-up to prevent inrush current from overwhelming the power supply. Under prolonged thermal stress or component aging, the MOSFET fails to open its gate. The drive receives no power. QTS detects an I/O timeout, logs "Disk Failed" then "Disk Unplugged," and drops the drive from the array.
The drive itself is fine. Once removed from the chassis and connected to a stable power source, it reads normally. This failure is strictly a backplane electronics problem, not a mechanical drive defect. Competitors who immediately recommend cleanroom intervention are wrong for this failure mode.
Partition 1 Configuration Database Corruption
QNAP stores its RAID configuration database on partition 1 of every member drive, assembled as a small md9 RAID 1 mirror. This database maps storage pool UUIDs to mdadm array geometry. If partition 1 corrupts due to a dirty shutdown, a firmware crash, or the backplane dropping a drive mid-write, QTS cannot identify the array. The Web UI reports the drives as unrecognized, foreign, or uninitialized.
Your files live on partition 3, completely separate from the config database. The mdadm superblocks on partition 3 still contain the RAID geometry. Recovery reads these superblocks directly and reassembles the array without needing the config DB.
QTS vs QuTS Hero: Different Recovery Paths for Unrecognized Drives
QNAP runs two operating systems with completely different storage stacks. The recovery procedure depends entirely on which OS was running before the failure.
QTS Recovery: mdadm + LVM2 + ext4
Standard QTS models store data on ext4 volumes atop Linux mdadm RAID with LVM2 in the middle. After imaging each member drive, we read the mdadm superblocks from partition 3 using mdadm --examine. The superblock contains the RAID level, chunk size, layout, member order, and data offset. We then assemble the array read-only with mdadm --assemble --readonly, activate the LVM volume group with vgchange -ay, and mount the ext4 logical volume read-only to extract files.
QNAP typically uses a 512K or 64K chunk size for RAID 5 and RAID 6 arrays. The superblock version matters: 1.0 places metadata at the end of the partition with data offset 0; 1.2 places metadata 4KB from the start with a data offset around 1MB. Specifying the wrong version shifts every block and produces garbage.
QuTS Hero Recovery: ZFS Pool Import
QuTS hero models like the TVS-h674 and TS-h886 run ZFS directly on partition 3 with no mdadm or LVM layer. ZFS maintains multiple copies of its uber-block in a circular array on each vdev label. When a pool fails to import, we clone every member and use zdb to walk the uber-block ring, identifying the most recent consistent transaction group.
We import the pool read-only against the chosen transaction group with zpool import -F -o readonly=on. If the pool ran deduplication, the Deduplication Table must fit in RAM at import time; approximately 5 GB of RAM per 1 TB of deduplicated data. A pool that imported fine on a 128 GB host may kernel-panic on a smaller recovery workstation.
For the full walkthrough, see our QuTS hero ZFS pool import, uberblock rollback, and DDT RAM requirements page.
QuTS Hero ZIL and SLOG Device Loss
QuTS hero relies on the ZFS Intent Log (ZIL) for synchronous writes. By default the ZIL lives inside the main pool.
When sync-write latency matters, an admin adds a dedicated separate log device, a SLOG vdev, often a small fast SSD, so synchronous writes are acknowledged from the SLOG before being folded into a transaction group. That separate log device becomes a third reason a QuTS hero pool can refuse to import.
Losing the log device is not the same as losing a data vdev. The bulk dataset is not striped onto the SLOG, so a missing log device does not destroy the pool's stored data.
What is at risk is narrow and specific: if the SLOG device fails following a sudden power loss, the in-flight synchronous writes that had been acknowledged from the SLOG but not yet committed to a transaction group are permanently and irrecoverably lost. The bulk pool survives. Those particular unacknowledged-to-disk sync writes do not.
A pool that still references a now-missing log device refuses a normal zpool import. ZFS reports a missing or unavailable log vdev, which QuTS hero surfaces to the user as drives or a pool not being recognized.
The recovery path is to import the pool read-only and allow the missing log device to be discarded rather than block on it, using zpool import -m -o readonly=on with the same read-only forensic discipline applied across this page. The -m flag is what lets ZFS import a pool whose log vdev is gone instead of refusing. Reading happens against cloned images of the member drives, never the original drives.
This SLOG and ZIL failure path is separate from DDT RAM exhaustion and from uberblock rollback after metadata corruption. Those are three distinct reasons a QuTS hero pool refuses to import, and each one is read against imaged drives read-only.
Moving QNAP Drives to a New Chassis: Initialization Overwrite Risk
The primary cause of unrecoverable data loss after drives go unrecognized is not the original failure. It is the initialization prompt that appears when you insert the drives into a different QNAP chassis. After the destination NAS detects a partition 1 mismatch, it offers to initialize or restore factory defaults. Accepting this writes new RAID superblocks to partition 3 of every drive, destroying the original geometry, stripe size, and disk order.
- Initialization overwrites RAID metadata. The setup wizard writes new superblocks to partition 3 of every drive. The original RAID geometry, stripe size, and disk order are destroyed.
- LVM headers are wiped. The LVM Physical Volume header and Volume Group Descriptor Area on each drive are overwritten. The mapping from the RAID device to the ext4 logical volume is severed.
- QuTS hero pools are destroyed. For ZFS systems, initialization creates a new zpool with fresh uber-blocks. The original Merkle tree linking to your data is overwritten.
- Even clicking Cancel can be risky. Some QTS versions perform background scans or auto-repair attempts that write to the drives without explicit user confirmation. The safest action is to power down immediately and remove the drives.
If you see any prompt to initialize, create, or format the storage pool after moving drives: power off the unit. Remove the drives, label each one with its bay number, and contact us. The data is recoverable at that point. After initialization, recovery is harder and more expensive.
QNAP Member Drive Partition Layout
QTS partitions each member drive into five sections. Partitions 1, 2, 4, and 5 are system arrays. Partition 3 holds your data. Understanding this layout explains why a config failure does not affect your files.
| Partition | md Device | Contents |
|---|---|---|
| sdX1 | md9 | QTS system config mirror (~510 MB). RAID 1 across all drives. |
| sdX2 | md256 | System swap / config (~510 MB) |
| sdX3 | md0 / md1 | User data storage pool. The remainder of the drive capacity. |
| sdX4 | md13 | Extended system array (~486 MB). RAID 1 across all drives. |
| sdX5 | swap | Swap / cache partition (~8 GB) |
For data recovery, only partition 3 (sdX3) matters. This partition contains the mdadm RAID array that holds your files. On QTS systems it is managed through LVM2 with an ext4 logical volume. On QuTS hero systems it contains a ZFS pool directly. The system partitions (md9, md13, md256) store QTS boot and config files. They do not need to be recovered for user data extraction.
How do you restore the original QNAP partition layout?
You do not restore partition 1 from inside QTS or QuTS hero once the config database has desynchronized. The correct path is to reassemble from partition 3, where the data pool keeps its own filesystem and pool metadata, not to "restore" the partition 1 config.
QNAP maps your storage pools to the underlying member-drive arrays using a small configuration database on partition 1, assembled as the md9 RAID 1 mirror. The data pool itself does not depend on that database.
On QTS the pool is Linux software RAID (the mdadm tool, the same software RAID that has shipped in Linux since 2001) and keeps its own mdadm superblocks on partition 3 of each member drive. On QuTS hero the pool is OpenZFS, which keeps native ZFS pool metadata on partition 3 instead.
In both cases that data-pool metadata survives partition 1 corruption intact, which is why recovery reads partition 3 directly rather than trying to repair the config on partition 1.
The trap is the prompt that offers to "re-initialize" or "restore" the system from within the web UI. Accepting it is destructive.
On QTS it writes a fresh array structure over the partition 3 mdadm superblocks & severs the LVM Physical Volume header that maps the RAID device to your logical volumes. On QuTS hero it overwrites the ZFS pool metadata on partition 3 instead.
Linux RAID and ZFS recovery practice is to never issue a command that writes to the member drives during a failure state.
Two partition 1 failure sub-states
How the forensic rebuild proceeds depends on whether the partition table is intact or has been damaged. When the table survives, the data partition is read directly; when it does not, the partition boundaries have to be rebuilt first.
- Partition 1 corrupted but present
- The partition table exists, but the md9 config mirror reports errors or is desynchronized. Running
mdadm --examine /dev/sdX3against the data partition still returns the RAID geometry straight from the partition 3 superblock. - Partition table damaged or zeroed
- The partition table itself is damaged, zeroed, or gone, so the operating system no longer exposes the data partition as a device node. Because the metadata 1.0 superblock sits at the end of partition 3, and QNAP places system partitions 4 and 5 after the data partition, a raw-disk scan looks past it. We first rebuild the partition boundaries (or map a loop device at the calculated offset) so that
mdadm --examinecan read the partition 3 superblock and reconstruct the data pool.
Reading geometry from partition 3 without the config DB
We interrogate the member drives directly rather than asking the UI.
On each cloned image, mdadm --examine /dev/sdX3 reports the chunk size, RAID level, layout, member and disk order, and data offset from the partition 3 superblock, with no config database involved.
QNAP has historically written its primary arrays with metadata version 1.0, where the superblock sits at the end of the device and the data offset begins at 0, so identifying the version is part of reading the geometry correctly.
Once the geometry is known, we assemble the data array offline and read-only across the partition 3 devices of the cloned images, for example mdadm --assemble --readonly /dev/md0 /dev/sdX3 /dev/sdY3 /dev/sdZ3. Assembling read-only on the clones is our standard procedure: the original drives are never written to, so a wrong guess at member order costs nothing and can be retried.
Why can't data recovery software find my QNAP iSCSI LUN files?
Because a QNAP file-based iSCSI LUN is not a physical partition. It is a single large container file (a thin-provisioned image) that lives inside a hidden directory on the data-pool filesystem on partition 3, not a separate block device on the disk. A signature scanner reading raw drive sectors never opens that file, so it never sees the filesystem your iSCSI target holds.
If your QNAP served LUNs to a VMware datastore, a Windows initiator, or a backup target, the data you care about is one layer deeper than the QNAP volume itself. On QTS the container sits on the ext4 filesystem that rides on mdadm software RAID plus LVM. On QuTS hero it sits inside a ZFS dataset instead. Either way, reaching the files is a multi-stage job, not a one-click scan, which is the part most generic NAS recovery tools skip past.
What the iSCSI container actually is
- The hidden iSCSI directory
- A hidden directory on the partition 3 data-pool filesystem (ext4 on QTS, or a ZFS-backed dataset on QuTS hero) where QNAP stores the file-based block-storage containers that back each file-based iSCSI LUN. It does not appear in a casual file listing & is not a separate partition on the disk.
- The container file
- The container file itself, a single large image object on the data pool. Everything the iSCSI initiator wrote, its partition table, its NTFS or VMFS filesystem, & its files, lives inside this one file. To the host that mounted the LUN it looked like a whole disk; on the QNAP it is a single object on partition 3.
- Thin (sparse) provisioning
- A thin-provisioned LUN only consumes space for blocks that were actually written, so the container file holds real data only in its allocated extents. A raw scan that treats the unallocated gaps as data wastes time on empty space & still misses the real filesystem, which only resolves once the container is mounted.
The four-stage extraction chain
Recovering an iSCSI LUN from unrecognized QNAP drives runs in order. You cannot reach the files until the layer beneath them exists again.
- Rebuild the underlying array, read-only. Clone every member drive, then reassemble the QTS
mdadmarray with its LVM layer, or import the QuTS hero ZFS pool, entirely from the images. When event counts disagree andmdadmauto-assembly refuses, the array geometry is reconstructed with Data Extractor Express RAID Edition on the PC-3000 Express rather than forced together. - Mount the data-pool filesystem, read-only. Mount the reconstructed partition 3 filesystem read-only so the directory tree, hidden folders included, becomes visible without writing a single block back to the images.
- Extract the container file. Locate the file-based LUN container inside the hidden iSCSI directory & copy it out as a standalone image. This is the object the iSCSI initiator saw as a disk.
- Loop-mount the extracted container. Map the container file as a loop block device so its internal partition table & filesystem, the guest VM disk or the iSCSI target filesystem, can finally be read & the actual files extracted.
Why raw signature scanners fail on an iSCSI LUN
A signature-scanning tool that scans the raw drives for filesystem headers will not find files inside an unmounted LUN, because those files live inside the file-based container, not on the QNAP volume directly. The container has to be reconstructed and loop-mounted first. It is thin-provisioned, so only allocated extents hold real data. This is the same logical-layer discipline we apply across filesystem recovery and brand-specific QNAP recovery.
How We Recover Data from a QNAP with Unrecognized Drives
Every QNAP recovery follows an image-first workflow. Your original drives are never modified. All RAID assembly and filesystem extraction happens on cloned images.
- Free evaluation and model identification. We document the QNAP model, the QTS or QuTS hero version, the RAID level, the number of member drives, and any prior recovery attempts. We check whether the failure was a backplane MOSFET fault, a partition 1 config desync, or an accidental initialization.
- Write-blocked forensic imaging. Each member drive is connected through a hardware write-blocker and imaged with PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager. Drives with mechanical issues receive head swaps or board-level repair in our 0.02 micron ULPA-filtered clean bench before imaging.
- RAID metadata capture. For QTS we read mdadm superblocks from partition 3 of each cloned image to capture stripe size, parity rotation, member order, and data offset. For QuTS hero we read ZFS vdev labels and uber-blocks to identify valid transaction groups.
- Offline array reconstruction. We assemble the virtual mdadm array or import the ZFS pool from the cloned images on a Linux workstation. All reconstruction is read-only. The original drives remain untouched.
- Filesystem extraction and delivery. For QTS we activate the LVM volume group and mount ext4 read-only. For QuTS hero we import the ZFS pool with transaction group rewind if needed. Files are extracted, verified, and copied to your target media. Working copies are securely purged on request.
How Much Does QNAP Drives-Not-Recognized Recovery Cost?
QNAP recovery follows our standard NAS recovery model: a per-drive imaging fee based on each drive's condition, plus an array reconstruction fee. Cases where the backplane failed but the drives are healthy typically cost less because no mechanical work is needed. QuTS hero ZFS reconstruction costs more than QTS ext4 due to additional metadata complexity.
- 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
Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed
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.
NAS array reconstruction adds a flat fee per array on top of per-drive imaging. If we recover nothing, you owe $0. 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.
Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.
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 proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.
See our clean bench validation data and particle test videoQNAP Drives Not Recognized Recovery FAQ
Why does my QNAP say drives are not recognized when they still spin?
That symptom usually means the 4957AGM MOSFET on the SATA backplane failed. It is a power-sequencing chip that controls 5V and 12V to each bay. When it dies, drives lose power intermittently. QTS logs 'Disk Unplugged' and drops the disk from the array. The drive itself is fine; the backplane cannot keep it powered.
Is my data gone if the NAS will not recognize the drives?
Probably not. QNAP stores the RAID configuration on partition 1 (a small md9 array) and your actual data on partition 3. If partition 1 corrupts, QTS reports the drives as unrecognized or foreign, but partition 3 is untouched. Recovery reassembles the array using the metadata still present on the drives.
Can I move my QNAP drives to a new enclosure?
You can physically move them, but do not power them on in a new QNAP and click through any setup wizard. The destination NAS writes its own partition 1 configuration and may ask you to initialize or restore factory defaults, which overwrites the RAID metadata. Your files are still on partition 3, but the new NAS will not know how to read them.
What is the difference between QTS and QuTS hero recovery?
QTS uses mdadm software RAID plus LVM and ext4. QuTS hero uses OpenZFS directly on partition 3 with no LVM layer. For QTS, we reassemble mdadm and activate LVM volumes on a Linux workstation. For QuTS hero, we import the ZFS pool from the imaged drives. Both methods work without the original QNAP hardware.
Will a firmware update fix drives not recognized?
A firmware update will not repair a dead 4957AGM MOSFET, and it will not reconstruct a corrupted partition 1. In some cases, a firmware update itself can corrupt partition 1 if it loses power mid-write or if the backplane drops a drive during the process. Firmware updates fix software bugs; they do not fix hardware power failures or metadata corruption.
Do I need the original QNAP chassis to recover my data?
No. QNAP uses software RAID. The metadata that describes the array is written to each drive's partition 1. We read that metadata on a Linux workstation, reassemble mdadm or import the ZFS pool, and copy your files to a new drive. The original chassis is only relevant if the failure is a dead backplane MOSFET, and even then we do not need it for recovery.
Can I use QNAP's own recovery tools to fix unrecognized drives?
QNAP's built-in tools are designed for healthy arrays. If the partition 1 config is corrupt or the backplane is dead, those tools cannot see the array geometry and will offer to reinitialize. Reinitialization writes a new, empty config. We do not recommend running any QNAP repair or restore utility before the drives are imaged.
What happens to my QuTS hero pool if the ZFS log (SLOG) device dies?
The bulk pool survives because your data is not striped onto the SLOG. What is lost is narrow: if the SLOG failed following a sudden power loss, the in-flight synchronous writes that were acknowledged from the SLOG but not yet committed to a transaction group are permanently and irrecoverably gone. The pool then refuses a normal zpool import because it references a missing log vdev, which QuTS hero shows as a pool or drives not recognized. Recovery imports the pool read-only and allows the missing log device to be discarded, using zpool import -m -o readonly=on against cloned images. The -m flag is what lets ZFS import a pool whose log vdev is gone instead of refusing. This is a separate failure from DDT RAM exhaustion and from uberblock rollback after metadata corruption.
Why can't data recovery software find my QNAP iSCSI LUN files?
A QNAP file-based iSCSI LUN is not a physical partition. It is a container file stored inside a hidden directory on the partition 3 data pool, not a separate block device on the disk. Signature scanners that read raw drive sectors never open that file, so they never see the filesystem inside it. Recovery has to reassemble the array read-only, mount partition 3, extract the container file, then loop-mount it to reach the files. The LUN is thin-provisioned, so only allocated extents hold real data.
How much does QNAP drives-not-recognized recovery cost?
Pricing is per drive, multiplied by the number of drives that need imaging. Because the drives themselves are usually healthy in a backplane or config failure, most cases start at From $100 per drive for simple imaging. If any drive has firmware corruption or mechanical damage, the per-drive cost moves to the appropriate tier shown below. Units with helium-filled enterprise drives use From $200 per drive as a baseline. +$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.. NAS array reconstruction is a flat fee on top of per-drive imaging. No data, no recovery fee.
Related services
Need Recovery for Other Devices?
Bricked after a firmware update
Red status LED on the chassis
ZFS pool import, uberblock rollback, DDT RAM
QTS, QuTS hero, ZFS pools
All NAS brands and RAID types
RAID 0, 1, 5, 6, 10 arrays
Mechanical HDD recovery
Complete service catalog
QNAP drives not recognized?
Power down, label your drives, and ship them to us. Free evaluation. No data, no fee.