Container Pool Saturation and Tape Copy Backlog
A Spectrum Protect server uses a 60 TB directory-container pool as the only primary pool for 300 nodes. It is 92% full. Server-side deduplication averages 3.5:1, and nightly ingestion is about 6 TB logical. Migration is configured to a tape pool at high=90%, low=70%, and the library has 12 LTO-8 drives with 12 TB native per cartridge. The copy pool is built with BACKUP STGPOOL to a second tape pool, and it has not completed for nine days. The tape inventory has 40 scratch volumes. Operations reports that migration jobs start but do not reduce pool occupancy, tape mounts are constant, and two nightly backups failed with insufficient space. The storage team proposes lowering the migration high threshold to 80% and adding 100 TB of disk. Your manager asks whether that will fix the problem or just delay it.
1. Diagnose why migration is not reducing pool occupancy. Support your answer with capacity calculations for the container pool, tape migration, and copy pool.
Read the worked answer
The pool is 92% of 60 TB, about 55 TB physical. At 3.5:1 that represents about 193 TB logical. Migration to tape writes logical data unless the target preserves dedup, and tape does not; so one tape copy is roughly 193 TB, or about 17 LTO-8 cartridges at 12 TB native, before overhead. The copy pool needs a second set, roughly another 193 TB, so a complete migration plus copy cycle consumes about 386 TB. Forty scratch LTO-8 volumes provide 480 TB, so capacity is barely sufficient for one cycle and leaves little for growth, reclamation, or failed mounts. If migration and BACKUP STGPOOL run concurrently or restart, tape mounts stay constant and occupancy can remain flat because new backups add about 6 TB logical, about 1.7 TB physical, per night while migration drains slower. Lowering high from 90 to 80 starts migration earlier but does not add tape throughput or fix the copy backlog; adding 100 TB disk only delays the same wall.
2. Recommend changes to thresholds, schedules, and offsite strategy. State what you would change first and why.
Read the worked answer
I would first stop treating disk as the only fix. Add scratch tapes and confirm tape pool capacity and mount health, then schedule migration in a window with no backup ingest and allow it to finish; run BACKUP STGPOOL after migration, not during peak. Set migration high and low thresholds so there is enough disk headroom for nightly ingest, but do not lower high to 80 without checking whether the tape side can drain faster. For the dedup pool, compare the cost of tape copies, which rehydrate logical data, with node replication to a DR server, which can send only changed extents and keep a dedup-aware target. If the business needs 30 days on disk for restore, add capacity; if not, shorten disk retention and use tape for older versions. Add monitoring for scratch count, copy lag, and migration duration.
3. What would you monitor to prevent recurrence, and what thresholds would you set?
Read the worked answer
Monitor QUERY STGPOOL for percent utilized and migration status, QUERY VOLUME for scratch and full volumes, QUERY PROCESS for long-running migration or copy, and QUERY ACTLOG for mount and media errors. Track logical versus physical capacity, dedup ratio, nightly ingest, migration throughput, and copy-pool lag. Set alerts when the container pool exceeds 85%, scratch falls below a two-week supply, or the copy pool is more than one cycle behind. Use event records and capacity trending, not only a nightly glance. Also review whether the 40-scratch inventory is enough for two copies plus reclamation and growth; if not, add volumes before lowering thresholds.