NAS Not Detecting Drives
When a NAS suddenly reports its disks as missing, uninitialized, or not recognized, the platters are usually fine. The fault sits upstream, either in the transport layer that connects the drives to the controller or in the metadata the operating system needs to assemble the array. We separate those two cases by imaging every member offline and reading the on-disk metadata from the clones, so the original drives are never written to. Nationwide service is mail-in to our lab at 2410 San Antonio Street, Austin, TX. Free evaluation. No data recovered means no charge.
What a NAS detection failure usually means
A NAS that cannot detect its drives is rarely simultaneous platter failure. The cause is almost always a transport-layer disconnect, such as a SAS expander reset or a backplane power MOSFET, or logical array-metadata corruption, such as a zeroed mdadm 1.2 superblock or a corrupted QNAP partition-1 config database. Power down immediately and image every member. Do not power-cycle, reseat, initialize, or rebuild.
Why is my NAS not detecting the drives?
Two faults produce one screen. Path A is transport: healthy drives, but power or signaling to the controller dropped. Path B is logical: reachable drives, but a corrupt mdadm superblock, LVM header, or config partition. Image first, then read the metadata to tell them apart.
A NAS fails to detect its drives for one of two mutually exclusive reasons, and the recovery path is different for each. Most consumer and small-business NAS appliances are a Linux box running mdadm software RAID and LVM under a graphical interface, so detection depends on a chain of conditions: the drive must receive power, spin up, negotiate on the bus, present a partition table, and expose a valid mdadm superblock and LVM header. A break anywhere in that chain produces the same symptom on the screen, a missing or uninitialized disk, with very different physical causes underneath.
Path A: physical / transport
The drives are electrically healthy but the appliance cannot reach them. A blown power MOSFET on a shared rail, a SAS expander that keeps resetting, a sagging PSU, or oxidized connectors will drop several drives at once even though the platters are untouched.
Path B: logical / metadata
The drives spin up and report healthy SMART, but the OS cannot assemble the array because the metadata is gone: a zeroed mdadm 1.2 superblock, a lost LVM physical-volume header, an overwritten partition table, or, on QNAP, a corrupted partition-1 configuration database.
Do this first: power the unit down. Every reboot, reseat, or Repair click while you are still guessing which path you are on can move a recoverable case into the unrecoverable column.
Which dmesg signature separates a backplane fault from a drive fault?
The kernel ring buffer tells you which path you are on before you touch a screwdriver. Capture dmesg and /var/log/messages off the unit, or off the members on a bench host, before you reseat, reboot, or image anything. Those buffers are the only record of how the drives dropped, and the first reboot overwrites them. A shared transport fault and a single-drive fault leave different fingerprints.
# Shared transport fault (backplane / SAS expander):
# several members drop in the SAME dmesg window, with mpt2sas/mpt3sas reset messages,
# transport "device blocked" and link-down entries, and NO per-drive media or ATA error
mpt3sas_cm0: ... reset ...
sdX: device blocked
end_device ... : link down
# Single-drive fault: one target resets in isolation,
ataN.00: failed command
# or the member enumerates cleanly but carries no array metadata:
mdadm --examine /dev/sdX1 -> No md superblock detected # or a mismatched array UUIDSeveral targets dropping in one window with mpt2sas or mpt3sas resets and link-down entries, and no per-drive media or ATA error, is a shared transport fault: the platters are healthy and the members read end to end once imaged on working hardware.
A single ata bus reset scoped to one target, or a clean enumeration where mdadm --examine reports no md superblock or a mismatched array UUID on one member, is a per-drive superblock or firmware fault on that disk, not a backplane fault.
Are the drives dead or is it the backplane?
Usually the backplane. When several members vanish together while others stay online, the shared transport layer failed, not the platters: a blown power MOSFET, a SAS expander reset cascade, a sagging PSU, or a dead sideband management bus. Imaged on working hardware, those drives read end to end.
If several drives disappeared together while others in the same chassis are fine, the fault is almost certainly in the shared transport layer, not in the individual disks. A NAS backplane interfaces every drive to the motherboard through shared power rails and a shared signaling path, which means a single component failure can take down a whole bank of healthy drives at once.
Backplane power MOSFET failure
NAS backplanes switch the 5V logic rail and the 12V spindle-motor rail through surface-mount power MOSFETs. When one of these parts fails, for example a 4957AGM-class dual MOSFET governing a rail, power is severed instantly to the affected bay or the entire enclosure. The NAS CPU keeps running and the OS boots normally, but the drives behind the dead rail never spin up and never announce themselves on the bus. To the management UI the disks have simply vanished. This is non-destructive to the data: the platters were never touched, and the array reassembles cleanly once the members are imaged on working hardware.
SAS expander reset cascades
Larger NAS and server chassis fan out many drives behind a SAS expander connected to a single host bus adapter port. The expander behaves like a switch, and when one aging drive starts returning command timeouts, the Linux mpt2sas or mpt3sas driver responds by resetting the entire expander to re-establish communication. That reset briefly interrupts every drive on the topology. If the failing drive keeps timing out, the resets loop, and healthy members occasionally fail to recover from the aggressive bus reset and drop out of the array. The result is that one marginal disk causes the controller to report several good drives as missing.
PSU spin-up current sag
Hard drives draw far more current spinning up from rest, overcoming stiction and accelerating the platters, than they do at idle. As a power supply ages and its 12V rail capacitors degrade, it may no longer deliver the peak amperage needed to spin up several high-capacity drives at once. The voltage sags, the spindle motors stall, and the drives fail to report their presence during the controller scan. The array comes up degraded or empty even though every disk is healthy on a supply that can source the inrush current.
Connector oxidation and the reseat trap
Years of thermal cycling and ambient humidity build a microscopic oxide layer on the gold SATA and SAS contacts, which can raise contact resistance enough to drop a drive. The standard advice is to reseat the drive so the pins scrape the oxide away. That can work once, but repeated power-cycling to force detection is a serious risk: if a drive dropped because of a weak preamp or marginal heads, forcing it through repeated thermal expansion and spin-up surges accelerates head failure, and an unstable head can contact the platter and turn a transport error into permanent rotational scoring.
SAS expander and backplane management-bus failure
A drive can receive 12V, spin up to speed, and still never appear on the host bus adapter, because spin-up and enumeration travel different paths. The data and power conductors are separate from the sideband management bus that the backplane uses to report slot, presence, and LED state, typically SGPIO or an I2C link to the expander.
When that management path fails on its own, the platters are untouched but the expander can no longer present the drive to the HBA, so the member reads as absent.
Worse, an expander that starts faulting triggers a reset cascade in the Linux mpt2sas or mpt3sas driver, and a single reset drops every healthy member behind it at once. dmesg records the transport-layer connection drops rather than any media error. Because nothing wrote to the platters, the array reassembles cleanly once each member is imaged on a working backplane and the geometry is reconstructed in software.
Staggered spin-up timeout on hot-swap enclosures
On JBOD and expander enclosures that use staggered spin-up (SSU, or the drive-side PUIS feature) to limit inrush current, drives power up in sequence rather than all at once.
A marginal or high-capacity disk that takes longer to reach ready can exceed the controller's discovery timeout window: it shows up during the initial bus scan, then drops out mid-scan before it finishes reporting ready. To the operator this looks like intermittent detection, a drive that comes and goes between boots, rather than a dead disk.
dmesg and smartctl on a working host confirm the state machine timed out, not the media. The platters are untouched, the member simply failed to report ready in time, and it images normally once it is read on hardware without an aggressive discovery deadline.
Why did my Synology or QNAP drop multiple drives at once?
Synology & QNAP are Linux mdadm boxes, so one logical event drops every member: an interrupted write zeroes a 1.2 superblock, mismatched event counts block assembly, or a corrupt config partition makes the UI call healthy disks unrecognized. The data partitions stay intact underneath.
If the drives spin up, report healthy SMART, and still will not assemble into a volume, the failure is logical: the OS cannot read the metadata labels it needs to instantiate the array. Synology and QNAP both run standard Linux storage stacks, so the failure lands in the same places every Linux array can fail: the mdadm superblock, the LVM headers, the partition table, or a vendor configuration database.
The mdadm 1.2 superblock
Linux software RAID identifies each member by a small metadata block called the superblock. Synology and QNAP format the data pool with a version 1.2 superblock, written at a 4 KiB offset from the start of the partition, an offset chosen to keep 4K sector alignment and leave room for header data ahead of the array payload. The small system and swap arrays on those units (the Synology md0/md1 and the QNAP /dev/md9 config set) instead use the legacy version 0.90 superblock stored at the end of the partition, so the version and offset depend on which array you are reading. The command below reads that structure without mounting anything, and on a recovery case it is run only against a write-blocked clone, never the original drive.
mdadm --examine /dev/sdX1A healthy member returns the array UUID, the RAID level, an event counter, and the data offset that marks where your payload begins:
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
UUID : a1b2c3d4:e5f60718:29304152:63748596
Level : raid5
Data Offset : 2048 sectors
Super Offset : 8 sectors
Events : 184213
State : clean
Active Devices : 4If an unexpected power loss interrupts an array write, or a firmware bug initializes a drive incorrectly, that 4 KiB sector can be overwritten with zeros or garbage. To the NAS the drive is blank and not a recognized member, even though your data still starts safely at the data offset and runs clean to the end of the disk. Mismatched event counts across members produce the same outcome: the array refuses to assemble because the superblocks disagree about which member was current at the moment of failure.
Superblock magic versus array UUID mismatch
"Not detected" on the logical side splits into two distinct failures that look identical in the UI but need opposite handling. In the first, the version 1.2 magic value a92b4efc at the 4 KiB offset is zeroed or garbled, so the member looks blank to mdadm even though the data offset further in is intact. In the second, every superblock is perfectly readable, but the members disagree: a mismatched array UUID or divergent event counts make the assembler refuse to bring the set up even though no metadata is missing. Telling these apart matters, because the fix differs.
mdadm --examine /dev/sdX1 # read-only; run on the CLONE, never the originalmdadm --examine is read-only and reports both states without touching the disk. When the magic is gone, the member is rebuilt from its siblings' geometry. When the magic is intact but event counts are close, a forced assembly can bring the array up, but only against write-blocked clones, never the original members:
mdadm --assemble --force /dev/md0 /dev/loopA /dev/loopB ... # on clones onlyA third variant of the same symptom is purely cosmetic from the array's point of view: corruption in the first system partition that holds the appliance configuration database, the QNAP /dev/md9 set or the Synology /dev/md0 OS partition, makes the management interface report the disks as unrecognized while the mdadm data partition stays structurally perfect. The pool looks empty, but the array underneath assembles normally once the data partitions are parsed from the clones.
What does the md state transition tell you: active, faulty, or removed?
The way a member left the array is itself a diagnostic, and /proc/mdstat plus the kernel log preserve it. When a disk stops answering, md marks it faulty in the surviving members' superblocks as soon as the block layer returns I/O errors, then evicts it to removed.
A drive with genuine media trouble dwells in the faulty state longer, because the kernel keeps retrying sector reads before md gives up on it. How long a member sat in faulty, read alongside the dmesg transport log, is what separates a clean transport dropout from a failing disk.
This governs how the array comes back. Linux md refuses to auto-start a RAID 5 or RAID 6 array that is both dirty and degraded, because recomputing parity from an out-of-date member would silently corrupt the stripes it touches. Overriding that refusal with a forced assembly is an explicit administrator action, and it is safe only against write-blocked clones of the members, never the original disks.
cat /proc/mdstat # read-only: shows active / faulty / removed members
mdadm --assemble --force /dev/md0 /dev/loopA /dev/loopB ... # clones only, never originalsLVM headers and partition tables
Synology and QNAP layer LVM on top of mdadm, so the logical volume depends on an intact physical-volume header, and the whole stack depends on the GPT partition table that marks where the mdadm partition begins. If a firmware update or a mis-aimed command overwrites the GPT, the system loses the boundary pointers, cannot find the start of the mdadm partition, cannot read the superblock, and cannot activate the volume group. One overwritten header at the bottom of the stack makes every layer above it disappear.
QNAP partition-1 configuration database
QNAP reserves the first partition of every member, assembled as /dev/md9, for its system configuration database, including the /etc/enclosure_0.conf file that maps physical ports to drive World Wide Names. A sudden power loss, an aborted rebuild, or a failed firmware update can garble or zero that file. On reboot the unit mounts partition 1, fails to read the mapping, and can no longer associate the physical disks with the storage pool, so it reports the drives uninitialized or missing. The user data on partition 3 is physically untouched. This is a logical fault, and it reassembles offline once the metadata is parsed from the clones.
The same architectural reality is why an Synology array or a QNAP array can be reassembled and mounted on a standard Linux workstation. There is no proprietary silicon between you and the data, only standard Linux metadata that has to be read in the right order.
Why did my Synology volume crash after the NVMe cache failed?
On a DS920+, DS1520+, or DS1621+ running an M.2 NVMe read/write cache, a cache device that drops off the PCIe bus loses every uncommitted dirty write it was still buffering. That leaves the underlying mechanical Btrfs array half-written, so DSM reports Volume Crashed even though the HDDs are healthy.
A detection failure or a Volume Crashed banner can originate at the cache layer, not at the data drives. The DS920+, DS1520+, and DS1621+ accept M.2 NVMe SSDs that DSM can configure as a read/write cache sitting in front of the mechanical HDD array.
When that cache device drops off the PCIe bus, the dirty pages it had accepted but not yet flushed to the spinning disks are gone, and the Btrfs filesystem on the HDDs is left in an inconsistent, partially written state. The platters spin, image end to end, and report clean SMART, yet DSM marks the volume crashed or shows the data drives as unrecognized.
How a dropped NVMe cache crashes the volume
Consumer-grade NVMe controller firmware can panic and disappear from the PCIe bus under heavy sustained write loads. When a read/write cache vanishes mid-flush, the writes that were acknowledged in the cache but never committed to the array are permanently lost. The Btrfs Copy-on-Write generation trees on the mechanical Synology array are left referencing data extents the cache was supposed to write and never did, so the current tree root is corrupt.
The recovery does not try to repair that tree in place. It walks backward to an intact historical root. A Synology volume is Btrfs layered on LVM layered on mdadm, so the array is first assembled read-only from the member clones, the LVM volume group is activated, and the Btrfs tools then target the resulting logical volume, not any single member:
# assemble the array read-only from the member clones, then activate LVM
mdadm --assemble --readonly /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2
vgchange -ay # activate the volume group
btrfs-find-root /dev/mapper/vg1-volume_1 # read-only; run against the assembled logical volume
btrfs restore -t <bytenr> /dev/mapper/vg1-volume_1 /mnt/out # extract from a chosen generationThe Btrfs tools run only against the logical volume assembled from the write-blocked clones of the members, never the original disks. They read the older Copy-on-Write generation roots that predate the corruption and extract files from whichever generation is intact.
What never happens is btrfs check --repair or a mount -o recovery,ro framed as a safe inspection: both write to disk, and a repair pass overwrites the historical generation roots that are the entire reason the data is still recoverable. On a Copy-on-Write filesystem the old roots are the recovery path, and any in-place repair destroys them.
Read-only cache versus read/write dirty cache
Before any array reassembly, the first triage step is to confirm whether the M.2 slot is populated and how that device was configured, because the two cache modes fail in opposite ways. A read-only cache holds nothing but copies of data that already lives on the array, so if it drops off the bus the array loses no writes and the volume stays consistent.
A read/write cache, by contrast, acknowledges writes in the cache before they reach the HDDs, so a device that drops mid-flush takes uncommitted writes with it. Knowing which mode was configured tells you immediately whether the cache dropout could have caused the corruption or whether the fault lies elsewhere in the stack.
SMR drives behind the cache and stall-then-eject
A related sub-case appears when consumer SMR (Shingled Magnetic Recording) HDDs sit behind the NVMe cache. When the cache flushes a large run of buffered writes, those sustained sequential writes can overflow the SMR drive's CMR cache zone. The drive then stalls for 30 to 60 seconds while it reshingles tracks in the background, and the Linux kernel can read that latency as a dead drive and eject the member from the array.
On a parity array, ejecting a member during a heavy flush can drop the volume. The risk is probabilistic, not a fixed countdown: it depends on the write pattern, how full the CMR cache zone already is, and the controller timeout, so an SMR member may survive many flushes and then eject on one. We read slow SMR members through DeepSpar Disk Imager, which tolerates the long latency rather than ejecting on it.
What to do when the cache drops the volume
Power the unit down immediately and do not try to re-add or re-initialize the cache device. Re-initializing the cache will not recover the lost dirty writes and can prompt DSM to rewrite the volume metadata.
Image every mechanical member through a hardware write-blocker on PC-3000 Express or DeepSpar Disk Imager, assemble the array virtually from the clones and activate the LVM volume group, then reconstruct the Btrfs filesystem read-only against the resulting logical volume with btrfs-find-root and btrfs restore against an intact generation. The original disks are never written to.
Can a corrupt config partition make every drive read as not detected?
Yes. On WD My Cloud, Buffalo TeraStation, and Netgear ReadyNAS, a corrupt firmware, OS, or configuration partition makes the unit report every disk missing or uninitialized while the data volume underneath is intact. The fix is to parse the array offline, not to initialize or factory-reset the box.
The same not-detected screen shows up across brands when the system partition that holds the appliance firmware or configuration is damaged while the data partitions stay perfect. Synology and QNAP are covered above; the pattern repeats on Western Digital, Buffalo, and Netgear hardware, each with its own trap.
| Brand | Symptom on the screen | What is actually damaged | Safe fix |
|---|---|---|---|
| WD My Cloud | Shares vanish after a firmware update | Config or firmware partition; the ext4/mdadm data volume is untouched | Image the member, parse the array offline on Linux |
| Buffalo TeraStation | NASNavigator reports Unformatted or EM Mode | Boot-partition corruption; the XFS/mdadm data volume is typically intact | Reassemble mdadm read-only from clones, then replay the XFS log |
| Netgear ReadyNAS | Unit will not mount; a factory reset is offered | System-partition damage, not disk failure; OS4/OS5 use mdadm+LVM+ext4, OS6 uses mdadm+Btrfs directly | Image members first; never factory-reset OS6, which destroys the data |
WD My Cloud: a corrupt config partition hides an intact data volume
On WD My Cloud units running OS3 or OS5, a corrupt configuration or firmware partition makes the unit report its drives missing even though the data volume is untouched. The classic symptom is network shares disappearing after a firmware update. That is a logical fault on the system partition, recoverable by parsing the array offline rather than reinitializing the unit.
A single-bay My Cloud is embedded Linux with its drive on a native SATA lane to the onboard SoC, not a USB enclosure, so the data volume is a standard mdadm array formatted ext4. Pulling the bare drive and wiring it to a Windows SATA port will not surface the shares, because the array has to be assembled and mounted on a Linux host, not because the platters are encrypted. Recovery images the member and parses the array offline.
Buffalo TeraStation: EM Mode is a boot partition, not dead disks
Buffalo TeraStation units drop into EM Mode (Emergency Mode) when firmware or boot-partition corruption stops the appliance from booting normally. NASNavigator then reports the unit as Unformatted or in EM Mode, which reads like total drive loss.
The data volume is Buffalo's usual XFS layered over Linux mdadm, and it is typically intact. Recovery reassembles the mdadm members read-only from clones, then replays the XFS log and mounts the filesystem. xfs_repair -L zeroes the log and is destructive, so it is never the first move on the original members.
Netgear ReadyNAS: get the layer order right, and never factory-reset OS6
Netgear ReadyNAS recovery depends on the OS generation, and getting the abstraction order wrong fails the job. Legacy OS4 and OS5 units stack mdadm, then LVM, then ext4: reassemble the md members read-only, activate the volume group, then mount and check ext4 (for example e2fsck -b against a backup superblock), in that order.
OS6 units drop LVM entirely and place Btrfs directly on top of mdadm, so there is no volume group to activate and the Btrfs tools target the md device directly.
A factory reset on ReadyNAS OS6 destroys user data. It rewrites the configuration and the data, not just the settings, so the reset offered on a unit that will not mount is an overwrite, not a repair. Image the members first.
Because all three stacks are standard Linux metadata, the members image on the bench and the array reconstructs virtually from those images with Data Extractor Express RAID Edition, R-Studio, or UFS Explorer. No proprietary controller is required, only the layers read in the correct order.
Why does reseating or power-cycling the drives make it worse?
Because each action writes. Power-cycling stresses marginal heads toward a crash, slot-swapping a foreign disk makes the OS initialize it & overwrite the superblock, and a Repair click rewrites parity and metadata. A safe transport fault becomes a destructive logical overwrite. Power down & image first.
Because the actions that feel like troubleshooting are the same actions that destroy data. Forum and basic support advice almost always escalates risk on a NAS that is already in trouble.
- Repeated power-cycling. If a member dropped because of marginal heads, every forced spin-up adds stiction and surge stress. A head-slap on a weak head converts a non-destructive logical or transport error into a scratched platter.
- Slot-swapping a foreign disk. Inserting a drive the NAS considers unrecognized into a different bay frequently prompts the OS to initialize it as a new volume, which overwrites the mdadm superblock and partition table on the spot.
- Using the Repair or Recover button. A DSM Repair, a QNAP Recover, or a manual
mdadm --createwithout--assume-cleanwrites fresh parity and metadata across the members. If you force this with a stale or out-of-sync drive, the controller recalculates parity against the wrong data and permanently scrambles the stripes. - Moving the drives to a new chassis. Selecting Migrate or Repair on a new enclosure tells it to rewrite system partitions and forcibly import the array. That import often fails and then offers a fresh install that overwrites the data partitions.
None of these is a recovery step. Rebuilding a degraded array restores redundancy on a working array; it does not recover data, and on a degraded array a single unrecoverable read error on a surviving member behaves differently per controller. Legacy and low-end consumer controllers and HP Smart Array P-series and E-series abort the rebuild and drop the volume offline; modern Dell PERC and LSI/Broadcom MegaRAID puncture the stripe and continue, and Linux md/mdadm logs the bad block and continues. The larger risk is that the rebuild pins marginal same-batch survivors at full read load until one fails mechanically. RAID provides hardware availability, not a backup. The safe move is to stop, power down, and image first.
Re-seating a member erases the evidence of whose fault it was
Re-seating or hot-swapping a member before it is imaged resets the volatile SAS, SATA, and HBA error counters that recorded how the disk dropped, and rebooting the unit overwrites the dmesg transport history the diagnosis depends on. Trying the drive again destroys the record that would prove whether the backplane or the drive dropped the array, which is exactly the question that determines the recovery path.
Preserve the logs, image every member first, and read the array state from the clones. SAS members image on PC-3000 Portable III; SATA members image on PC-3000 Express or DeepSpar Disk Imager.
How is a not-detected drive different from a failed drive?
A not-detected drive is healthy but unreachable: it lost transport or its metadata is corrupt, & it reads end to end once imaged through a write-blocker. A failed drive has a physical fault on that one member, a head crash, seized spindle, or shorted PCB, needing bench work first.
A not-detected drive is usually healthy but unreachable, while a failed drive has a real physical fault. Telling them apart is the whole job, and it is why imaging comes before any conclusion. A drive that returns clean once it is cloned through a write-blocker was never the problem; the problem was the rail, the expander, or the metadata.
- Not detected, transport fault
- The drive is fine. It lost power or signaling through the backplane, expander, or PSU. Imaged on working hardware it reads end to end and the array reassembles.
- Not detected, logical fault
- The drive is fine and reachable, but its mdadm superblock, LVM header, or partition table is corrupt. The data is intact past the metadata and recovers once the array is assembled offline.
- Physically failed member
- A head crash, seized spindle, shorted PCB, or firmware lockout. This member needs physical work, a head transplant on the clean bench or firmware repair, before it can be imaged. In a parity array the other members still carry the stripes.
How do you recover a NAS that will not detect its drives?
Power down, label every bay, & clone each member through a write-blocker on PC-3000 Express or DeepSpar Disk Imager. Read the superblocks & LVM headers from the clones to separate transport from logical fault, reassemble the geometry virtually in R-Studio or UFS Explorer, then extract. Originals are never written.
We recover a NAS detection failure by imaging every member offline and reassembling the array virtually, so the original disks are never written to. The procedure is the same whether the root cause turns out to be transport or logical, because imaging first is what lets us tell the two apart safely.
- 1. Power down and document. Record the NAS model, RAID level, member count, filesystem, and every prior reboot, reseat, or Repair attempt. This evaluation is free.
- 2. Label every bay. Mark each drive with its physical slot number before removal. Slot order is required for correct reassembly.
- 3. Write-blocked imaging. Clone each member through hardware write-blockers on PC-3000 Express or DeepSpar Disk Imager. Mechanically failed members receive head transplants on the 0.02 micron ULPA-filtered clean bench before imaging. Software imaging of marginal members uses
ddrescueor HDDSuperClone with adaptive retry. - 4. Read the metadata on the clones. Run
mdadm --examineagainst each cloned partition, compare event counts, confirm the data offset, and inspect the LVM headers and partition table. On QNAP we check the partition-1 configuration database on/dev/md9. - 5. Offline virtual assembly. Reconstruct the exact array geometry from the cloned images with R-Studio or UFS Explorer. The original disks stay powered off.
- 6. Extract and verify. Mount the reassembled volume read-only, copy the filesystem to fresh target media, and verify it. Working copies are securely purged on request after you confirm receipt.
Related reading: RAID rebuild failure recovery covers what happens when a rebuild aborts partway, and two drives failed covers double-fault parity arrays.
What does NAS array recovery cost?
Priced per member, not per array. Healthy members that dropped for a transport or metadata reason are billed at the per-drive imaging & file-system tier, plus virtual reconstruction quoted after the free evaluation. A mechanically damaged member adds its own head-swap or surface tier. No data, no charge.
NAS recovery is priced per member drive, because the work is imaging each disk and then reassembling the array. A pool of healthy members that dropped for a transport or metadata reason is logical imaging plus reconstruction. A member with mechanical damage adds the head-swap or surface-damage tier for that one disk.
No data, no charge: if we recover nothing from your array, you owe $0. Free evaluation, no diagnostic fee, no obligation.
Example: a four-member array where all disks are healthy but the array will not assemble is priced from the per-member file-system recovery tier (From $250) for each disk, plus array reconstruction quoted after the free evaluation. A member with a head crash adds the head-swap tier ($1,200–$1,500) plus donor parts for that one drive.
+$100 rush fee to move to the front of the queue. Full per-drive pricing is published on our HDD recovery service page.
NAS Detection Failure Questions
Did all my NAS drives really fail at the same time?
Why does my NAS say the drives are uninitialized when SMART looks fine?
Why does my QNAP show an empty storage pool after a firmware update?
Is it safe to reseat the drives or power-cycle the NAS to force detection?
What is the difference between a drive that is not detected and a failed drive?
Can I just move the drives to a new NAS enclosure?
How do you recover a NAS that will not detect its drives?
Can I tell from the logs whether it is the backplane or a dead drive?
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 videoYour NAS lost its drives. Power down before doing anything else.
Free evaluation. No data, no charge. Mail-in from anywhere in the U.S. to our Austin, TX lab.