If your ASUSTOR NAS — an AS-series, Lockerstor, Drivestor, Nimbustor, or Flashstor unit — has dropped its storage pool offline, fallen victim to DeadBolt ransomware, refused to boot after an ADM firmware update, or locked you out of EZ-Connect remote access after a service-side change, you’ve reached the right team. ASUSTOR has built a respectable share of the prosumer and small-business NAS market since the brand launched in 2011 as an ASUS subsidiary, particularly among customers attracted by competitive hardware specifications and the ADM operating system’s feature breadth. The deployed ASUSTOR fleet skews toward IT-aware home users, small offices, and creative professionals — an audience that knows what they bought, takes the failure personally, and wants their data back. Gillware has been recovering ASUSTOR data from our ISO 5 Class 100 cleanroom in Madison, Wisconsin. ASUSTOR cases are scoped at intake by an engineer who has handled the failure mode you’re looking at — not by a generic sales gate. See also our NAS data recovery hub.

Open an ASUSTOR recovery case →

How ASUSTOR NAS Devices Work

ASUSTOR’s product line is structured into named sub-brands that target different market segments, all running the same ADM operating system underneath. Identifying the sub-brand and generation is the first step in scoping a recovery, because the hardware platform and the era of deployment determine the recovery profile.

AS-series. The original ASUSTOR lineup, structured around model numbers in the AS-3xxx through AS-7xxx range. Common entry-level models include the AS3102T, AS3104T, AS3202T, AS3204T (two- and four-bay, Intel Celeron, 2015 through 2019 production). Common mid-range models include the AS5202T, AS5204T, AS5304T, AS5402T (two- and four-bay, more capable hardware). Common higher-end models include the AS6404T, AS6604T, AS6706T, AS6404T, and the older AS-50x and AS-31x lineups still in deployment. Earlier ASUSTOR generations — the AS-202T, AS-204T, AS-304T from the 2013 through 2015 production window — are now eight to twelve years old and reaching their end-of-life service period.

Lockerstor. ASUSTOR’s premium sub-brand, launched in 2019. Common models include the Lockerstor 2 (AS6602T), Lockerstor 4 (AS6604T), Lockerstor 4 Gen2 (AS6704T), Lockerstor 8 (AS6508T), Lockerstor 10 (AS6510T), and the newer Lockerstor Gen3 variants. The Lockerstor line targets users who would otherwise consider higher-end Synology Plus models or QNAP TVS units.

Drivestor. ASUSTOR’s entry-level sub-brand, launched in 2021 to replace the older AS-31xx and AS-32xx tiers. Common models include the Drivestor 2 (AS1102T), Drivestor 2 Pro (AS1102TL), Drivestor 4 (AS1104T), Drivestor 4 Pro (AS1104TL). Aimed at first-time NAS buyers, home backup users, and small home offices.

Nimbustor. ASUSTOR’s gaming and multimedia sub-brand, launched in 2019. Common models include the Nimbustor 2 (AS5202T), Nimbustor 4 (AS5304T), Nimbustor 2 Gen2 (AS5402T), Nimbustor 4 Gen2 (AS5404T). The hardware is similar to the AS5xxx tier but the branding targets enthusiast media-server use cases.

Flashstor. ASUSTOR’s NVMe-only NAS sub-brand, launched in 2023. The Flashstor 6 (FS6706T) and Flashstor 12 Pro (FS6712X) replace the traditional hard-drive bays with M.2 NVMe slots, which puts these units in a fundamentally different recovery profile from the rest of the ASUSTOR lineup. NVMe storage in a NAS context has different physical failure modes, different firmware-recovery considerations, and different ZFS-and-btrfs implications than spinning-disk NAS — the architecture is recent enough that the field experience is still accumulating.

ADM — the ASUSTOR operating system. ADM (ASUSTOR Data Master) is a Linux distribution with ASUSTOR-specific management layers and packaged services. ADM has shipped in major versions 1, 2, 3, and 4, with ADM 4 (released 2021) being the current platform. The storage stack underneath ADM is the same general Linux pattern used by other NAS brands: mdadm software RAID for the redundancy layer, LVM for volume management, and ext4 or btrfs as the filesystem. Newer ADM 4.x deployments default to ext4 for compatibility and offer btrfs as an option for volumes that need snapshot capabilities; some Lockerstor configurations ship with btrfs as the default. Recovery proceeds off-controller from the imaged drives without depending on a functioning ADM install.

MyArchive. ASUSTOR’s hot-swappable archive-drive feature that lets a designated drive bay function as removable storage rather than as part of the primary RAID array. The MyArchive drive uses an ASUSTOR-specific partition layout that other NAS brands don’t recognize, and recovery from a failed MyArchive drive proceeds independently of the primary array recovery.

EZ-Connect and AiData. ASUSTOR’s remote-access and mobile-app stack. EZ-Connect routes external access through ASUSTOR’s cloud-service backend; AiData is the mobile companion app. Both depend on the ASUSTOR cloud-service backend remaining operational and on the unit being able to reach it — conditions that have changed multiple times over the platform’s history and that figure into specific failure modes below.

ASUSTOR NAS Failure Conditions That Lead to Data Loss

The patterns below are the ones that disproportionately bring ASUSTOR cases to our lab.

DeadBolt ransomware (February 2022). The defining ASUSTOR security event. On February 21, 2022, the DeadBolt ransomware campaign that had previously targeted QNAP shifted its focus to ASUSTOR, exploiting vulnerabilities in the ADM EZ-Connect remote-access service to gain access to internet-exposed ASUSTOR units, encrypt user files with the .deadbolt extension, and overwrite the ADM login interface with a ransom demand. ASUSTOR’s incident response included emergency firmware updates pushed to all affected models, temporary disablement of EZ-Connect to limit the attack surface, and a series of advisories naming specific ADM versions as required for protection. Recovery from a DeadBolt-affected ASUSTOR unit depends on the variant, whether the encryption process completed, whether ADM snapshots from before the event exist and are reachable (DeadBolt did not always destroy snapshots), and whether backup repositories on attached drives or remote destinations survived the event. We recover by extracting the drives, imaging them, identifying the pre-encryption file state where possible, and applying snapshot history or backup repository content where it survived.

Storage pool offline. The most common ADM error state we see outside of the DeadBolt context. The storage pool reports as offline in the ADM Storage Manager, shared folders are inaccessible from the network, and the underlying drives may show as present but the storage pool layer has refused to assemble them into a working volume. The underlying cause is usually multi-drive failure beyond the pool’s redundancy, mdadm superblock damage on a single drive that escalated to the whole pool, or volume-management metadata corruption that ADM couldn’t navigate cleanly.

ADM firmware update failures. ADM updates are generally low-risk, but the ADM 3 to ADM 4 transition in 2021 produced a wave of post-update cases — units that completed the upgrade apparently successfully, rebooted, and came back with storage pools offline or volumes unmountable. Several specific ADM 4.0 and ADM 4.1 minor versions have been documented as causing post-upgrade volume mount failures on units that had been running stably on ADM 3. We see post-upgrade cases on a regular cadence and the recovery proceeds off-controller from the drive images without depending on the ADM install state.

EZ-Connect lockout after ASUSTOR backend changes. ASUSTOR has reorganized the EZ-Connect cloud-service backend multiple times, and units that depended on EZ-Connect for remote access have sometimes found themselves locked out after service-side configuration changes, after the post-DeadBolt EZ-Connect mitigation steps, or after their unit’s firmware version fell out of compatibility with the current backend. The local SMB shares typically still work; the cloud-mediated paths don’t. The data on the drives is unaffected, but the user-facing remote access patterns are. Where customers can no longer log in to their own unit even locally because of EZ-Connect-mediated authentication issues, we extract the drives and read the data directly.

MyArchive drive failures. A MyArchive drive in an ASUSTOR unit operates as removable storage with an ASUSTOR-specific layout. When a MyArchive drive fails — surface damage, controller failure, motor failure — the recovery is a single-drive recovery on a non-standard partition layout. The primary RAID array is unaffected by MyArchive drive failures, but the data on the MyArchive drive itself is its own recovery scope and requires understanding ASUSTOR’s specific MyArchive on-disk layout.

Multiple drive failure beyond fault tolerance. The same condition that takes down standard RAID arrays applies to ASUSTOR. RAID 5 (and ASUSTOR’s analogues) tolerates one drive failure; RAID 6 tolerates two. We see this pattern most often on units in service for five to ten years with the original drive cohort. First drive fails, the storage pool drops to degraded, the user inserts a replacement drive and starts a rebuild, a second drive fails mid-rebuild, and the pool drops offline. Surviving drives are often only partially failed, which is why cleanroom imaging frequently resurrects enough of a failed-status drive to make recovery possible.

Drive replacement and rebuild failures. A drive fails on a redundant ASUSTOR array. ADM marks the pool degraded. The owner inserts a replacement drive and starts a rebuild from the Storage Manager interface. The rebuild reads every surviving sector across the remaining members and copies into the new drive. If a read error appears on a surviving member during the rebuild, the rebuild aborts and the pool can drop offline. Large arrays on high-capacity drives are particularly exposed because the rebuild reads enough surface that an unrecoverable read error becomes statistically likely on aging drive cohorts.

btrfs metadata corruption on newer Lockerstor and AS-series units. ADM 4.x makes btrfs available as a storage option on supported hardware, and Lockerstor configurations frequently ship with btrfs as the default. Where btrfs hits metadata-tree corruption that the kernel cannot navigate cleanly, the volume can become unmountable even though the underlying data extents are intact. btrfs scrub, btrfs check, and ADM’s filesystem-repair tools sometimes fix this and sometimes make it worse. We work against the on-disk state at intake and reconstruct the filesystem trees off-controller.

Failed migration between ASUSTOR models. A common ASUSTOR scenario: an owner with a working older AS-series unit (AS5202T, AS6404T) buys a newer Lockerstor or Flashstor model and attempts to migrate the drives. ASUSTOR documents migration paths and compatibility, but field cases that arrive at our lab are typically the ones outside the documented paths or inside the documented paths that didn’t complete cleanly. Symptoms include the destination unit refusing to recognize the storage pool, prompting to reinitialize the drives, or appearing to import the pool but mounting it inaccessibly.

Boot partition failure on aging hardware. ASUSTOR units, like other Linux-based NAS platforms, mirror the operating system across the drives in the array. When the boot partition on multiple drives fails simultaneously — from a power event, an interrupted firmware update, or accumulated filesystem damage on the system partition — the unit can refuse to boot past the initial hardware checks while the data partition remains intact. We recover by extracting the drives and reading the data partition directly.

End-of-life hardware on older AS-series units. The AS-202T, AS-204T, AS-304T, AS-606T, and similar early-ASUSTOR units from the 2013 through 2016 production window are now eight to thirteen years old. Electrolytic capacitor failures on the power supply boards are increasingly common, the original drive cohorts have aged well past their reasonable service envelope, and ASUSTOR has reduced active support for the earliest ADM versions that ran on these units.

NVMe-specific failures on Flashstor units. Flashstor’s all-NVMe architecture introduces failure modes that the rest of the ASUSTOR lineup doesn’t have. NVMe drive controllers fail with different signatures than traditional SATA hard drives; thermal throttling and sustained-write degradation produce different recovery scenarios; firmware-level recovery on NVMe is fundamentally different from spinning-disk drive recovery. The Flashstor platform is recent enough that the failure profile is still accumulating, and we expect cases to grow in volume as the deployed fleet ages.

Power surge and unclean shutdown. ASUSTOR units handle unclean shutdowns reasonably well most of the time, but a sufficient power event can damage the controller board, multiple drives, or both. The pattern we see is “the ASUSTOR came back up after the storm and now the storage pool won’t come online” or “the unit came back up showing two failed drives” — sometimes both drives are genuinely failed, sometimes only one is and the other has been flagged as a precaution.

One pattern worth naming separately. The standard ASUSTOR Support and community-forum guidance for storage pools offline, post-update mount failures, and degraded RAID conditions is usually some combination of “run the storage pool repair function,” “reseat the drives in a specific order,” or “create a new pool and restore from backup.” Those steps work cleanly when the array is healthy underneath. When the underlying condition is multi-drive degradation, btrfs metadata corruption, or a DeadBolt event where snapshot history is the recovery path, the same steps destroy the data the customer called to save. The real decision in front of a downed ASUSTOR is not “ASUSTOR Support versus recovery shop” — it is “execute the documented repair now and accept whatever happens” versus “image the drives first and recover before any further ADM-side action.”

How We Recover ASUSTOR NAS Arrays

We never operate a failed ASUSTOR NAS during recovery. Running a degraded array, attempting a storage pool repair through ADM, or letting the unit auto-rebuild during diagnostic work all risk turning a recoverable case into an unrecoverable one. Each drive is removed from the chassis, bay positions documented, and imaged on isolated, write-blocked hardware in our cleanroom. Physically damaged drives are repaired with donor parts as needed before imaging — head replacements, PCB swaps, firmware recovery, and platter burnishing where the surface has been damaged. NVMe storage from Flashstor units is imaged on isolated NVMe-aware hardware with the appropriate write-blocking precautions. We work from drive images for everything that follows; the originals stay shelved and untouched.

Once we have a verified image of every drive, our reconstruction work begins. HOMBRE — Gillware’s in-house RAID and filesystem reconstruction software, built and maintained by the engineers who use it — inspects every single sector of every drive image, identifies the ASUSTOR-specific partition layout (whichever ADM generation it came from), parses mdadm superblock structures, reconstructs the LVM and filesystem layers above, and assembles the storage pool virtually from the drive images. We don’t depend on a working ASUSTOR chassis to read the data; HOMBRE reads it directly from the drives.

On standard ADM ext4 arrays, the recovery handles the ASUSTOR partition layout, mdadm RAID reconstruction, LVM volume group parsing, and ext4 filesystem recovery. On Lockerstor and AS-series btrfs configurations, the recovery includes btrfs metadata-tree reconstruction with snapshot history where present. On MyArchive drives, the recovery operates against the ASUSTOR-specific archive partition layout independent of the primary array. On Flashstor NVMe arrays, the recovery proceeds from the imaged NVMe controllers with the appropriate filesystem reconstruction on top.

On DeadBolt ransomware cases, the recovery scope expands to identifying which files were touched by the ransomware, which file regions are recoverable from snapshot history that survived the event, and which files can be partially salvaged through forensic reconstruction of the pre-encryption state. Where ADM snapshot history exists from before the encryption event, that history is often the cleanest recovery path back to a known-good state. Where backup repositories on attached external drives or remote destinations survived the event, those repositories become part of the recovery scope.

The engineers running this work see the failure modes catalogued above on a weekly basis. There is no ASUSTOR NAS condition on this page that we are encountering for the first time. HOMBRE assembles the array as a virtual volume from the images, and the filesystem layer is recovered against the assembled volume. The deliverable is a file list and an outcome you can act on, rather than an ASUSTOR that’s been talked back into mounting and then expected to keep working.

Related Pages

By NAS brand: WD NAS · Synology · Buffalo NAS · QNAP NAS · Seagate NAS · Netgear ReadyNAS · Drobo · LaCie · FreeNAS / TrueNAS. Related topics: Ransomware recovery (especially relevant for DeadBolt-affected ASUSTOR cases). By RAID level: RAID 5 · RAID 6 · RAID 10. Return to the NAS data recovery hub for the full overview.

Start Your ASUSTOR NAS Recovery

If your ASUSTOR is offline and the data on it matters, the next step is to power it off and start a free evaluation. Before shipping:

• Power the unit off. Continued boot attempts on a unit with a failing drive cohort, an offline storage pool, or a post-DeadBolt state can compound the problem.
• Do not pay the ransom if you’ve been hit by DeadBolt or any other ASUSTOR-targeting ransomware. Decryption after payment is unreliable, and snapshot-based or forensic recovery options are often a better outcome than the gamble of paying.
• Do not run the ADM “Storage Pool Repair” function in an attempt to fix an offline pool. The repair tools work cleanly on healthy arrays and can make failed pools harder to recover.
• Do not run btrfs check, btrfs scrub, or any other filesystem repair tool against drives pulled from a btrfs-configured ASUSTOR unit. These tools can propagate damage on a corrupted filesystem.
• Do not initialize, reset, or rebuild the storage pool from the Storage Manager interface.
• Do not insert replacement drives into a unit that has dropped its array offline.
• Do not run an ADM firmware update in an attempt to fix the problem — especially if you’ve been hit by ransomware. The post-incident emergency updates have broken some configurations as a side effect.
• Do not move the drives to a Synology, QNAP, or other brand of NAS in an attempt to read them. ASUSTOR’s partition layout will not be recognized, and the destination unit will offer to initialize the drives — accepting that prompt destroys the data.
• Label each drive with its bay position before removing it from the chassis. Bay order matters for ASUSTOR RAID reconstruction.
• Note your model number, ADM version, and any ransomware variant (look at the file extensions on the encrypted files and any ransom-note files left behind for ransomware identification). “AS5202T,” “Lockerstor 4,” “Drivestor 4 Pro,” “Flashstor 6” all imply different recovery paths.
• Ship the full set of drives together, in original or equivalent anti-static packaging. We don’t need the ASUSTOR chassis or the power supply for traditional spinning-drive units; for Flashstor units, ship the chassis with NVMe drives still seated.

Open a case or call and you’ll reach our recovery team. The initial scoping call covers feasibility, recovery approach, and turnaround.

Open an ASUSTOR NAS recovery case →

Single-bay ASUSTOR recoveries (where applicable) operate on our standard “no data, no charge” engagement: if the recovery is unsuccessful, you don’t pay for the work. Multi-bay ASUSTOR recoveries (any unit with two or more drives in a redundant configuration) carry an engineering deposit to cover the reconstruction work, with the full price disclosed in the quote before you authorize the recovery. btrfs corruption cases, DeadBolt ransomware recoveries, and Flashstor NVMe recoveries may carry higher engineering deposits reflecting the additional reconstruction work involved — all disclosed in the quote.

Prefer to talk to someone first? Call 1-877-624-7206 during business hours (M–F 8 am–7 pm, Sat 10 am–3 pm Central), or schedule a 15-minute consultation with a client advisor.