NetApp ASA and AFX Data Recovery
NetApp's ASA (All-SAN Array) and AFX platforms both run on ONTAP but reorganise it around block storage and, in AFX's case, around a disaggregated architecture that separates compute from shared storage. Recovery work on either family starts by establishing which generation is in play, since the underlying WAFL and RAID mechanics are shared with AFF and FAS but the controller model, failover behaviour and multipathing differ.
Platform Lineage and Naming
NetApp introduced the first ASA A-series as an all-SAN variant of AFF, running standard ONTAP but exposing only block protocols and enforcing symmetric active/active paths to both controllers rather than the asymmetric ALUA behaviour of general-purpose AFF/FAS. The current ASA A-series and ASA C-series continue this approach on NVMe flash, with the C-series aimed at capacity-optimised QLC deployments.
AFX is a newer and structurally different platform: it disaggregates ONTAP compute nodes from a shared pool of NVMe storage nodes connected over a dedicated back-end fabric, rather than pairing two controllers directly to their own shelves. This lets compute and capacity scale independently, but it also means a recovery engagement may need to account for the state of multiple compute nodes and the storage-node pool separately.
Both platforms remain part of the ONTAP family lineage that includes FAS and AFF, and both are managed through the same System Manager and ONTAP command set that administrators of those platforms will recognise.
- ASA — All-SAN Array, NetApp's block-only ONTAP configuration
- ASA A-series — original all-SAN controllers derived from AFF A-series hardware
- ASA C-series — capacity-flash all-SAN controllers
- AFX — NetApp's disaggregated ONTAP architecture with separate compute and storage nodes
- SAN-optimised ONTAP / symmetric active-active — the ASA personality distinguishing it from general-purpose ONTAP
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| ASA A-series | ASA A150, A250, A400, A800, A900 and successors, block-only ONTAP personality on AFF-derived controllers |
| ASA C-series | ASA C250, C400, C800 and similar capacity-flash (QLC) all-SAN configurations |
| AFX | AFX compute nodes paired with shared NVMe storage-node shelves over a dedicated back-end fabric |
Architecture and Data Layout
ASA systems run ONTAP with a SAN-only personality: no NAS protocols are exposed, and both controllers present every LUN as active-active over symmetric paths, which changes multipathing behaviour compared with a general-purpose AFF cluster but does not change how WAFL lays out data underneath. For the WAFL, aggregate and Snapshot mechanics common to both platforms, see the AFF and ONTAP/WAFL pages rather than this one.
AFX separates the compute layer — the nodes running ONTAP itself — from a shared pool of NVMe storage nodes accessed over a dedicated fabric, rather than each controller owning its own directly attached shelves. This means aggregates and volumes can, in principle, be served by different compute nodes over time, and a recovery evaluation needs the storage-node pool state alongside the compute-node configuration to reconstruct WAFL structures correctly.
Both platforms use ONTAP RAID (RAID-DP or RAID-TEC) beneath their aggregates, and both support ONTAP-level replication such as SnapMirror, so replicated copies at a second site are frequently a first line of recovery to check before deeper media-level work is considered.
Protocols and formats: iSCSI, Fibre Channel, FC-NVMe, NVMe/TCP, VMFS, vVols, SnapMirror
- Underlying data layout follows WAFL and ONTAP RAID (RAID-DP, RAID-TEC) as on AFF and FAS — see the ONTAP/WAFL page for those mechanics in depth.
- AFX's separation of compute and storage nodes means the physical location of aggregate members must be established from the storage-node pool rather than assumed from a single controller's configuration.
Failure Scenarios
Logical failures
- Deleted LUNs or volumes with Snapshot copies expired or removed
- Failed ONTAP or firmware upgrade on a controller or compute node
- Aggregate or volume corruption following a failed migration between nodes
- SnapMirror relationship broken or resynchronised in the wrong direction
- Accidental LUN unmap or volume offline/destroy during provisioning changes
- Multipathing misconfiguration masking a healthy LUN from a host
Hardware failures
- Multiple drive failures exceeding RAID-DP/RAID-TEC tolerance within an aggregate
- Dual controller or compute-node failure
- Back-end fabric failure isolating AFX storage nodes from compute nodes
- NVRAM/NVMEM failure with unflushed writes
- Shelf or storage-node enclosure failure
Encryption and credentials
Both ASA and AFX support NetApp Storage Encryption and NetApp Volume Encryption with onboard or external key management. Key manager configuration and any external KMIP server state should be preserved alongside the array for an evaluation.
What Not To Do Before an Evaluation
- Do not run rebuilds, reconstructions or re-initialisations against an array that has already lost more drives than its protection level allows.
- Do not recreate pools, aggregates, disk groups, storage pools or clusters — these operations write new metadata over the structures a recovery needs.
- Do not swap drives between slots, and do not reorder shelves. Record the original slot and shelf positions before removing anything.
- Do not run file-system repair tools against production volumes before the underlying storage layer has been evaluated.
- Do not restore a backup or replication set over the affected volumes until the recovery scope has been assessed.
- Do not eradicate deleted volumes or empty recycle/destroyed states on platforms that hold deleted data for a retention window.
Our Evaluation and Recovery Process
- Intake and platform identification — array model, generation, firmware, protection layout and the sequence of events that led to the failure.
- Read-only evaluation of the media and array structures, including assessment of drive health and the extent of any physical damage.
- Forensic imaging of all contributing media, with cleanroom work where drives require it. Originals are preserved unaltered.
- Reconstruction of the storage layer — pools, aggregates, parity groups, chunklets, extent groups or objects — from the images.
- Extraction of the layers above: file systems, virtual machines, databases, mailboxes and shares.
- Verification against a file list and customer-nominated critical data, followed by secure return on encrypted media.
Frequently Asked Questions
Is ASA a different file system from AFF?
No. ASA runs standard ONTAP with WAFL underneath; the difference is a SAN-only personality and symmetric active-active path presentation, not a different on-disk format.
What makes AFX different to recover from than AFF?
AFX separates compute nodes from a shared NVMe storage-node pool, so an evaluation needs visibility into that storage-node pool as well as the compute-node configuration, rather than treating a single controller as the whole system.
Can SnapMirror replicas help before deeper recovery work?
Often yes — where SnapMirror is configured to another ASA, AFX, AFF or FAS system, checking the replica's integrity is a sensible first step before considering source-side recovery.