If an Adaptec or Microchip SmartRAID controller has dropped your array offline, refused to import an existing configuration after a controller upgrade, lost all arrays after a migration from a previous Series, or surfaced drives as “Ready” instead of “Foreign” on a new card, you’ve reached the right team. The Adaptec line — now operating under Microchip’s SmartRAID brand — sits in a different part of the market than PERC and Smart Array, with strong penetration in white-box server builds, Supermicro storage platforms, Cisco UCS deployments, and engineering and video workstations. Gillware has operated as a dedicated data recovery laboratory since 2004 from our ISO 5 Class 100 cleanroom in Madison, Wisconsin. Adaptec 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 RAID data recovery hub.

Open an Adaptec recovery case →

How Adaptec / Microchip SmartRAID Controllers Work

Adaptec has changed hands several times. The original Adaptec was acquired by PMC-Sierra in 2010, PMC-Sierra was acquired by Microsemi in 2016, and Microsemi was acquired by Microchip Technology in 2018. Each transition kept the Adaptec brand alive on the controller line itself, but each transition also brought architectural changes that broke backward compatibility with the previous generation in ways that matter for recovery. The current product line ships under the Microchip Adaptec SmartRAID name. The hardware history splits cleanly into three architectural eras that do not interoperate at the array-import level.

Series 5, 6, and 7 (ARC firmware era). The classic Adaptec generations — ASR-5805, ASR-6805, ASR-71605, ASR-72405, and their variants. These cards run the ARC firmware stack (Adaptec RAID Code) and write array metadata in the AMF / CPF format associated with that stack. They were the dominant Adaptec deployment from roughly 2008 through 2015 and are still in production in older builds.

Series 8 transitional (8405, 8805, 8885, 8885Q, 81605Z, 81605ZQ). Released around 2014, the Series 8 cards introduced 12 Gb SAS, a new firmware base, and management tools (maxView Storage Manager) that overlap conceptually with what would later become the SmartRAID line — but Series 8 is its own architecture, and arrays from Series 7 cards cannot be imported on Series 8 hardware. Microchip’s published support guidance is direct: arrays cannot be imported from previous generation Adaptec SAS RAID adapters to Series 8 controllers. RAID 5EE is also not supported on Series 8, so any array using that Adaptec-specific level was effectively stranded at the Series 7 to Series 8 boundary.

SmartRAID 3100 / 3200 series and Tri-Mode SmartRAID (3204-8i, 3254-8i, 3258-16i, 3258-16i/e). The current Microchip generation. SmartRAID 3200-series controllers introduce SAS / SATA / NVMe Tri-Mode operation on the same physical port and use a substantially different on-disk metadata format from both Series 7 and Series 8. Microchip’s published guidance on cross-generation array import is the same on this boundary: “arrays cannot be imported from previous generation Adaptec SAS RAID adapters to the new SmartRAID adapters.” A customer upgrading from a Series 7 71605 to a Series 8 81605ZQ, or from a Series 8 81605ZQ to a SmartRAID 3258, will see the drives recognized by the new controller, listed at the physical-drive level, and reported as Ready instead of Foreign — with no “Scan for Foreign Configuration” or “Import” option available because the new firmware doesn’t understand the previous-generation metadata format at all. The arrays don’t appear “missing”; the new firmware is intentionally ignoring them.

Two further details matter for recovery. First, Adaptec writes its array metadata in a reserved region near the start of each disk rather than at the trailing sectors. This is a significant architectural difference from PERC, ServeRAID, and MegaRAID (which all use SNIA DDF at the end of the disk). It means an Adaptec array is uniquely vulnerable to any tool or operating-system prompt that writes to the first few sectors of a disk — Windows Disk Management’s “Initialize Disk” dialog when an unknown disk is inserted is the most common path to an Adaptec metadata wipe. Second, Adaptec offers a Mode setting per drive called “Expose RAW” that presents physical drives directly to the host outside of any RAID configuration. The Expose RAW state is similar to JBOD but Adaptec-specific in implementation; recovery of arrays that included Expose RAW members has its own metadata-reading requirements.

The administrative surface is arcconf (the CLI) and maxView Storage Manager (the GUI), plus the BIOS option-ROM Adaptec RAID Configuration (ARC) menu reached with Ctrl+A at POST. Events are written to the controller event log accessible from any of those tools. The patterns we see most often are documented below.

Adaptec Error Conditions That Lead to Data Loss

Microchip publishes Adaptec event tables in the maxView and arcconf documentation and a library of customer-facing support articles on cross-generation compatibility. The patterns below are the ones that disproportionately end up at our lab — either because they imply data loss in progress, multiple drive failure beyond the array’s redundancy, or a configuration state where the next attempted action commonly destroys the array.

Cross-generation controller upgrade with no import path. The headline Adaptec failure mode and the most common case we see in 2026. An operating production array on a Series 7 (ASR-71605, ASR-72405) or Series 5/6 (ASR-5805, ASR-6805) controller is migrated to a Series 8 (81605ZQ, 8805, 8885) or SmartRAID 3xxx replacement after a controller failure or refresh. All physical drives are recognized by the new controller and shown in the arcconf physical drive list, but they appear as Ready rather than Foreign, no arrays are listed under Manage Arrays, no logical drives are visible in the OS, and there is no “Import” or “Scan for Foreign Configuration” option anywhere in the BIOS, maxView, or arcconf. Microchip’s documented position is that this is by design. The original arrays have not been destroyed — the metadata is still on the drives — but no Adaptec controller in production today can read it. Recovery proceeds entirely off-controller from imaged drives.

Adaptec metadata wipe by Windows Disk Management or third-party tools. Because Adaptec stores its metadata near the start of the disk rather than the end, any tool that writes to the first few sectors of a member drive destroys the array configuration. The most common path is a drive that the controller has flagged Failed or has otherwise dropped from the array being attached to a Windows workstation for “inspection” — Windows Disk Management prompts to initialize the unknown disk, the operator clicks yes, and the Adaptec metadata header in the reserved leading sectors is overwritten with an MBR or GPT. We see this case routinely. The drive’s payload data is generally intact — Disk Management only writes to the very first sectors — but the array’s record of stripe size, drive order, parity rotation, and member positioning is gone from that drive’s metadata region.

Multiple drive failure beyond fault tolerance. The same condition that takes down PERC and MegaRAID arrays applies on Adaptec, with the added complication that RAID 5EE arrays (Adaptec’s Enhanced Efficient RAID 5 with a distributed hot-spare) are not supported beyond Series 7 and cannot be reconstructed by a Series 8 or SmartRAID controller even if drives were physically intact. Recovery of failed RAID 5EE arrays is fundamentally an off-controller reconstruction job. For standard RAID 5 and RAID 6 with multiple drive failure, the surviving drives are imaged in our cleanroom and the array is rebuilt offline from the images.

Failed rebuild on a Series 5/6/7 controller approaching end-of-life. The ARC-era cards (ASR-5805, ASR-6805, ASR-71605) entered the field between 2008 and 2014. The deployed fleet of those cards is now eleven to seventeen years old and we are seeing controller-side failures at increasing frequency — capacitor failures, NVRAM corruption, BIOS option-ROM hangs, and outright card death during a rebuild. When the controller fails mid-rebuild, the array is left in a partial state that the failed controller can no longer continue and a replacement Series 7 card may or may not pick up. Replacing a Series 7 ARC-era card with a Series 8 or SmartRAID card hits the no-import constraint described above.

Pinned cache and AFM-700 (Adaptec Flash Module) failures. Adaptec’s flash-backup cache module is the AFM-700 / ZMCP, a flash + supercap module that protects write-back cache across power loss on cards that support it — the 8885Q, 81605ZQ, and SmartRAID Q-suffix variants. When the module fails or the supercap loses charge, write-back is disabled and the controller operates in write-through. Cache that was pinned (held against missing virtual disks) at the time the module failed cannot be transferred to a replacement module. As with MegaRAID and Smart Array pinned cache, the pinned writes are lost; whatever was in flight has to be reconstructed from the file system state on the disks themselves.

Patrol Read / Background Consistency Check side effects. Adaptec’s background surface scan (Build / Verify / Verify-with-Fix) is similar in spirit to MegaRAID’s Patrol Read and the Smart Array ARM scan. On a degraded or marginally-failing array, the background scan can flag a surviving drive as Failed based on media errors and drop the array below its fault tolerance. The pattern we see is a degraded array that operated stably until a routine Verify-with-Fix pass found a media error on a second drive and pushed the array offline.

Cross-vendor migration. Drives moved from an Adaptec controller to any non-Adaptec controller will not import. Adaptec’s metadata format is invisible to LSI, HPE, and Dell firmware. The reverse is equally true — drives from any non-Adaptec source will not import on an Adaptec controller. We see this case after attempted hardware refreshes where the operator assumed the array would carry over, sometimes after the destination controller has been given the chance to initialize the drives during the discovery phase.

BIOS option-ROM hangs on aging Series 5/6/7 hardware. An increasingly common symptom on older Adaptec deployments: the system POSTs through to the Adaptec option-ROM banner and stops, with no entry into the ARC menu and no boot to OS. The cause is usually controller-side hardware degradation, sometimes triggered by a marginal drive that the firmware can’t time out cleanly. The array configuration on the drives is intact in most of these cases; the controller itself has failed.

Predictive failure cascades. Adaptec tracks media errors per drive and flags drives with Predictive Failure status when the error rate crosses a threshold. As with PERC, Smart Array, and MegaRAID, the drive flagged is often not the actual source of the underlying problem — errors propagated from a marginal stripe on a neighboring drive end up logged against the drive that performed the read. Drive-replacement cycles that don’t address the underlying media-error condition are a recurring pattern across older Adaptec deployments.

One pattern worth naming separately. The standard OEM support-engineer instruction for several of the conditions above — cross-generation migration that lost the arrays, an Adaptec metadata wipe by Windows Disk Management, a controller failure on aging Series 5/6/7 hardware — tends to be some variant of “create the array fresh and restore from backup.” That instruction is correct when current backups exist. When they do not — which is the situation that brings cases to us — the “create the array fresh” step destroys whatever metadata still exists on the drives, including any metadata our reconstruction process could have read. The real decision in front of a downed Adaptec array is not “vendor support versus recovery shop” — it is “create the array fresh and lose whatever wasn’t backed up” versus “image the drives first and recover before any further controller-side action.” A short call with our engineering team scopes which path applies.

How We Recover Adaptec Arrays

We never operate a failed Adaptec array during recovery. Running a degraded array during diagnostic work risks pushing the next drive over the edge, triggering an unwanted background verify, or letting the controller decide on its own to rebuild against the wrong member. Each drive is removed from the chassis, bay positions and any Adaptec-specific Expose RAW state documented, and imaged on isolated, write-blocked hardware in our cleanroom. SAS and SATA members are imaged through HBAs in IT mode; NVMe members from SmartRAID 3200-series Tri-Mode arrays are imaged through PCIe interposers on dedicated workstations. 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. 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 file-system reconstruction software, built and maintained by the engineers who use it — inspects every single sector of every drive image, identifying Adaptec metadata in the reserved leading-sector region of each disk and file-system forensic artifacts throughout. That sector-by-sector inspection is the key to rebuilding an Adaptec array without the original controller, and it is particularly valuable on the Adaptec side precisely because no Adaptec controller currently in production can read across the Series 7 to Series 8 to SmartRAID boundaries. HOMBRE does not have that constraint.

On Adaptec arrays specifically, HOMBRE parses the AMF/CPF metadata used by the ARC-era cards (Series 5/6/7), the Series 8 metadata format, and the SmartRAID-generation metadata format on equal footing. Stripe size, drive order, parity rotation algorithm, starting LBA offset, and any Expose RAW state are reconstructed from the on-disk records. Where the Adaptec metadata has been wiped from one or more drives — the Windows Disk Management initialization scenario, or any other tool that overwrote the leading sectors — HOMBRE falls back to blind-detection mode: scanning member surfaces for file-system signatures and inferring the stripe parameters from the layout of detected file metadata across the images. This is more engineering-intensive but routinely succeeds where the data itself was never overwritten, only the configuration record. Where pinned cache contents from a failed AFM-700 are relevant, those are read out of cache module dumps and evaluated for staleness against the rest of the array state.

The engineers running this work see the failure modes catalogued above on a weekly basis. There is no Adaptec 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 file-system layer above it — NTFS, ReFS, VMFS, ext4, XFS, ZFS, whatever the array was hosting — is recovered against the assembled volume. The deliverable is a file list and an outcome you can act on, rather than a controller that’s been talked into mounting an array it was never going to recognize.

Related RAID Recovery Pages

By RAID level: RAID 0 · RAID 1 · RAID 5 · RAID 6 · RAID 10 · RAID puncture. By controller brand: Dell PERC · HPE Smart Array · LSI MegaRAID. Return to the RAID data recovery hub for the full overview.

Start Your Adaptec Recovery

If your Adaptec array is offline and production data is on it, power the system down before any other action. Do not initialize any of the drives in Windows Disk Management or any other operating-system disk utility — Adaptec’s leading-sector metadata is uniquely vulnerable to this and the prompt looks innocuous. Do not create a new array on the existing drives in arcconf, maxView, or the ARC BIOS menu, even if support guidance suggests it. Do not accept any rebuild prompt or background-verify prompt at POST. Label each drive with its bay position and any Expose RAW state before removing it from the chassis — that information is part of the array identification. Ship the full set of drives together; we don’t need the server or the controller card.

Open a case or call and you’ll reach our engineering team. The initial scoping call covers feasibility, recovery approach, and turnaround — production-critical Adaptec cases enter the work queue same-day. Recovery is billed on a standard time-and-materials basis.

Open an Adaptec recovery case →

Or skip the form and 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.