NAS Symptom Recovery
QNAP Drives Not Recognized Recovery
Your QNAP stopped seeing one or more of its drives. The QTS system log says "Disk drive X failed or is unplugged," or the storage pool is just gone.
Often the drives themselves are fine, and the fault is a power failure in the backplane behind the bay or a corrupted configuration database on partition 1. Your data sits on partition 3, and it's 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?
A lot of the time, QNAP drives show up as unrecognized because the backplane stopped feeding power to the bays or the partition 1 configuration database got corrupted. Your 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.
How We Recover a QNAP That Stopped Recognizing Its Drives
We image every member drive read-only first, reassemble the array offline on a Linux workstation without the original QNAP, and extract your files. No data, no fee.
How we recover it
- Read-only per-disk imaging. Each drive is cloned through a hardware write-blocker with DeepSpar Disk Imager or PC-3000 Portable III. In a backplane or config failure the drives are usually healthy, so imaging is clean and the originals are never written to.
- QTS: read partition 3 directly. We parse the mdadm superblock and LVM metadata straight from partition 3 on the clones. Corruption of the partition 1 config database, the md9 mirror, does not touch the partition 3 user data, so the array reassembles without the config DB.
Why us
- Real imaging hardware. PC-3000 Portable III and a 0.02 micron ULPA-filtered clean bench for the rare drive that also needs mechanical work.
- One lab, all in-house. A single Austin, TX lab performs every step. No outsourcing, no franchises.
- No data, no fee. No recovery fee if we recover nothing, and no diagnostic fee to evaluate the array.
When the drives are healthy & the fault was the backplane or the config, pricing starts at $100 per drive. See the full pricing breakdown below.
What Actually Fails When QNAP Stops Recognizing Drives
Two of the common ones are a hardware fault, where the backplane stops powering a bay, & a logical fault, where the configuration database corrupts. Neither one touches partition 3.
Backplane power faults
Every bay gets its 5V and 12V through the backplane the drive plugs into. When that path stops delivering power to one bay, the drive in it goes quiet mid-operation.
QTS sees the commands it issued go unanswered and warns that the disk drive failed or is unplugged, then drops the member 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.
If you're standing in front of the box instead of logged into QTS, read the status LED first. A QNAP status light flashing red and green means a background operation is running. That's the pre-login symptom; the empty pool & the partition 1 configuration database are what QTS reports once you're signed in.
All of that assumes the unit itself is up. The backplane fault described here takes power away from one bay while QTS keeps running, which is why you can sign in & read a failed-or-unplugged report at all. A chassis that never comes up is the adjacent condition. Nothing answers on the network, so there is no QTS session & none of the reports on this page are available to read. Start with a QNAP chassis that never powers on instead.
Partition 1 Configuration Database Corruption
QNAP keeps its RAID configuration database on partition 1 of every member drive, assembled as a small md9 RAID 1 mirror. That database is the map of which storage pool sits on which underlying mdadm array.
When partition 1 corrupts, QTS tells you the storage pools are empty 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.
A firmware update that never wrote cleanly to the internal Disk on Module flash leaves the unit unable to boot, or leaves QTS calling the storage pools empty or uninitialized. That second report looks the same in the Web UI as a corrupted partition 1, & partition 3 comes through intact either way.
Interrupted Writes on a Crash or Forced Reboot
A crash or a forced power cycle while writes are still in flight can drop a member while the drive itself is fine. Whatever triggered the reset, this lands on the volume on partition 3, a different layer from the partition 1 configuration database losing its map to the array.
On QTS, a pool-backed volume sits on mdadm, LVM, & ext4. ext4 journals its metadata, so the next mount replays the journal & lands on a structurally consistent filesystem. In-flight writes that were never committed get discarded on the way there.
QuTS hero behaves differently. ZFS is copy-on-write & transactional, so the pool state already committed to disk survives the crash intact. An interrupted ZIL flush doesn't corrupt the pool that is already on disk.
QNAP's security advisory QSA-26-10, dated 2026-06-17, ships its fixes in QTS 5.2.9.3499 on the ext4 side of the product line, with QuTS hero h5.2.9 covering the ZFS side. The versions it lists as affected are QTS 5.2.7 & QuTS hero h5.2.8. One of its entries, CVE-2026-26241, is a buffer overflow in File Station 5 that's fixed in File Station 5.5.6.5243. The MITRE/QNAP description reads: "A buffer overflow vulnerability has been reported to affect File Station 5. The remote attackers can then exploit the vulnerability to modify memory or crash processes."
What journal replay buys you on the ext4 stack is narrower than it sounds. Under the default data=ordered mode, replaying the journal at the next mount puts the structural metadata back in a consistent state. It won't make writes durable if they were never flushed with fsync. One layer down, the md driver marks the array dirty before it writes & marks it clean again at shutdown. A crash leaves it marked dirty.
On either stack the first move is the same: clone every member through a write-blocker before any repair, migrate, or firmware reflash.
Record the running firmware version at intake alongside the clones. A dropped array on an unpatched unit is not automatically a drive fault, so the number belongs in the intake record before anything reflashes the unit.
QNAP I/O Error Accumulation: How a Pool Slips From Warning to Degraded
When a RAID group loses a member, QTS marks it "Warning (Degraded)". If QTS has also set that group to read-only, the status reads "Warning (Degraded - Readonly)".
That status means the group lost its redundancy. It doesn't mean QTS erased your files.
Two different problems can get a member dropped, & they need opposite handling. One is a drive that stalled and got dropped even though its platters are fine. The other is a drive that is physically wearing out.
| Signal | SMR command-timeout drop | Reallocated-sector degradation |
|---|---|---|
| What is happening | A shingled (SMR) drive stalls mid-rewrite while it shuffles overlapping tracks. The stall runs past the SATA command timeout, so the command is canceled for want of a response. | The drive is remapping data off sectors that went bad, or has sectors it cannot yet read waiting to be remapped. |
| What QTS logs | A warning that the disk drive failed or is unplugged. The member is dropped logically. | A "Medium error" alert & a S.M.A.R.T. warning. |
| Is the drive dead | No. It was dropped for being slow, not for being broken. Connected to a stable host it reads normally. | The surface is decaying, & every extra full-surface read pushes it further along. |
A shingled drive rewrites overlapping tracks in bands, so a sustained-write burst can make it pause while it rearranges data. If that pause runs long enough, QTS gives up on the command & treats the quiet drive as gone. The platters never lost anything; the drive was too slow to answer in time. Pull it out, put it on a stable connection, and it reads.
Reallocated and pending sectors are the opposite story. Those counters climb because the magnetic surface itself is failing & the drive is trying to route around the damage. That drive is on a downward path, & the worst thing you can do to it is ask it to read its entire surface.
Why a degraded state is not lost data
When a pool says "Degraded," that's coming from the array's health & membership layer. That layer is the mdadm superblocks on partition 3 that record which drives the array still counts as active members. The status doesn't mean partition 3 got erased. Whether it was an SMR timeout or reallocated sectors, the files on partition 3 are still there.
You can make the loss permanent by reacting destructively: forcing a rebuild, formatting, reinitializing, or running a bad-block scan on a drive that's already physically failing. QNAP's own procedure for a disk in Warning or Error status is a bad block scan. That scan reads the failing surface end to end.
That membership layer is not a QNAP invention, so the triage carries across brands. Synology, Netgear ReadyNAS, Asustor, Terramaster, and Buffalo track array membership in the same mdadm superblock structure QTS uses, which is why recovering a degraded NAS storage pool begins at the same layer on any of them: the mdadm superblocks that record which members the array still counts, read before anything is allowed to write to them. Above mdadm, the brands split up. Buffalo data volumes are predominantly XFS, with ext4 on some units. Netgear ReadyNAS runs LVM with ext4 on OS4 & OS5, & Btrfs directly on mdadm on OS6. So the reconstruction past that point isn't one procedure. QuTS hero is a different animal, because it runs ZFS instead of mdadm.
Image first, especially on the reallocated-sector case
A rebuild reads every surviving member end to end, the marginal one included. On a drive with a rising reallocated-sector count, that full-surface read is exactly the stress that turns a weak drive into a dead one. That is why every member is cloned before any reconstruction runs.
Each drive is imaged through a hardware write-blocker with DeepSpar Disk Imager or PC-3000 Portable III, so the original is never written to & a failing drive is read once, gently, under control rather than hammered by a rebuild loop.
For the SMR-timeout case the imaging is clean because the drive was never broken. For the reallocated-sector case, imaging before any rebuild or bad-block scan is not optional; it is the difference between one careful read pass and a stress test the drive may not survive.
The arithmetic behind that ordering is blunt. Consumer drives carry a worst-case manufacturer rating of one unrecoverable read error per 10^14 bits read, which works out to about 12.5TB, and a single-parity pool that has already lost a member has no second copy of the stripe it is rebuilding. What happens when that read error lands depends on the layer underneath: Linux mdadm, which is what QTS runs, logs the unreadable LBA to its Bad Block Log and carries the resync through, so the loss is scoped to the blocks it could not read rather than to the whole pool. That is still a NAS RAID rebuild that ends in data loss, which is why the imaging pass comes first.
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.
The chunk size comes out of the superblock rather than out of an assumption. So does the metadata version, and it matters: 1.0 places the superblock at the end of the partition with the data starting at offset 0, while 1.2 places it 4 KB from the start with the data pushed further in. Specifying the wrong version shifts every block and produces garbage.
QuTS Hero Recovery
QuTS hero models like the TVS-h674 and TS-h886 run ZFS, with no mdadm or LVM layer underneath. Each vdev label carries several copies of the ZFS uber-block.
If the pool ran deduplication, holding the Deduplication Table in ARC takes roughly 1 to 5 GB of RAM per 1 TB of deduplicated data.
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.
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 a slow on-demand deduplication table load and from uberblock rollback after metadata corruption.
Moving QNAP Drives to a New Chassis: Initialization Overwrite Risk
If what broke was metadata, putting the drives in a different QNAP chassis is dangerous. Pick a migrate or repair option there & it can end with an offer to initialize.
Say yes and the setup wizard writes new RAID superblocks to partition 3 of every drive. The original RAID geometry, stripe size, & disk order are destroyed.
If you moved the drives & now see any prompt to initialize, create, or format the storage pool, power the unit off. Pull the drives, label each one with its bay number, & contact us.
QNAP Member Drive Partition Layout
Partition 3 holds your data. Once you see where everything lives, it's clear why a config failure leaves your files alone.
| Partition | md Device | Contents |
|---|---|---|
sdX1 | md9 | QTS system config mirror. RAID 1 across all drives. |
sdX2 | md256 | Swap (~0.5 GB) |
sdX3 | The mdadm data array | User data storage pool. |
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.
The system arrays hold the QTS configuration database (md9) and swap (md256). Neither is needed for user data extraction.
How do you restore the original QNAP partition layout?
You do not restore partition 1 from inside QTS 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 that manages the kernel md driver) and keeps its own mdadm superblocks on partition 3 of each member drive. On QuTS hero the pool is OpenZFS, & ZFS keeps its own pool metadata.
On QTS, that data-pool metadata comes through partition 1 corruption intact. That's why we read partition 3 directly instead of 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.
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. A metadata 1.0 superblock sits at the end of its own partition. 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.
Identifying the metadata version is part of reading the geometry correctly. If the superblock reports 0.90 or 1.0, it sits at the end of the device and the data begins at offset 0; if it reports 1.2, the superblock sits near the start and the data begins further in.
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 container file that lives inside a hidden directory on the data-pool filesystem on partition 3, not a separate block device on the disk.
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.
Reaching the files is a multi-stage job, not a one-click scan.
What the iSCSI container actually is
- The hidden iSCSI directory
- A hidden directory on the partition 3 data-pool filesystem (ext4 on QTS) 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
- To the host that mounted it, the LUN looked like a whole disk.
- 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.
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. When event counts disagree and
mdadmauto-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.
- 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.
The container has to be reconstructed and loop-mounted first. 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 power 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.
- 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. 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. 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.
- 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
Reconstructing the array is a separate fee, charged per array, on top of the 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.
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 Drives Not Recognized Recovery FAQ
Why does my QNAP say drives are not recognized when they still spin?
One common cause is a power fault in the backplane behind the bay rather than a fault in the drive. When the bay cannot hold the drive powered, QTS stops getting answers from it, warns that the disk drive failed or is unplugged, and drops it from the array. Pulled out of the chassis and connected to a stable power source, that drive usually reads normally.
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. When partition 1 corrupts, QTS shows the storage pools as empty or uninitialized, but partition 3 hasn't been touched. Recovery reassembles the array using the metadata still present on the drives.
Can I move my QNAP drives to a new enclosure?
You can move them physically. Don't power them up in a new QNAP and click through a setup wizard, though. When the original failure was metadata corruption, a migrate or repair attempt can end with an offer to initialize, and saying yes overwrites the data partitions.
What is the difference between QTS and QuTS hero recovery?
QTS uses mdadm software RAID plus LVM and ext4. QuTS hero uses OpenZFS with no LVM layer. For QTS, we reassemble mdadm and activate LVM volumes on a Linux workstation.
Will a firmware update fix drives not recognized?
A firmware update will not repair a dead backplane, 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 member's own data partition, partition 3.
Can I use QNAP's own recovery tools to fix unrecognized drives?
Not before the drives are imaged. We don't recommend running any QNAP repair or restore utility until every drive has been cloned.
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. The -m flag is what lets ZFS import a pool whose log vdev is gone instead of refusing. This is a separate failure from a slow on-demand DDT load 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. Recovery has to reassemble the array read-only, mount partition 3, extract the container file, then loop-mount it to reach the files.
Does a degraded QNAP pool mean my data is lost?
No. A degraded status comes from the array's health and membership layer. That's the mdadm superblocks on partition 3, which record which drives the array still counts as active members. It is not erasure of your files, which live on that same partition 3 and stay intact when a member is dropped. Doing something destructive once the pool shows degraded can make the loss permanent: forcing a rebuild, formatting, reinitializing the pool, or running a bad-block scan on a drive that's physically failing. The safe move is to power down, image every drive read-only, then reassemble the array offline.
My SMR drive keeps dropping out of the QNAP pool. Is it dead?
Usually not. Shingled (SMR) drives rewrite overlapping tracks in bands, so a sustained-write burst can make the drive stall while it rearranges data. If the stall runs past the SATA command timeout, QTS cancels the command, warns that the disk drive failed or is unplugged, and drops the member. The platters never lost anything. The drive was too slow to answer in time, not broken. The correct response is image-first: clone the drive through a write-blocker and read it on a stable host, rather than force a rebuild. A rebuild reads every surviving member end to end, which is the exact stress you want to avoid if any drive in the set is marginal.
How much does QNAP drives-not-recognized recovery cost?
Pricing is per drive, multiplied by the number of drives that need imaging. When the fault was the backplane or the config and the drives are healthy, pricing starts at $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.. We bill array reconstruction as a separate fee on top of per-drive imaging. No data, no recovery fee.
Since 2008
Established
As Featured In
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.