cancel
Showing results for 
Search instead for 
Did you mean: 

B2D Backup sets don't get overwritten after retention time ends

NimaJ
Level 3


Background:

Running BE2012 1798.1244

OS 2008

We generally backup to disk and retain that information for 1-4 Weeks.  After most B2D jobs complete a duplicate job kicks off and duplicates the data to tape to be retained for 1 or 7 years.

 

My issue:  My B2D sets are not all being overwritten or delted even after their retention time has ended.  This causes the disk to fill up.

 

If I try to forcefully delete these expired B2D backup setsfrom the backup sets section of the Administrative console it informs me that "Other backup sets depend on backup set snapshot .." .  These dependent jobs are tape duplicate jobs that expire 1 or 7 years later. 

 

Why do my duplicate Tape jobs depend on the B2D jobs?  Shouldn't they depend on other tape jobs?  If I have a full and incremental on seperate tapes.

 

Any suggestion would greatly be apreaciatted. 

 

Thanks,

Nima

2 REPLIES 2

lmosla
Level 6

Hello,

go into Configuration Settings >Backup Exec Settings > Storage and check to make sure the Overwrite setting is "Overwrite recyclable media that is contained in the destination media set before overwriting scratch media"

and also see this link on how Backup Exec 2012 manages DLM http://www.symantec.com/docs/TECH201826 

are all of the Live updates installed?

 

 

NimaJ
Level 3
Thanks Imosla, The "Overwrite recyclable media.." option was not set and I have now set it. We will see in time if that really help. Unfortunately I doubt it will because the backup set is not recyclable because other backup sets depend on it. I just don't know why a tape backup set would depend on a disk backup set when the same data resides on tape. The link you provided stated "Backup sets from incremental and differential jobs are dependent on the backup sets that come from the full backup job in the same backup definition”. Do you by any chance know how I would define a backup definition? Thanks, Nima