Top 20 ONTAP mistakes—and how to avoid them

1. Treating Snapshot reserve as “handled”

Symptom: volume full despite modest active data. Why: retained snapshots consume reserve and can spill into filesystem space. Fix: size from measured change/retention and alert on both.

cluster::> volume show -vserver svm1 -volume vol1 -fields size,available,percent-used,snapshot-reserve
svm1 vol1 10TB 420GB 95% 5%

2. Misreading fractional reserve

Symptom: overwrite or LUN write fails in a thin volume. Why: fractional reserve and space guarantee do not create physical capacity. Fix: inspect guarantees, reserve, overwrite reserve, and aggregate headroom together.

cluster::> volume show -volume san01 -fields space-guarantee,fractional-reserve,available
volume space-guarantee fractional-reserve available
san01  none            0%                 96GB

5. Oversubscribing aggregates without telemetry

Symptom: several thin volumes approach full at once. Why: logical promises share one physical pool. Fix: trend aggregate committed, used, available, growth and Snapshot/clone liabilities; set response thresholds.

6. Deleting the wrong snapshot

Symptom: a recovery point disappears or dependent clone blocks deletion. Why: names, policies, dependencies and retained blocks were not reviewed. Fix: show the snapshot first; use autodelete policy only after setting trigger, target and order deliberately.

cluster::> volume snapshot show -vserver svm1 -volume vol1
cluster::> volume snapshot autodelete show -vserver svm1 -volume vol1
# Destructive: use exact snapshot only after approval
cluster::> volume snapshot delete -vserver svm1 -volume vol1 -snapshot hourly.2026-08-20_1200

7. Leaving autosize off

Symptom: a volume hits its ceiling while aggregate space remains. Why: no growth policy exists. Fix: configure a bounded maximum and thresholds; autosize is a buffer, not capacity planning.

cluster::> volume autosize -vserver svm1 -volume vol1 -mode grow -maximum-size 12TB -grow-threshold-percent 85
cluster::> volume autosize -vserver svm1 -volume vol1
Mode  Maximum Size Grow Threshold
grow  12TB         85%

8. Throttling production with forgotten QoS

Symptom: latency rises at a repeatable IOPS/MBps ceiling. Why: a fixed policy survived a migration or resize. Fix: inspect assignment and QoS latency; choose fixed or adaptive QoS from the service objective.

9. Compressing already-compressed data

Symptom: little saving and harder performance attribution. Why: encrypted/compressed payloads have low redundancy. Fix: measure efficiency by workload and disable features that do not earn their operational cost; see storage efficiency.

19. Thin-provisioning LUNs past physical reality

Symptom: one bursty host consumes shared headroom and other LUNs fail writes. Why: logical sizes were summed without correlated growth. Fix: monitor host filesystem, LUN, volume and aggregate as one capacity chain; preserve emergency headroom.

3. Soft-mounting database NFS

Symptom: application I/O errors during a transient network/storage delay. Why: a soft mount gives up and returns an error. Fix: use a hard mount with application/vendor-validated settings; see databases on ONTAP and the NFS guide.

4. No usable LIF failover policy/group

Symptom: NAS IP becomes unreachable after port/node failover. Why: no eligible target exists or broadcast domains are wrong. Fix: prove home/current ports, policy, group and targets, then test.

cluster::> network interface show -fields home-node,home-port,curr-node,curr-port,failover-policy,failover-group
cluster::> network interface failover-groups show
cluster::> network interface failover-groups show-targets -vserver svm1 -lif nfs01

15. Wrong DNS on an SVM

Symptom: peer names, AD, LDAP, Kerberos or remote endpoints fail inconsistently. Why: SVM DNS scope, routes, search domains or records differ from cluster management. Fix: test from the correct SVM and correct its DNS/name-service configuration.

cluster::> vserver services name-service dns show -vserver svm1
cluster::> network ping -vserver svm1 -destination dr-peer.example.com
dr-peer.example.com is alive

16. Blocking required management/replication ports

Symptom: System Manager, SSH, REST, AutoSupport, peering, or SnapMirror times out. Why: the firewall model omitted direction, LIF role, or release-specific services. Fix: allow only required endpoints/ports and verify end-to-end; check the current ONTAP port reference and hardening guide.

10. Letting SnapMirror lag grow silently

Symptom: the recovery point is hours older than policy. Why: no lag/error alert, insufficient bandwidth, overlapping transfers, or policy-label mismatch. Fix: alert on state, status, lag and last transfer—not job success alone.

cluster::> snapmirror show -fields state,status,lag-time,last-transfer-end-timestamp,healthy
destination-path state status lag-time last-transfer-end-timestamp healthy
dr:vol1_dp Snapmirrored Idle 03:42:11 8/27/2026 10:15:02 false

18. Keeping every audit/config copy on-box

Symptom: a cluster compromise or site loss removes evidence and recovery configuration together. Why: export and retention were never assigned. Fix: send logs to an off-box controlled destination and regularly create/download configuration backups; see audit logging.

20. Never testing DR

Symptom: first failover reveals stale DNS, missing secrets, wrong host paths, or an unusable runbook. Why: replication health was mistaken for recoverability. Fix: schedule isolated rehearsals, time every dependency, document evidence and remediate; use the DR comparison and runbooks.

11. Weak SMB authentication or signing posture

Symptom: downgrade exposure or clients negotiate obsolete authentication. Why: compatibility exceptions became permanent. Fix: require supported SMB signing where policy calls for it, disable NTLMv1, prefer Kerberos/NTLMv2, test clients, and follow the SMB guide and security guidance.

12. Losing NVE/NAE key backups

Symptom: encrypted volumes cannot be unlocked after key-manager loss or disaster. Why: key custody was treated as storage configuration. Fix: use supported onboard/external key management, verify connectivity and securely back up key-manager information outside the cluster. Recovery details vary—check your version and contact support before risky changes.

cluster::> security key-manager show
Node  Key Manager Type Status
node1 external         available
node2 external         available
cluster::> security key-manager key query

13. Ignoring degraded storage failover

Symptom: the next controller event becomes an outage. Why: takeover capability or partner state was never made actionable. Fix: alert on degraded/disabled state and clear the cause before maintenance.

cluster::> storage failover show
                              Takeover
Node   Partner Possible State Description
node1  node2   false    Connected to node2, Takeover is not possible: reason...
node2  node1   false    Connected to node1, Takeover is not possible: reason...

14. Upgrading without release-specific planning

Symptom: validation finds incompatible firmware, host software, or removed behavior late. Why: “rolling” was mistaken for “risk-free.” Fix: use Upgrade Advisor/Active IQ, release notes, image validation, the interoperability matrix and the ONTAP upgrade runbook.

17. Using cluster-admin for everything

Symptom: automation and routine operators can change the entire cluster; audit attribution is poor. Why: convenience replaced role design. Fix: create named users and least-privilege RBAC roles, reserve emergency administration, and review the security audit log.

cluster::> security login show -fields user-or-group-name,application,authentication-method,role
vserver user-or-group-name application authentication-method role
cluster backup-bot        http        cert                  backup-api
cluster admin             ssh         password              admin