ONTAP Disk Commands: Adding, Replacing and Zeroing Disks

Disk operations are the highest-consequence routine work on an ONTAP cluster: a wrong assignment consumes a spare you needed for a rebuild, a failed disk left in place can degrade an aggregate, and a replaced disk that was never zeroed may still hold data. This guide covers the commands that matter for disk lifecycle work — inspection, spare planning, aggregate expansion, replacement and verification — and the order to run them in so that a maintenance task does not turn into a recovery exercise.

Inspection commands you should run before touching anything

cluster1::> storage disk show -fields disk,type,container-type,owner,usable-size,position
cluster1::> storage disk show -broken
cluster1::> storage disk show -container-type spare
cluster1::> storage aggregate show-spare-disks
cluster1::> storage disk option show

The spare check is not optional. NetApp's own guidance is to keep enough compatible spares for an aggregate to survive a failure plus the rebuild, and "compatible" matters: a 960 GB SSD cannot back up a 3.8 TB SAS aggregate. Check the spare list for the aggregate before removing anything.

Adding capacity to an aggregate

# Check what is available
cluster1::> storage aggregate show-spare-disks -original-owner node1

# Add disks by count (recommended, lets ONTAP pick compatible spares)
cluster1::> storage aggregate add-disks -aggregate aggr1 -diskcount 4 -disktype SAS

# Or add specific disks by name
cluster1::> storage aggregate add-disks -aggregate aggr1 -disk 1.0.5 1.0.6

# Verify the result
cluster1::> storage aggregate show -aggregate aggr1 -fields size,available,raidtype
cluster1::> storage aggregate show-status -aggregate aggr1

Two habits make this safe. First, use -diskcount with a disk type rather than naming disks by hand; ONTAP then selects spares that match the aggregate's RAID group requirements. Second, run show-status after the change and confirm the aggregate is online, the expected number of disks is in use, and no reconstruction is in progress.

Replacing a failed or failing disk

# Identify the disk and its physical position for the field engineer
cluster1::> storage disk show -disk 1.0.7 -fields disk,serial-number,position,state,vendor,model

# Fail the disk deliberately (planned replacement of a marginal disk)
cluster1::> storage disk fail -disk 1.0.7

# Remove it from the aggregate, then from the cluster
cluster1::> storage disk remove -disk 1.0.7
cluster1::> storage disk removeowner -disk 1.0.7

# Pull the disk, insert the replacement, then verify it appears as a spare
cluster1::> storage disk show -container-type unassigned

On most ONTAP 9 platforms, a replacement disk is detected automatically and reconstructs the RAID group without manual intervention; the manual path exists for planned swaps and for disks the system has not yet marked as failed. Whether a replacement requires storage aggregate add-disks afterwards depends on the platform and the RAID configuration — on some systems the new disk must be explicitly added back, so always verify with storage aggregate show-status after the swap.

Never remove two disks from the same RAID group at the same time. If a rebuild is in progress, wait for it to finish; the aggregate has no protection margin while reconstruction runs.

Zeroing spares and sanitising disks

# Check which spares still need zeroing
cluster1::> storage disk show -container-type spare -fields disk,zeroing

# Force the background zeroing process to complete now
cluster1::> storage disk zerospares

# Verify
cluster1::> storage disk show -container-type spare -fields disk,zeroing

Zeroing writes zeros over the whole disk so that no residual data can be read if it is later repurposed or returned. ONTAP normally zeroes spares in the background, but the progress can stall when the cluster is busy, and a spare that is not zeroed cannot be used for certain operations. storage disk zerospares is the command to complete it deliberately — run it before a maintenance window in which you expect to consume spares.

If a disk is being retired rather than reused, follow the cluster's data disposal policy: zeroing through ONTAP is appropriate for reuse inside the same environment, while disks leaving the organisation's control usually require a documented secure-erase or destruction step that ONTAP does not perform for you.

Verification checklist after any disk change

1. storage disk show -broken returns nothing unexpected.
2. storage aggregate show-status reports every aggregate online with no reconstruction pending.
3. storage aggregate show-spare-disks confirms the spare count is back to the design minimum.
4. storage aggregate show -fields size,available reflects the expected capacity change.
5. Autosupport has transmitted the event, so NetApp support has a record.
6. The change is recorded in the asset register with disk serial numbers — the next replacement will need them.

Common mistakes and their consequences

Automating the routine parts

# Nightly report to a log, then alert on anything unexpected
cluster1::> storage aggregate show-status
cluster1::> storage disk show -broken
cluster1::> storage aggregate show-spare-disks

These three outputs are enough for a simple script to raise an alert: any aggregate not online, any broken disk, or a spare count below the configured minimum. That turns disk management from a task someone remembers occasionally into a state the cluster reports on continuously — and it means the failure is discovered by monitoring rather than by a user.

Related storage articles

For space accounting at the aggregate level see ONTAP aggregate space usage explained; daily command references live in the ONTAP CLI storage cheatsheet, and space-related errors after efficiency changes are covered in ONTAP dedup aggregate space errors.

原文链接：https://docs.netapp.com/us-en/ontap/disks-aggregates/commands-manage-disks-reference.html