ONTAP Health Check Cookbook

Most storage incidents leave evidence before users notice an outage. Capacity pressure, degraded RAID, stale replication, displaced LIFs, and expiring certificates can usually be detected with a consistent health-check routine.

This tutorial turns that routine into a guided runbook. Work from top to bottom, use the Copy button on each command block, compare the output with the expected state, and record every exception in your operations log. The commands below are read-only.

Format and save the output

Before running the health check, increase the scrollback or line limit in your SSH client and enable session logging. Save the log with the cluster name and collection date so the complete output is available for comparison, escalation, and audit.

Before you start

Connect to the cluster-management LIF and record the cluster, ONTAP version, date, and ticket number. Check whether maintenance, takeover/giveback, an upgrade, or a replication test is in progress. Keep the previous report open so you can identify changes rather than reviewing isolated values.

rows 0
set -showseparator ","
cluster identity show
version
system node show -fields health,uptime,model

• rows 0 disables pagination so long output is captured without prompts or interrupted pages.
• set -showseparator "," separates displayed fields with commas. This makes tabular output easier to save as CSV and import into Excel after removing CLI prompts and unrelated log lines.
• cluster identity show records the cluster name and UUID, preventing reports from being attached to the wrong environment.
• version captures the running ONTAP release so command fields and findings can be interpreted against the correct version.
• system node show provides each node's health, uptime, and model. Unexpected uptime may reveal a recent reboot, takeover, or maintenance event.

These CLI display preferences apply only to the current session. Save the relevant output with a .csv extension when you plan to filter, compare, or report it in Excel.

Checkpoint: confirm that the cluster, node count, models, and uptime match the inventory.

1. Cluster health

cluster show
cluster ha show
system health status show
system health subsystem show
system health alert show

Expected: all nodes are healthy and eligible, HA matches the design, overall health is OK, and there are no unexplained alerts.

For any alert, collect its cause, impact, and recommended action:

system health alert show -instance

Treat new critical or major alerts as same-day escalations. Do not suppress or delete an alert simply to clear the dashboard.

2. Capacity and availability

storage aggregate show -fields size,usedsize,availsize,percent-used,state,raidstatus
storage aggregate show -state !online
volume show -fields size,available,percent-used,state,percent-snapshot-space
volume show -state !online

Expected: aggregates and production volumes are online, RAID status is normal, and free space covers forecast growth plus the time required to add or move capacity.

• 70–80%: forecast exhaustion and plan capacity work.
• 85–90%: assign an owner and near-term remediation.
• 95% or more: treat it as an incident.

Always combine utilization with growth rate. A 75% aggregate growing 5% each week may be more urgent than a stable aggregate at 88%.

3. Disks, RAID, and shelves

storage disk show -broken
storage disk error show
storage aggregate show -fields state,raidstatus
storage shelf show -connectivity

Expected: no broken disks or unexplained errors, aggregates online with normal RAID status, and redundant shelf connectivity.

If RAID is degraded, record the affected aggregate, reconstruction status, spare availability, and remaining redundancy. Follow the approved platform procedure; do not fail or remove disks from this checklist.

4. Snapshots and replication

volume snapshot show -fields size,create-time
volume snapshot policy show
volume show -fields percent-used,percent-snapshot-space
volume show -snapshot-policy none
volume snapshot autodelete show -enabled true
snapmirror show -fields source-path,destination-path,state,status,healthy,lag-time,unhealthy-reason
snapmirror show -healthy false

Expected: snapshots follow policy without consuming unexpected space, and every protected relationship is healthy and within the application's RPO.

Do not assume healthy=true means the RPO is met. Compare lag-time with the business requirement. For an exception, capture source, destination, lag, last transfer result, unhealthy reason, and application owner. Confirm snapshot ownership and retention requirements before deleting anything. Also ensure that snapshot autodelete is disabled because, during a ransomware attack, snapshots could be deleted once the volume reaches the autodelete threshold. Review whether any volumes have no snapshot policy assigned.

5. Ports and LIFs

network port show -fields link,health-status
network interface show -fields status-admin,status-oper,is-home,home-node,home-port,curr-node,curr-port
network interface show -is-home false
network interface show -failover

Expected: required ports are healthy, client LIFs are operational, and every non-home LIF is explained by design or active maintenance.

A non-home LIF is not automatically a fault. Validate its current port, failover targets, maintenance status, and client impact. Do not revert a LIF from a generic checklist.

6. Performance baseline

qos statistics workload latency show
statistics show-periodic -object volume -counter total_ops,avg_latency
system node run -node <node> -command "sysstat -c 10 1"

Expected: latency, operations, and CPU remain within the normal range for the same workload window.

One latency value without workload context is weak evidence. Compare IOPS, latency, and CPU with the established baseline. Use this step to detect deviations; perform a dedicated investigation before changing performance settings.

7. Firmware version collection

version
system service-processor show -fields type,status,fw-version
storage disk show -fields model,serial-number,firmware-revision
storage shelf show -module
network fcp adapter show -instance

Expected: ONTAP, SP/BMC, disk, shelf module, and FC adapter firmware match the versions approved for the platform. Record each disk's model (part number), serial number, and firmware revision, and record exceptions by node, adapter, shelf, or disk model; do not start firmware updates from this health check.

8. SAN Health Check

network interface show -data-protocol iscsi
iscsi initiator show -fields igroup,initiator-name,tpgroup
vserver iscsi session show
vserver iscsi connection show
network interface show -data-protocol fcp
fcp initiator show -fields igroup,wwpn,lif
lun mapping show -fields node,reporting-nodes,igroup,protocol

Expected: compare the number of logged-in iSCSI and FC initiators with the approved host inventory. iSCSI initiators should use the intended target portal groups, FC initiators should be logged in through the expected LIFs and fabrics, and LUN reporting nodes should match the owning node and HA partner design. Confirm on each host that MPIO is enabled, ALUA is recognized, all expected paths are active, and paths cross independent initiators, switches or VLANs, target LIFs, and both controllers. ONTAP shows target-side connectivity; only the host can confirm the multipath policy and software and end-to-end path state.

9. Supportability

system node autosupport show -node *
system node autosupport check show
system license show
cluster time-service ntp server show
security certificate show -fields expiration -expiration <60d

Expected: AutoSupport is operational, required licenses are valid, NTP is configured, and certificates have enough remaining lifetime for the renewal process.

Record the earliest certificate expiration. Missing telemetry, clock drift, or an expiring certificate may not cause an outage today, but each can complicate the next incident or maintenance window.

Close the health check

For every exception, record the affected object, finding, business impact, owner, ticket, and target date. Classify active unavailability, near-full aggregates, lost redundancy, and protection outside the committed RPO as critical. Track trends and supportability risks according to their time to impact.

Copy-ready cadence

Daily

system health alert show
storage disk show -broken
storage aggregate show -state !online
volume show -state !online
snapmirror show -healthy false
network interface show -is-home false
volume show -snapshot-policy none
volume snapshot autodelete show -enabled true

Weekly

storage aggregate show -fields availsize,percent-used-capacity,state,raidstatus
volume show -fields available,percent-used,state,percent-snapshot-space
storage disk error show
storage shelf show -connectivity
snapmirror show -fields state,status,healthy,lag-time,unhealthy-reason
network port show -fields link,health-status
system node autosupport check show

Monthly

system node show -fields health,uptime,model
system service-processor show -fields type,status,fw-version
storage disk show -fields model,serial-number,firmware-revision
storage shelf show -module
network fcp adapter show
fcp initiator show -fields igroup,wwpn,lif
iscsi initiator show -fields igroup,initiator-name,tpgroup
vserver iscsi connection show
lun mapping show -fields node,reporting-nodes,igroup,protocol
system license show
cluster time-service ntp server show
security certificate show -fields expiration -expiration <60d
qos statistics workload latency show

Version and safety note

Fields and privileges can differ by ONTAP release, platform, and cluster context. Validate this routine against the current ONTAP command reference and local procedures. This tutorial stops at detection and evidence collection; use an approved runbook for remediation.

Quais comandos você adicionaria a essa rotina? Compartilhe seus scripts nos comentários abaixo!