HA state assessment checklist · platform-specific recovery procedure required
Example: node B has taken over node A. A takeover can keep data available, but the reason must be understood before giveback.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Establish the state
- Capture node health, HA state, current aggregate ownership, LIF placement, affected applications, EMS timeline and planned maintenance.
- Determine whether the takeover was operator-initiated, automatic due to a fault, or incomplete. Check power, interconnect, storage and network alerts.
cluster show
storage failover show
system health alert show
event log show -severity ERROR02Decide the next action
- If partner hardware is faulted or aggregates are not healthy, escalate and repair before giveback. Do not force a giveback to clear an alert.
- If the cause is resolved, follow the exact platform and ONTAP giveback procedure in an approved window. Monitor client paths and LIFs during the transition.
Partner eligible, underlying fault resolved, and recovery procedure approved.
03Validate recovery
- Check both nodes and HA readiness, aggregate and LIF placement, volumes, SAN paths, application transactions, and new EMS messages.
- Record the initiating event and preventive change.
Both nodes healthy and HA ready; client access and replication normal.
04Timeline worksheet: availability and repair are different milestones
Illustrative case: a power fault triggers takeover and clients continue normally. That demonstrates continued service, but it does not resolve the faulty PSU/feed. A giveback before repair can repeat the incident. In another case, a veto names a specific blocker; bypassing it because the node looks online discards useful protection evidence.
| Time/event | Record | Decision |
|---|---|---|
| Before takeover | Normal owner, paths and current maintenance | What was expected to change? |
| Initiating fault | EMS/console/hardware event | Which component requires repair? |
| Takeover | Partner and aggregate ownership | Did service continue through surviving paths? |
| Partner recovery | Boot/health and fault resolution | Is returning ownership actually safe? |
| Giveback readiness/veto | Exact supported readiness result | Proceed through matching procedure or escalate. |
- Capture current ownership and service state before taking action. Check that the survivor has capacity and paths to sustain the workload during repair.
- Resolve the initiating fault and use the supported readiness procedure for the exact platform and release. Preserve any veto text and involve support when its cause is unclear.
- During a controlled giveback, monitor host/client transactions and paths as well as storage state. Compare the final placement with the intended design.
The repair cause is resolved, both nodes are ready for future HA events, and application service is verified after returning ownership.
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.