When you define or update a sequential access storage pool, you can use the REUSEDELAY parameter. This parameter specifies the number of days that must elapse before a volume can be reused or returned to scratch status after all files are expired, deleted, or moved from the volume.
When you delay reuse of such volumes and they no longer contain any files, they enter the pending state. Volumes remain in the pending state for the time that is specified with the REUSEDELAY parameter for the storage pool to which the volume belongs.
Delaying reuse of volumes can be helpful under certain conditions for disaster recovery. When files are expired, deleted, or moved from a volume, they are not erased from the volumes: The database references to these files are removed. Thus the file data might still exist on sequential volumes if the volumes are not immediately reused.
A disaster might force you to restore the database by using a database backup that is not the most recent backup. In this case, some files might not be recoverable because the server cannot find them on current volumes. However, the files might exist on volumes that are in pending state.
You might be able to use the volumes in pending state to recover data by doing the following steps:
If you back up your primary storage pools, set the REUSEDELAY parameter for the primary storage pools to 0 to efficiently reuse primary scratch volumes. For your copy storage pools and active-data pools, delay the reuse of volumes while you keep your oldest database backup.