POLICY DOMAIN – This is a container for policy and scheduling info
*BACKRETention* is a fallback value for any files which
have been backed up under the specified policy domain,
but for which there is now a lack of an active policy
set.
*ARCHRETention* is a fallback value for any files which
have been archived under the specified policy domain,
but for which there is now a lack of an active policy
set.
POLICY SET – This is a set of management classes within a POLICY
DOMAIN.
Only the active version has any effect. The active
version is created by issuing ACTIVATE POLICYSET
<set-name-you-made>.
After activating, you may edit the original set without
affecting the active copy.
MANAGEMENT CLASS – This is a classification for particular sets
of objects. Minimal set to be bound is an entire
archive for archiving (ARCHMC option) or a single file,
directory, filespace or everything for a backup
(INCLUDE option).
There can be many management classes per policy set,
but only ones in the active policy set may be
referenced
**The additional parameters for this structure are used
only for HSM migration.
BACKUP COPYGROUP – This is the structure which defines
retention of backup data. These settings are the most
confusing because their operation overlaps and may
require some to be set to “NOLIMIT” to attain the
desired effect.
*VERSIONS DATA EXISTS* – This value specifies the maximum
number of versions of a file which may be retained.
If this is exceeded by additional backups or imports,
then the next expiration run on the server will remove
the oldest versions until there are only this many
left.
**This may be “NOLIMIT” or a whole number.
*RETAIN EXTRA VERSIONS* – This value specifies the maximum
number of days to retain an inactive copy when there is
an active copy in the database.
**This may be “NOLIMIT” or a whole number.
*RETAIN ONLY VERSION* – This value specifies the maximum
number of days to retain the only inactive version of
a file once there are no active versions.
**This may be “NOLIMIT” or a while number.
**This does not affect active copies which are always
retained.
*VERSIONS DATA DELETED* – This is the maximum number of
inactive versions of a file to retain once the file no
longer has an active version.
*DESTINATION* – This specifies the storage pool to which
newly backed up data will go if it is bound to this
management class during backup.
**Rebound data will not move to a new pool
automatically.
**Data may be moved from this pool through migration or
MOVE DATA commands.
Archive Copygroup – This is the structure which defines
retention of archive data.
*RETAIN VERSION* – This is the only retention parameter
for archives, and is the number of days that the entire
archive will be kept.
*DESTINATION* – This specifies the storage pool to which
newly archived data will go if it is bound to this
management class during archive operation.
**Rebound data will not move to a new pool
automatically.
**Data may be moved from this pool through migration or
MOVE DATA commands.
Schedule – This is a time/date/frequency setting for when commands
may be automatically run by the tsm server either on the
tsm server (administrative) or on the tsm client (client).
Client Association – a separate entity that binds clients to schedules.
Node – A separate entity which defines a client and allows access.
——-
CAVEATS
——-
NOTE: Once an archive is made, it may not be rebound. In otherwords,
you may not specify a different management class for it. It IS possible
to change the copy-group retention period for this management class, and
then re-activate the policyset. This will change it’s retention;
however, be cautious with this, as you will affect ANY data in the same
management class.
NOTE: Management classes with the same name but which are within a
different policy domain will NOT conflict with eachother.
NOTE: Changes to a policy set will NOT have ANY effect unless that
policy set is copied into the active policy set with ACTIVATE POLICYSET.
Only the active policyset, and not it’s source policyset or any other,
will have an effect.
NOTE: Active versions are converted to inactive only by the client,
through client-side expiration. See the particular client code manual
for details. This may happen during a backup with an exclude list, or
during a backup with missing files, or through an API call to expire the
object.
NOTE: There are other parameters for all of these structures. Please
see the ADSM/TSM Administrator’s Reference Guide for details.
——-
EXAMPLE
——-
Backup copygroup is set as follows:
VDE = 3
VDD = 1
RETEX = 100
RETO = 1
Explaination:
– Versions 1 through three are kept up to 100 days FROM WHEN THEY
WERE BACKED UP.
– Any versions past 3 will be expired immediately upon the next
server-side EXPIRE INVENTORY process.
– NOTE: NO MORE THAN THREE VERSIONS WILL BE KEPT AFTER EXPIRE
INVENTORY, REGARDLESS OF THE NUMBER OF DAYS SPECIFIED IN
RETAIN-EXTRA AND RETAIN-ONLY!
– If the active version is made inactive (client side expiration),
then only the most recent copy will be kept, and it will only
be kept for one day FROM WHEN IT WAS BACKED UP.
——-
EXAMPLE
——-
Backup copygroup is set as follows:
VDE = NOLIMIT
VDD = NOLIMIT
RETEX = 14
RETO = 20
Explaination:
– All versions will be kept for 14 days FROM WHEN THEY ARE BACKED UP.
– When no active version remains (client-side expiration), the last
inactive version will be kept for 20 days FROM WHEN BACKED UP.
——-
EXAMPLE
——-
Backup copygroup is set as follows:
VDE = 5
VDD = 0
RETEX = NOLIMIT
RETO = NOLIMIT
Explaination:
– 5 versions will be kept while an active copy exists.
– Files will not expire by age.
– When the active version is made inactive, the next EXPIRE INVENTORY
will remove ALL versions of the file.