Configuring the retention period of migration copies

You can control the period for which migration copies are stored in Tivoli® Storage Manager storage. If you accept the installed-default data management policy, migration copies can be deleted from Tivoli Storage Manager storage in one year.

Files that are migrated by HSM for Windows client are stored as migration copies on a Tivoli Storage Manager server. The migration copies are stored in the storage pool that is defined by the archive copy group of the assigned management class. When migration copies are created in the HSM pool, they are bound to a management class. The migration copies are retained according to the policy specified in the archive copy group of the management class. If the retention period is too short, Tivoli Storage Manager can delete the migration copies on the Tivoli Storage Manager server and leave orphan stubs on the file system. In this case, the migrated files cannot be recalled, and must be restored from backup copies.

If you do not specify a management class for your migration copies, they are bound to the default management class. The default policy values in the archive copy group of the standard management class retain migration copies for only one year.

If the default management class has no archive copy group, the migration copies are retained according to the ARCHRETention value defined for the domain.

The archive copy group specifies three attributes that determine the period that migration copies can be retained on the Tivoli Storage Manager server.

RETVer determines the number of days to retain a migration copy.
RETInit determines when the RETVer attribute is applied.
If RETInit=EVent, the RETVer attribute applies when a HSM for Windows client reconciliation process determines that a migration copy is no longer needed. Migration copies are retained like this:
1. A stub is deleted from the file system.
2. Reconciliation determines that the migration copy on the Tivoli Storage Manager server is no longer needed. Reconciliation sends an event notice to the Tivoli Storage Manager server.
3. When the Tivoli Storage Manager server receives the event notice from the reconciliation process, the retention period specified by RETVer begins.
4. When the retention period specified by RETVer ends, the Tivoli Storage Manager server marks the file for deletion.
5. When the Tivoli Storage Manager server runs an expiration process, the migration copy is deleted from the Tivoli Storage Manager server.
If RETInit=CREATion, the RETVer attribute applies when a migration copy is created. If the RETVer period expires before a stub is deleted, Tivoli Storage Manager server deletes the migration copy. This leaves an orphan stub on the file system. If a stub is deleted before the RETVer period expires, a migration copy is retained like this:
1. A stub is deleted from the file system.
2. Reconciliation determines that the migration copy on the Tivoli Storage Manager server is no longer needed. Reconciliation sends a deletion notice to the Tivoli Storage Manager server.
3. When the Tivoli Storage Manager server receives the deletion notice from the reconciliation process, the Tivoli Storage Manager server immediately marks the migration copy for deletion.
4. When the Tivoli Storage Manager server runs an expiration process, the migration copy is deleted from the Tivoli Storage Manager server.
After a copy group is defined, the RETInit value cannot be updated.
RETMin determines the minimum period to retain a migration copy after it is created. This attribute applies only when RETVer=EVent.

Choose a management class with an archive copy group that meets your data retention needs.

When you configure the connection between the HSM for Windows client and the Tivoli Storage Manager server, you can specify a management class. This management class becomes the default management class for new migration jobs and new threshold migration configurations. You can specify a different management class for migration when you configure a job or threshold migration, and when you start a migration using dsmclc.exe. The management class that you specify when you configure a job or threshold migration overrides the default management class for migration. The management class that you specify when you start a migration using dsmclc.exe overrides the configured management class for migration.

Jobs and threshold migration that were configured prior to version 6.1.3 did not specify a management class, and they used the default management class for the policy set. Those jobs and threshold migration continue to use the default management class for the policy set until you reconfigure them. Note that the default management class for the policy set can be the same as the default management class for new migration jobs and threshold configuration, but is not necessarily the same.