NetApp MetroCluster Data Recovery
MetroCluster is NetApp's synchronous, site-level high-availability architecture built on top of ONTAP, mirroring aggregates between two sites so that a full site failure can be handled with a switchover rather than a restore. Because MetroCluster adds mirroring, bridging and quorum layers on top of ordinary WAFL and RAID, recovery cases here more often involve a mishandled switchover, a broken mirror relationship or a split-brain event than a simple drive failure.
Platform Lineage and Naming
MetroCluster has existed in ONTAP as a stretch or fabric-attached configuration using Fibre Channel back-end connectivity (MetroCluster FC), later joined by MetroCluster IP, which replaces FibreBridge and dedicated FC switches with routable IP connections between sites, simplifying cabling for longer distances. NetApp has also positioned SnapMirror active sync as a software-defined alternative that provides synchronous, near-MetroCluster protection between ONTAP clusters without the dedicated mirrored-aggregate architecture, sometimes referred to in the context of MetroCluster SDS discussions.
The core mechanism across MetroCluster FC and IP is SyncMirror, which maintains two plexes of each mirrored aggregate — one at each site — so that every write is committed to both locations before being acknowledged. This is distinct from SnapMirror, which is asynchronous or semi-synchronous replication between separate aggregates rather than a mirrored pair of plexes within one aggregate.
- MetroCluster FC — Fibre Channel back-end configuration, historically using ATTO FibreBridge to attach SAS shelves
- MetroCluster IP — IP-based back-end configuration without FibreBridge or dedicated FC switches
- SyncMirror — the underlying synchronous mirroring technology creating plex pairs
- Plex — one mirrored copy of an aggregate; a mirrored aggregate normally has two, one per site
- Tiebreaker / Mediator — the third-site or cloud-hosted quorum service used to arbitrate switchover decisions
- Switchover / switchback — the controlled or forced transfer of service between sites and its reversal
- SnapMirror active sync — a software-defined synchronous replication approach sometimes discussed alongside MetroCluster SDS
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| MetroCluster FC | Fabric-attached and stretch configurations using ATTO FibreBridge to connect SAS shelves over Fibre Channel |
| MetroCluster IP | IP-based back-end replacing FibreBridge, used on supported AFF and FAS platforms |
| Quorum services | Tiebreaker software or ONTAP Mediator, typically hosted at a third site or in the cloud |
Architecture and Data Layout
A MetroCluster configuration pairs two ONTAP clusters, one per site, each holding a plex of every mirrored aggregate. SyncMirror keeps both plexes consistent by writing to both sites before acknowledging the host, while the ONTAP RAID and WAFL layers beneath each plex behave as on any other AFF or FAS system.
MetroCluster FC historically relied on ATTO FibreBridge units to present SAS shelves over Fibre Channel to the remote site's controllers; MetroCluster IP removes that bridging layer in favour of direct IP connectivity between the storage and network fabrics at each site.
A tiebreaker or mediator service observes both clusters and helps decide whether an automatic or operator-initiated switchover is safe, aiming to avoid a scenario where both sites believe they should serve data independently. Switchover moves service to the surviving site; switchback later restores normal operation once the original site and its plex are resynchronised.
Not every aggregate in a MetroCluster configuration is necessarily mirrored — unmirrored aggregates can exist for data that does not need cross-site protection, and they do not benefit from SyncMirror or automatic switchover, which materially changes what is recoverable after a site event.
Protocols and formats: NFS, SMB/CIFS, iSCSI, Fibre Channel, SyncMirror, SnapMirror, SnapMirror active sync
- Mirrored aggregates hold two plexes of the same WAFL structures, one per site, kept synchronous by SyncMirror rather than being independent copies reconciled after the fact.
- RAID protection (RAID-DP or RAID-TEC) applies within each plex, so a plex can itself tolerate some drive loss independently of the cross-site mirror.
- Unmirrored aggregates sit outside the SyncMirror relationship entirely and rely on their own local RAID protection only.
Failure Scenarios
Logical failures
- Split-brain following communication loss between sites with tiebreaker/mediator unavailable or misconfigured
- Forced switchover performed without full confidence in surviving-plex consistency, followed by data written that later conflicts with the impaired site
- Failed or incomplete switchback leaving plexes out of sync
- SyncMirror relationship broken and not properly re-established, followed by independent writes at both sites
- Aggregate or volume deleted at one site before replication state was reconciled
- Mediator/tiebreaker configuration errors leading to an unintended automatic switchover
Hardware failures
- ATTO FibreBridge failure isolating SAS shelves from the remote site on MetroCluster FC
- Loss of inter-site FC or IP links exceeding the resilience of the configured fabric
- Multiple drive failures within a single plex exceeding local RAID tolerance
- Controller failure at one site combined with a degraded plex at the other
- Simultaneous power or network events affecting both sites at once
Encryption and credentials
MetroCluster supports NetApp Storage Encryption and Volume Encryption across both sites; key manager state must be consistent and available at whichever site is used for evaluation, since a plex cannot be interpreted without the corresponding keys.
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
What is the difference between a forced switchover and normal switchover?
A normal switchover happens with both sites healthy and communicating, so ONTAP can confirm the surviving plex is current. A forced switchover is used when the healthy site cannot confirm this, which carries a higher risk of losing writes that had not yet been mirrored — this is the scenario most likely to need a recovery evaluation.
What causes split-brain in MetroCluster?
It typically follows a communication failure between sites combined with an unavailable or misconfigured tiebreaker/mediator, after which both sites may independently believe they should be serving data — risking divergent writes to what should be a single mirrored aggregate.
Are unmirrored aggregates protected by MetroCluster switchover?
No. Unmirrored aggregates are outside the SyncMirror relationship and do not automatically switch over, so their protection depends solely on local RAID and any separate replication configured for them.
Is MetroCluster IP recovery different from MetroCluster FC?
The underlying WAFL and SyncMirror concepts are the same; the practical difference is that MetroCluster FC cases may involve ATTO FibreBridge state, while MetroCluster IP cases centre on the IP fabric and switch configuration instead.