Backup Exec 2012 introduces a new feature that prevents the overwrite or expiring of the last backup sets in a recovery chain. When multiple backup to disk or dedup sets exist for a resource, the last copy or latest recovery chain set can't be deleted or removed. This new Data Lifecycle Management ( DLM ) functionality is to ensure a server is protected and the latest backup set exists in case of a disaster recovery or restore. DLM has a rule to always keep the last copy of the latest recovery point chain per job definition per resource. These latest recovery points sets can be ungroomed expired backup sets and still fall into this rule.
Under certain conditions these backup sets that are not able to be deleted or groomed may fill up disk space cause low disk conditions or backups to stop if the storage device is out of space.
Cause #1: The Data Lifecycle Management (DLM) in Backup Exec 2012 is designed to keep an expired backup set until all of its dependent sets are expired before grooming them together.
A dependent set is determined by Backup Exec based on the data set relationship to guarantee complete data recovery for each backup point-in-time. For example, for NTFS file system backup, an incremental backup set depends on the last successful full backup set and all earlier incremental backup sets since the last successful full backup set.
a. Check if the retention settings for incremental backup sets are appropriate
According to Cause #1, if the retention of incremental backup set is set too long, then all the backup sets that the incremental depends on will not get groomed even when they are expired. They can only be groomed after all their dependent backup sets have expired.
b. Check if the job frequency for full backup job is appropriate
If a full backup job runs infrequently, and the incremental backup job keeps running, the earlier incremental backup sets cannot get groomed even after they are expired. This is because the newly created incremental backup sets are the dependents of these earlier incrementals, before their dependent backups expires they cannot be groomed. For example, if a full backup job is scheduled to run once a month, and the incremental backup jobs run hourly, then all of the incrementals that have run within the month will not be groomed until the new full backup job runs and the last incremental backup set created within the month expires.
c. Check the status of the full backup sets
As stated in the example presented in cause #1, an incremental backup set depends on the last successful full backup set and all earlier incremental backup sets since the last successful full backup set. If a full backup job failed, the incremental backup sets created after it depend on the earlier successful full backup set instead of this failed full backup set, and all the incremental backup sets since the earlier successful backup set. This will also prevent the expired backup sets from being groomed by DLM.
The solution for this issue is to get a successful full backup set.
Cause #2: DLM in Backup Exec 2012 has a rule to always keep the last copy of the latest recovery point chain per job definition per resource. This rule is enabled as default to guarantee that there is always a valid data recovery point. With this rule enabled, the backup sets that belongs to the last copy of these latest recovery point can not be groomed even when they are expired.
A recovery point chain is a chain of backup sets required to restore data to a point-in-time, for example [Full, Inc1, Inc2] is a recovery point chain that is needed to recover data to the point-in-time of Inc2. The latest recovery point chain is a chain of backup sets required to restore data to the latest backup point-in-time.
a. Check if many one-time only backup job have been created, and they only ran once or twice;
b. Check if there are old backup solutions that have been run before but are not scheduled to run any more.
To resolve this issue, the following registry value can be configured to disable the DLM rule mentioned above.
Note: Service Pack 1a (TECH186717) must be installed to proceed with the fix listed below. After installing SP1a, create the following registry key to turn on/off the "Keep the last and latest recovery chain" DLM rule.
Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.
1. Open Registry on the Backup Exec Media Server
3. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Server
4. Create a new DWORD value named DeleteLastRecoverySetsOnceExpired
5. Modify the value to 1
Note: In a CASO environment where the Adamm Database of Managed Backup Exec Servers (MBES) is on CAS this registry key needs to be set on the CAS server. This will be a central setting controlling all MBES.
If Adamm Database of MBES is local i.e. not on the CAS, then this registry key needs to be on MBES server.
After adding or changing the registry key the next time DLM runs the value or rule will be enforced.
Value: 0 - DLM will keep the last copy of the latest recovery chain.
1 - DLM will groom the last copy of the latest recovery chain when they expire.
In Backup Exec 2012 SP3 or earlier, the value of the registry key "DeleteLastRecoverySetsOnceExpired" affects only Disk Storage Device.
In Backup Exec 2012 SP4 or later, it affects not only Disk Storage Device but also Removable Disk Cartridge.
It is recommended a strong backup and duplicate strategy is in place before enabling this feature.
Backup Exec 2012
In Backup Exec 2012 SP3 or earlier, DLM manages only Disk Storage Device.
In Backup Exec 2012 SP4 or later, DLM manages both Disk Storage Device and Removable Disk Cartridge.