Space reclamation on sequential volumes comes into play when files are expired or deleted from the volume (say the client says delete all backups for example). When the percentage of reclaimable space on the volume hits the threshold defined for the storage pool, the volume then becomes eligible to be reclaimed. I think the server does a check every hour or so to see which volumes are ready to be processed. (This can have an adverse affect with performance or tie up resources needed for other tasks, so I find it best to control when reclamation runs via tsm scripts). When the reclamation runs, the server copies files that remain on the volumes being reclaimed to other volumes in the same storage pool. Once the volume being reclaimed is empty, it should be returned to scratch volume based on the reusedelay setting. Reclimation can run for both primary and copy volumes. There are various recommendations to be found for different types of storage devices, and even a workaround for if you only have one tape drive, and need to free up tapes.
Very simplistically: TSM is only able to tolerate the loss of the disk storage if you have a copy storage pool in which to repair the primary storage pool. You would then use that copy to restore the primary or fix any damaged extents. There's other options such as replication to another server as well.
A really simple layout of primary and copy would look something like this for the legacy storage pool (file for example):
- Client backups to to STGP_A at 10pm
- At 1am STGP_A runs a backup stgpool command to TAPE_COPY_A
Client now has data protected on disk (primary) and tape (copy).
I always recommend that you should have a copy, and not on the same device as the primary storage!. See this link here for types of storage pools:
https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.9/srv.solutions/c_stg_pools.html
Generally you do not want to destroy volumes unless absolutely needed. If a volume is unavailable, that is generally a bad thing as well. Both cases unless there's a copy (from primary storage or copy storage) you could suffer data loss and/or not meet retention requirements.
Something not addressed above is database backup volumes. Those are not processed via reclamation. I find it best to address those manually via internal tsm scripts that delete the oldest database backup to free up space/tapes for the next one.
Hope the above helps.