Quarterly Capacity Review: Buy Drives or Reclaim Space?

Headroom:

• 480 TiB usable − 452 TiB subscribed = 28 TiB free, i.e. 94 % subscribed.
• Growth of 6 TiB/month consumes that in about 4.6 months.
• Reclaimable: 26 TiB (UNMAP) + 18 TiB (orphan SAP) + 9 TiB (unowned snapshots) = 53 TiB.
• After reclamation: 28 + 53 = 81 TiB of headroom against 72 TiB of twelve-month growth.

So no purchase is required today - but the margin is thin and the forecast is not a promise. Reclaim order, by risk:

1. Unowned SnapVX snapshots (9 TiB). Lowest risk: confirm with the storage owner that the test policy has no consumer, set an expiry, let it elapse, or terminate generations. Non-disruptive to production I/O.
2. Orphan SAP devices (18 TiB). High value but needs sign-off - see the next question for the evidence trail and deletion order.
3. UNMAP (26 TiB). Slowest to realise: it depends on host-side rescan and host behaviour, and it arrives in increments over days or weeks. Start it now because it is the longest lead-time item.

Also note that 94 % subscribed is host-addressable thin capacity and can legally exceed usable; the real constraint is what compression delivers. If the effective ratio slips from 1.5:1 toward 1.2:1, physical consumption rises with no change in subscribed capacity. Raise the PO when projected subscription (after reclamation) passes roughly 85 % or when remaining lead-time buffer drops under 90 days.

Evidence to collect and keep in the change record:

• Topology: symaccess show view MV_SAP to list the initiator group, its WWNs, the port group and SG_SAP.
• Liveness on the array side: no logged-in initiators for those WWNs (symaccess list logins / symcfg list -connections), and zero host I/O counters on the devices over at least 30 days, not just the seven months of 'no login'.
• Fabric side: confirm the zones still exist but show no FLOGI, so you know the absence of login is a decommissioned host rather than a broken path that someone will fix tomorrow.
• Business side: written sign-off from the application owner and the service owner that the SAP system is retired, plus confirmation that no backup catalogue entry references the device WWIDs or LUN map.
• Recovery option: if any doubt remains, take a SnapVX snapshot of the devices and retain it for an agreed period before deletion, so the data can be linked back.

Deletion order (each step is a precondition for the next):

1. Delete masking view MV_SAP (non-disruptive).
2. Remove the 18 devices from SG_SAP.
3. Deallocate/unmap the devices, then delete them. This step is destructive and irreversible - it is the only step that returns capacity to the SRP.
4. Remove the stale zones and the orphan initiator group, and record the reclaimed TiB against the capacity baseline.

Report: current usable, subscribed and effective (post-compression) capacity; subscribed percentage and the 4.6-month runway at current growth; the reclamation pipeline with TiB per item, owner, risk and expected date; the resulting headroom (81 TiB) against the twelve-month forecast (72 TiB); the purchase trigger threshold and six-week lead time; and the cost avoided for this quarter. Be explicit that the runway depends on the reclamation items landing on schedule - if the UNMAP does not realise its 26 TiB, the trigger moves forward by roughly four months.

Governance to prevent recurrence:

• Snapshot policies must have a named owner and a defined expiry; secure snapshots only where compliance requires, and reviewed quarterly.
• A decommission checklist that runs MV → SG → device deletion in order, with evidence retained, so devices never become orphaned in a storage group.
• UNMAP enabled and verified on every host platform in the estate (VMFS6, RHEL, Windows), checked as part of build standards.
• Monthly alerts on SRP subscription thresholds and on storage groups or masking views with no login activity for 60 days.
• Naming and ownership metadata mandated at provisioning time, so the next review can attribute every storage group without archaeology.