Example: Retention when a policy uses both version and time controls

Using both the version and the time controls in a policy gives you flexibility in managing data retention but also causes complexity. To understand the interactions among the controls, review example policies and their effects on the retention of one file's backup versions during one month.

See Table 1 and Figure 1. A client backs up the file REPORT.TXT four times in one month, from 23 March to 23 April. The settings in the backup copy group of the management class to which REPORT.TXT is bound determine how the server treats these backup versions. Table 2 shows how different copy group settings can affect the versions, as of 24 April (one day after the file was last backed up).

Table 1. Status of REPORT.TXT backup versions as of 24 April
Version	Date created	Days since the version became inactive
Active	23 April	(not applicable)
Inactive 1	13 April	1 (since 23 April)
Inactive 2	31 March	11 (since 13 April)
Inactive 3	23 March	24 (since 31 March)

Figure 1. Active and inactive versions of REPORT.TXT

Active and inactive backup versions of the REPORT.TXT file are bound to the policy in the default management class. The class contains a backup copy group with policy settings.

Table 2. Effects of the policy on retention of backup versions for REPORT.TXT as of 24 April
Backups	Deleted Backups	Keep Extra Backups	Keep Deleted Backups	Results
4 versions	2 versions	60 days	180 days	Backups and Keep Extra Backups settings control the expiration of the versions. The version that is created on 23 March is retained until the file is backed up again (creating a fourth inactive version), or until that version is inactive for 60 days. If the user deletes the REPORT.TXT file from the client file system, the server notes the deletion at the next full incremental backup operation by the client. From that point, the Deleted Backups and Keep Deleted Backups settings also affect the retention. All versions are now inactive. Two of the four versions expire immediately (the 23 March and 31 March versions expire). The 13 April version expires when it is inactive for 60 days (on 23 June). The server keeps the last remaining inactive version, the 23 April version, for 180 days after it becomes inactive.
No limit	2 versions	60 days	180 days	Keep Extra Backups setting controls expiration of the versions. The inactive versions (other than the last remaining version) are expired when they are inactive for 60 days. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup operation by the client. From that point, the Deleted Backups and Keep Deleted Backups settings also affect the retention. All versions are now inactive. Two of the four versions expire immediately (the 23 March and 31 March versions expire) because only two versions are allowed. The 13 April version expires when it is inactive for 60 days (on 22 June). The server keeps the last remaining inactive version, the 23 April version, for 180 days after it becomes inactive.
No limit	No limit	60 days	180 days	Keep Extra Backups setting controls expiration of the versions. The server does not expire inactive versions based on the maximum number of backup copies. The inactive versions (other than the last remaining version) are expired when they are inactive for 60 days. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup operation by the client node. From that point, the Keep Deleted Backups setting also affects the retention. All versions are now inactive. Three of the four versions expire after each of them is inactive for 60 days. The server keeps the last remaining inactive version, the 23 April version, for 180 days after it becomes inactive.
4 versions	2 versions	No limit	No limit	Backups setting controls the expiration of the versions until a user deletes the file from the client node. The server does not expire inactive versions based on age. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup operation by the client node. From that point, the Deleted Backups setting controls expiration. All versions are now inactive. Two of the four versions expire immediately (the 23 March and 31 March versions expire) because only two versions are allowed. The server keeps the two remaining inactive versions indefinitely.