Tivoli Storage Manager server versus Protectier occupancy

Resolving The Problem

It is expected to have a different in occupancy between Tivoli Storage Manager and the VTL. Examine the total of physical_mb and logical_mb from the select command output. The difference between physical_mb and logical_mb represents data that is expired in aggregates. Depending on the aggregate size and depending on the estimated capacity of the VTL volume, this difference may vary.

For example, assuming a the VTL storage pool uses a device class with an estimated capacity of 100GB. A full volume in Tivoli Storage Manager will report an occupancy at 100 GB. The same volume in the VTL will also report an occupancy of 100GB. As data expires on the volume, the occupancy may report less and less data stored on the volume, say 40GB for example. The VTL will continue to report the occupancy for this volume as 100GB.

Once a VTL volume is reclaimed and the volume returns to scratch, it is then relabeled assuming the library is configured with the "RELABELSCRatch=YES" parameter. Once the volume is relabeled, the VTL volume space is released in the VTL.

So, expired data that has not been reclaimed on VTL volumes contributes to the data occupancy difference. Other factors that contribute to this occupancy discrepancy are listed below

• Number of PENDING volumes
  A pending volume is a volume for which all files have been deleted, but for which the time specified by the storage pool REUSEDELAY parameter has not elapsed. A pending volume will show zero (0) occupancy in Tivoli Storage Manager but will still occupy the FULL amount of the volume size in the VTL.
  Run the following commands to verify the number of PENDING volumes :
  
select count(*) from volumes where status='PENDING' and stgpool_name='XXX'
query vol status=pending stg=XXX

  Replace XXX with the storage pool name that uses the Protectier storage.
  Use the following command to verify the estimated capacity of the volume :
  
query devclass <devclass_name> f=d

  Replace "<devclass_name>" with the device class name configured with the storage pool that uses the VTL. Examine the "Est/Max Capacity (MB)" value. Multiply this value by the number of pending volumes to obtain the total amount of pending data that still occupies space in the VTL but does not occupy space in Tivoli Storage Manager.
  Use the following command to verify the reusedelay parameter of the storage pool :
  
q stg <stgpool_name> f=d

  The reusedelay parameter represents the number of days that must elapsed before a pending volume is scratched and therefore before the VTL space is released for the volume.

• Number of database backups volumes
  A Tivoli Storage Manager server instance database backup volume will not be reported in the occupancy commands but will be reported as space occupied by the VTL. This is normal because the "QUERY OCCUPANCY" or the "SELECT * FROM OCCPUANCY" reports occupancy in storage pools and a database backup volume does not belong to a storage pool. Use the following commands to verify the number of database backup/snapshot volumes in use :
  
query volh type=dbb
query volh type=dbs

  
• Number of backupsets volumes
  Same as with the database backup and snapshot volumes, the backupsets volumes are not reported in Tivoli Storage Manager occupancy as they do not belong to a storage pool but still occupy space on the VTL. Use the following commands to verify the number of backupsets volumes in use :
  
q volh type=backupset
q backupset f=d

  
• Number of export volumes
  Same as with the database backup and snapshot volumes, the export volumes are not reported in Tivoli Storage Manager occupancy as they do not belong to a storage pool but still occupy space on the VTL. Use the following commands to verify the number of export volume in use :
  
q volh type=export