Policy domains, management classes, and copy groups
This domain tests how retention is modeled. A policy domain groups nodes and contains policy sets; a policy set contains management classes; a management class contains backup and archive copy groups. The copy group controls destination storage pool and retention.
Core rules
Only one policy set can be active in a policy domain. You define a policy set, define management classes and copy groups, validate the set, then activate it. A node belongs to one policy domain and binds its data to a management class, often the default management class. Backup copy groups use parameters such as FREQUENCY, VEREXISTS, VERDELETED, RETEXTRA, and RETONLY. Archive copy groups use archive retention values. The destination storage pool must already exist.
Worked example
Create domain FIN, policy set STANDARD, management class DAILY, and a backup copy group with destination DISKPOOL, FREQUENCY=1, VEREXISTS=7, RETEXTRA=14, VERDELETED=2, and RETONLY=30. Validate and activate the policy set, then register nodes in FIN. The reasoning is that retention is policy-driven: backups become inactive and are expired according to the copy group, not by manually deleting files from a storage pool.
Traps
Do not assume every management class is the default; assign a default explicitly. Do not activate an unvalidated policy set. Changing a copy group does not instantly delete or move existing data; expiration and reclamation apply later. Do not point a copy group at a nonexistent pool, and do not confuse backup retention with archive retention.