SnapVX Capacity Pressure from a Long-Lived Linked Target
An 8 TB storage group SG_ORACLE_PROD is protected by a SnapVX policy that runs every 4 hours and retains 7 days (42 snapshots). The array's 40 TB SRP is at 86% used; snapshot space is 32 TB and rising. A target storage group SG_ORACLE_TEST has been linked to the snapshot from 02:00 yesterday for a test refresh; the link is still active and the test owner says they need 'a few more days'. Host writes to the source average 180 MB/s with peaks of 400 MB/s. Unisphere shows the linked target's track delta is 1.8 TB and growing. The next policy snapshot is due in 40 minutes. You have an alert that SRP free capacity is below 15%. The business cannot lose the ability to restore the source to any of the last three days. Change approval for policy changes takes 24 hours.
1. Which objects are consuming SRP capacity, and why is the linked target more urgent than the 42 snapshots?
Read the worked answer
The SRP is consuming capacity from three visible sources: allocated thin volume data, SnapVX snapshot data, and the linked target's delta. The linked target is urgent because a link keeps source tracks that have changed since the snapshot, so the source's ongoing 180-400 MB/s writes continue to consume SRP capacity to preserve the target image. The 1.8 TB track delta and its growth rate are a live multiplier; the next policy snapshot in 40 minutes will create another recovery point and may add metadata and changed-track pressure.
The 42 snapshots are also consuming space, but they are bounded by the policy. The link is unbounded because the test owner keeps extending it. Do not delete all old snapshots first: that would destroy the three-day restore capability the business requires. Identify the top consumers with Unisphere SRP snapshot capacity views and symsnapvx list -sg SG_ORACLE_PROD -detail, then target the linked target and snapshots older than three days.
2. What immediate actions would you take in the next 40 minutes, and how do you respect the 24-hour change process?
Read the worked answer
Treat this as a capacity-exhaustion emergency, because an SRP that fills can affect new writes and snapshot creation. Notify the change board and test owner in writing that the link must be stopped or the SRP is at risk.
Order of action:
- Confirm the top consumers and capture current SRP free capacity.
- Ask the test owner to confirm the test is complete or can be paused. If yes, unlink or terminate the SG_ORACLE_TEST link from the snapshot. Terminating the link should release the source's obligation to retain those changed tracks, but confirm the target is no longer needed first.
- If the owner refuses, escalate for an emergency change. Do not wait for the normal 24-hour approval while free capacity continues to fall.
- Before the next policy snapshot, consider suspending the policy only if the link cannot be stopped and capacity is critical; document that this widens RPO.
- Preserve at least one snapshot per day for the last three days. Delete only snapshots older than the three-day requirement, and only after confirming they are not linked to any target.
Do not delete the most recent snapshots or the link blindly; the goal is to remove the largest unbounded consumer while preserving the required recovery points.
3. What permanent policy and monitoring changes prevent recurrence?
Read the worked answer
Align the snapshot policy with the actual business requirement: if only three days of restore points are required, reduce retention from 7 days to 3 days through the normal change process. Keep the 4-hour interval only if the RPO justifies it; otherwise a longer interval reduces snapshot count and changed-track overhead.
Add controls around test links:
- Require a defined time-to-live for any linked target and track it in the change system.
- Put test refreshes in a separate SRP or array if possible so test links cannot consume production snapshot headroom.
- Use Unisphere and CloudIQ alerts at 70% and 80% SRP used, not only below 15% free.
- Review snapshot and link capacity weekly, and include linked-target delta in capacity reporting.
- Document an emergency procedure for unlinking a target when the owner is unavailable.