Symantec Backup Exec 2012 Default Incremental backup

[crocs]

Hi,

when i create a new backup to disk , SBE2012 offers me one full backup and one incremental backup.

The first with "keep for: 2 Weeks " and The second with " keep for: 1 Weeks ".

This policy means that I can go back to the files older than one week? or two week ?

thx

:)

[Kiran_Bandi]

The first with "keep for: 2 Weeks " and The second with " keep for: 1 Weeks ".

Because considering after one week you will be running the FULL backup again, no need of last week's incrementals.

[SuperBrain]

Keep for - Designates the amount of time for which you want to keep the backup sets or job history.

Which means, the Full backup set will be protected for 2 weeks, hence you will be able to restore information backup to 2 weeks from this set.

Similarly Incremental backups will be protected from being overwritten for 1 week.

Automated data lifecycle management (DLM) for disk and cloud storage

Backup Exec uses data lifecycle management to automatically expire backup sets on disk and cloud storage. Backup Exec reclaims the storage space when the amount of time that you specify when you create the backup job expires. If backup sets are dependent on other backup sets, then Backup Exec does not expire the data until all expiration dates are reached. You do not need to manage media when you keep backup data on disk or cloud storage.

As per the Best Practices (http://www.symantec.com/docs/HOWTO74427)

When setting up the schedules for backups in a backup definition, avoid adding many incremental backups between full backups. The data lifecycle management process must search through each backup set to check dependencies; therefore, the more incrementals there are, the longer the DLM process takes.

DLM will not expire backup set that depend on another backup set (incremental) to expire unless the backup set on which it depends is expired (i.e. full).

[Kiran_Bandi]

Hi Bhavik,

DLM will not expire backup set that depend on another backup set (incremental) to expire unless the backup set on which it depends is expired (i.e. full).

The above statement is a bit confusing. What do you mean by that? BE will not expire incrementals (even with one week retention) untill FULL backup set (with 2 week retention)?

[SuperBrain]

Which is why the Best Practices state :
 

When setting up the schedules for backups in a backup definition, avoid adding many incremental backups between full backups. The data lifecycle management process must search through each backup set to check dependencies; therefore, the more incrementals there are, the longer the DLM process takes.

[Kiran_Bandi]

I think it is reverse....

If you have dependent backup sets (Incrementals/differentials ) with higher retention than baseline backup (FULL), then BE will not expire baseline backup till dependent backups expires.

[SuperBrain]

What i meant was :

4wks         2wks             2wks             2wks           2wks            4wks

FULL ---> INCRE 1 ---> INCRE 2 ----> INCRE3 ----> INCRE4 ----> FULL 2

Every incremental backup is dependant on the previous full/incremental backup.

In this case, 

INCRE4 is dependant on INCRE3 (so this will not be expired before INCRE4), similarly

INCRE3 is dependant on INCRE2

INCRE2 on INCRE1

INCRE1 on FULL

FULL 2 is independant.

[crocs]

Thx for the replay.

In this scenario (keep for: 2 Weeks " -> FULL and " keep for: 1 Weeks -> INC)
Es: In sequence from top to bottom:

Day: 1  Sunday ( FULL_A )
Day: 2  Monday( INC1_A ) -> file a.txt modified ( version 1 )
Day: 3  Tuesday( INC2_A )
Day: 4  Wednesday( INC3_A ) -> file a.txt modified ( version 1.1 )
Day: 5  Thursday( INC4_A ) -> file a.txt modified ( version 1.2 )
Day: 6  Friday( INC5_A )
Day: 7  Saturday( INC5_A )

Day: 8  Sunday ( FULL_B )
Day: 9  Monday( INC1_B ) -> in this case - Day: 2  Monday( INC1_A ) is expired, data is overwriten? by the job - Day 9  Monday( INC1_B ) ?

if data is overwritten by Day: 9  Monday( INC1_B ) and the data are no longer available in Monday( INC1_A )  file a.txt ( version 1 ),
the file a.txt ( version 1.2 ) is recoverable? since it depends on the previous version 1 and versione 1.1 ?

Thx
:)

[SuperBrain]

INC1_A (Keep for 1 week) will not be expired because the backup set on which it depends (FULL_A = Keep for 2 weeks) is still alive! (remember dependant backup sets will not be expired unless the backup set it depends on are expired).

[crocs]

when expired the Day: 1  Sunday ( FULL_A ) , witch incremental start deleting ? ( INC1_A ) then ( INC2_A ) ecc... ? or together?

[SuperBrain]

I just read through the DLM Blog Entry (very interesting one) which states the following:

"The dependency of full and associated incremental backup sets will be checked to prevent broken chain of full/incremental backup sets.   In other words, DLM won’t groom expired full and incremental backup sets if there is a dependent incremental backup set that has not expired.

DLM won’t delete the last copy of the latest recovery point chain.

§  The definition of the recovery point chain:

·      Associated full and incremental backup sets that are generated from the same job for the same resource using the same selection list.  (e.g. \\Server\C:, \\Server\MSSQL\BEDB)"

Going by the above explanation, 
MON - FULL_A will be retained for 2 Weeks (because it doesnt depend on any backup set what-so-ever)

TUE - INC1_A will be expired after 1 Week but not groomed (overwritten) yet. (coz INC2_A depends on this)

WED - INC2_A will be expired after 1 Week but not groomed (overwritten) yet. (coz INC3_A depends on this)

THU - INC3_A will be expired after 1 Week but not groomed (overwritten) yet. (coz INC4_A depends on this)

FRI - INC4_A will be expired after 1 Week but not groomed (overwritten) yet. (coz INC5_A depends on this)

SAT - INC5_A will be expired after 1 Week but not groomed (overwritten) yet. (coz INC6_A depends on this)

SUN - INC6_A will be expired after 1 Week.

"FULL_A to INC6_A" = 1 Recovery Point Chain (as per the second rule mentioned about, DLM won't delete the last copy of the latest recovery point chain) i.e. till the time next Recovery Point Chain is complete.
Having said that.... 

All backup sets will be kept till Next Sunday i.e. till the time INC6_A is expired. When INC6_A expires, the complete INCREMENTAL CHAIN (INC1_A - INC6_A) is ready to be groomed. (remember FULL_A is an independant set + FULL_A = keep for 2 weeks)

Although, the complete INCREMENTAL CHAIN is expired and ready to be groomed, it will still be retained till the point a new Recovery Point Chain is complete i.e. next MON - SUN backups are complete :)

I'm sorry if i made this a little confusing, but I've tried to use your example to help you understand this better... 
 

Here's the link to the blog entry: https://www-secure.symantec.com/connect/blogs/data-lifecycle-management-be-2012

[pkh]

Although, the complete INCREMENTAL CHAIN is expired and ready to be groomed, it will still be retained till the point a new Recovery Point Chain is complete

The previous chain will be groomed once the last incremental backup or full backup has expired (which ever is later) and the next full backup is created (next recovery point).  There is no need to wait for the next chain to expire.  The next full backup is sufficient to recover the server.

[SuperBrain]

DLM has a rule according to which, backup exec 2012 will NOT groom the last available Recovery Point Chain (regadless of full/incremental/all sets being expired) unless it has a new Recovery Point Chain successfully complete. Important thing to understand here is tht it will not groom the Recovery Point Chain (full + all incre's before the next full). I dnt mean that the previous full / incre's / all backup's are required even after a new full is successful. I'm just tryin to explain how DLM will play its role to ensure data is available and safe. One last thing to add, there was a known issue with be2012 dlm not following the above rule. It is said to be fixed i think in one of the hotfixes (which is included in the service pack 1)

[pkh]

DLM has a rule according to which, backup exec 2012 will NOT groom the last available Recovery Point Chain (regadless of full/incremental/all sets being expired) unless it has a new Recovery Point Chain successfully complete.

Can you provide the documentation to substantiate the above statement?

[SuperBrain]

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 un groomed expired backup sets and fall into this rule.

http://www.symantec.com/docs/TECH187957

Like mentioned earlier, this is also explained in the blog entry: https://www-secure.symantec.com/connect/blogs/data-lifecycle-management-be-2012 by Anker Tsaur who is the leader of Design and Development team of DLM feature in Backup Exec 2012.

[pkh]

When you start on a new chain, i.e. create the full backup, the previous chain is no longer the latest chain and hence it can be deleted.  The document does not say that the latest chain must be completed before the previous chain can be groomed.  It only says that the latest chain will be kept until there is another later chain.

[SuperBrain]

Full backup = 1 backup set (not a chain). As per DLM rule, the "chain" will be kept un groomed. 

Secondly, if we have to think of DLM to work as you mentioned above, it is only working as per the "dependancy rule" (i.e. Full backup is independant, so the previous backups sets are not required) and not utilizing the following rule at all.

Rule states "DLM won't delete the last copy of the latest recovery point CHAIN." (not being rude by typing "chain" in all CAPS, just that there is no underline option so i have to use CAPS to highlight that word )

Following is a reply by Anker Tsaur on his blog entry:

"The logic used to determined

The logic used to determined the last copy of the latest recovery point chain for each resource is the  backup sets that are required to successfully recover to the latest point-in-time for a selected resource. 

For example, If you backed up your C: with weekly full and daily incremental to storage#1 with one week retention, and duplicate them to storage#2 with 2 week retention. You have following backup sets generated after first two weeks. And you decide to delete the backup job of C: 

On storage#1:

Full00, Incr01, Incr02, ...., Incr06, F10, Incr11, Incr12, ..., Incr16

On Storage#2:

Full00c, Incr01c, Incr02c, ...., Incr06c, F10c, Incr11c, Incr12c, ..., Incr16c

On the first day of the third week, DLM will delete follwoing backup sets:

Full00, Incr01, Incr02, ...., Incr06,

On the first day of the fourth week, DLM will delete follwoing backup sets:

F10, Incr11, Incr12, ..., Incr16 + Full00c, Incr01c, Incr02c, ...., Incr06c

The following backup sets will never be deleted since they are the last copy of latest recovery point chain of C: backup.

F10c, Incr11c, Incr12c, ..., Incr16c"

[pkh]

I am not sure whether I misunderstood you.  Let's say we have this scenario.  All the backups are kept for 1 hour.  This short expiry date is deliberate so that the retention period does not come into play.

Full backup is done on Sunday and incremental backup are done from Mon. to Fri.

So in 2 weeks, we should have done the following jobs with the corresponding backup sets

Full F1, Incr 11, Incr 12, Incr 13, Incr 14, Incr 15

Full F2, Incr 21, Incr 22, Incr 23, Incr 24, Incr 25

If I read you correctly, you are saying that only after Incr 25 is done, will the chain Full F1, Incr 11, Incr 12, Incr 13, Incr 14, Incr 15 be groomed.

I am saying that as soon as F2 is done, the chain Full F1, Incr 11, Incr 12, Incr 13, Incr 14, Incr 15 can be groomed.  This is because I am able to recover my server to the point in time when F2 is done.  As soon as F2 is done, the Full F1, Incr 11, Incr 12, Incr 13, Incr 14, Incr 15 chain is no longer the latest chain and therefore it can be groomed.