To reduce disk space issues with backups, up-to-the-minute (UTM) retention is triggered independently of overall backup retention.
Prior to SnapManager 6.1 for Microsoft Exchange, UTM retention was dependent on Backup Retention, and did not run if there were no backups or Snapshot copies to delete per the Backup Retention settings. The UTM Restore Retention did not enforce the retention policy until the Backup Retention policy was triggered.
For example, if there is a retention of 30 days for SnapManager for Exchange backups and a period of 4 days of UTM Restore Retention, UTM restore policy does not delete backed up transaction logs and mark the older backup sets “Point in Time” until the Backup Retention policy starts deleting the excess backup sets because its specified threshold is reached (when more than 30 days of backups are created). This situation has the potential to create disk space issues.
To address this concern, UTM retention is now separate from the backup retention, and can be triggered independently after the backup. Those two types of retention coexist within SnapManager for Exchange.
Valid input for UTM-related switches
The following switches can have the following values: RetainUtmBackups
Values: an integer between 0 and 255
RetainUtmDays
Values: a float value >= 0
A negative number generates an error message.
If you specify values for both RetainUtmBackups and RetainUtmDays, an error message is generated. However, there is one exception: in PowerShell, if you specify -1 for either
RetainUtmBackups or RetainUtmDays, then SnapManager ignores the switch and does not generate an error. Instead, it uses the prior backup retention method and takes the default value (0) for NoUtmRestore.
If none of the three UTM-related switches is specified, the prior backup retention method is used with the NoUtmRestore default value (0).
Registry keys
The following registry keys are added under HKEY_LOCAL_MACHINE->Software->Network Appliance->SnapManager for Exchange->Client:
• KeepLastNSnapshotOlderDayUtm REG_SZ
• KeepLastNSnapshotOptUtm REG_DWORD
When both KeepLastNSnapshotUtm and KeepLastNSnapshotOlderDayUtm have a valid value, SnapManager uses the following values of KeepLastNSnapshotOptUtm to determine if the operation is either number-based or day-based:
• 0: Number-based • 1: Day-based
• 2: Retain up-to-the-minute restore ability for all the older backups
There are three new entries added to the control file under <BACKUP_CLIENT_SETTING>: • <BACKUP_SET_TO_KEEP_UTM>
• <BACKUP_SET_TO_KEEP_IN_DAYS_UTM>
• <DELETE_BACKUPS_OPTION_UTM>
When both BACKUP_SET_TO_KEEP_UTM and BACKUP_SET_TO_KEEP_IN_DAYS_UTM have a valid value, SnapManager uses the following values of DELETE_BACKUPS_OPTION_UTM to determine if the operation is either number-based or day-based:
• 0: Number-based • 1: Day-based
• 2: Retain up-to-the-minute restore ability for all the older backups
UTM retention scenario 1: backups in a stand-alone system
This scenario assumes four backups exist in the stand-alone system with backup retention set to 8 and UTM to 3.
The result of this scenario is after the backup is complete, there will be 5 backups with the first 3 of backup with UTM restorability and the last 2 with PIT restorability.
• Before: N1 <- old => UTM N2 <- => UTM N3 <- => UTM N4 <- => UTM • After:
N1 <- old => PIT
N2 <- => PIT
N3 <- => UTM
N4 <- => UTM
N5 <- new => UTM
UTM retention scenario 2: days of backup in a stand-alone system
This scenario assumes 4 days of backup exist in the stand-alone system with backup retention as 8 days and UTM as 3 days.
The result of this scenario is after the backup is complete, there will be 5 backups with the first 3 days of the backup with UTM restorability and the last 2 days with PIT restorability. Although backup retention is set to 8, UTM is still enforced and deletes the extra transaction logs from specified management group.
• Before: D1 <- old => UTM D2 <- => UTM D3 <- => UTM D4 <- => UTM • After: D1 <- old => PIT D2 <- => PIT D3 <- => UTM D4 <- => UTM D5 <- new => UTM
UTM retention scenario 3: backups on a DAG Active node system
This scenario assumes 4 backups exist on a DAG Active node system with backup retention set to 8 and remote backup retention is also set to 8 and UTM to 3.
Although backup retention is set to 8, UTM still gets enforced and deletes the extra transaction logs from specified management group.
The result of this scenario after backup is complete is as follows: • Active node:
There will be 5 backups with the first 3 of the backups with UTM restorability and the last 2 with PIT restorability. N1 <- old => PIT N2 <- => PIT N3 <- => UTM N4 <- => UTM N5 <- new => UTM • Passive node:
There will be 5 backups with the first 3 of the backups with UTM restorability and the last 2 with PIT restorability. N1 <- old => PIT N2 <- => PIT N3 <- => UTM N4 <- => UTM N5 <- new => UTM
UTM retention scenario 4: days of backup on a DAG Active node system
This scenario assumes 4 days of backups exist on a DAG Active node system with backup retention set to 8 days and remote backup retention is also set to 8 days and UTM to 3 days.
Although backup retention is set to 8, UTM is still enforced and deletes the extra transaction logs from the specified management group.
The result of this scenario after backup is complete is as follows: • Active node:
There will be 5 days of backups with the first 3 days of backup with UTM restorability and the last 2 days with PIT restorability.
D1 <- old => PIT D2 <- => PIT D3 <- => UTM D4 <- => UTM D5 <- new => UTM • Passive node:
There will be 5 days of backups with the first 3 days of backup with UTM restorability and the last 2 days with PIT restorability.
D1 <- old => PIT
D2 <- => PIT
D3 <- => UTM
D4 <- => UTM
D5 <- new => UTM