cancel
Showing results for 
Search instead for 
Did you mean: 

Differential backup only capturing changes since last incremental

lrcai
Level 2

Hello. Backup Exec 2016, FP2.

Here's the plan I'm trying to implement:

Fridays at 7pm: Full backup to disk, duplicate to tape
Mon, Tues, Wed, Thurs at 7pm: Differential backup to disk, duplicate to tape
Hourly: Incremental backup to disk (not copied to tape)

I've got it all set up as described above, and Full + Inc works as you'd expect, and Full + Diff works as you'd expect. When I'm doing Full + Diff + Inc it doesn't work. I'm discovering is that the differential backups aren't capturing changes since the last full. Instead, they are only delivering changes since the last incremental. Veritas support is on the case, and they seem to think my plan should work, and are thusfar similarly baffled.

Are there any settings or conditions that you might suggest I investigate? Is this scenario not supported?

TIA.

1 ACCEPTED SOLUTION

Accepted Solutions

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

It is not a good idea to mix full, differential and incremental in same job

When the differential follows another differential OR the full then all is OK as the differential remains chained to the last full.

However when a differential follows an incremental  then the differential is chained to the last incremental AND not the last full and to really complicate things  if an incremental then follows that differential, then that new incremental will depend on the previous incremental as well.

To give a bit more detail:

Full on Friday = not chained to anything

Hourly Incrementals through Monday = chained through each other to Full

Differential on Monday  = chained through Monday incrementals to Full  (makes this differential into just another incremental and means a duplicate to tape of this set is also linked through incrementals on disk and not directly to the full and could means restores from tape might fail if the on-disk incremental sets have been erased and could also mean DLM reclaims of the incrementals are locked from deletion by  the differential sets on tape.)

Hourly Incrementals through Monday = chained through each other and Monday's incrementals to the Full

Differential on Tuesday   = chained through Tuesday + Monday Incrementals

... etc (until next full resets the seqeunce)

I believe that the backup industry in general often states, in ERROR,  that differential always depends on last full because the scenario of mixing incremental and differentials is rarely discussed and thus it is common usage to just say "Incremental depends on last full but differential only depends on full"

Unfortunately the above, simplified definition (while often being quoted in IT circles) is wrong, differential jobs actually depend on when the archive bit OR change journal was reset and because Incremental jobs do reset this information, the differential does depend on the last incremental OR full (and incidentally an incremental also depends on last incremental or full but not a differential which does not do the reset) I think that we may have some documents saying differential depends on full (ONLY) just because of the industry practice of saying the same thing.

This does cause confusion for Backup Admins in terms of sets required for a restore, overwrite protection, duplication to tape and also causes disk space issues as it has an effect on DLM chains as well.

If you have a case number for working with Veritas Support on this issue, can you please send it to me (suggest by Private Message)

 

 

 

 

 

 

View solution in original post

5 REPLIES 5

lrcai
Level 2

Oh, and:

Windows Server 2012R2
Backups based on modified time

Here's an example of what I'm seeing:

11/7 5:34pm, full, 18.5 TB

11/9 12:49pm, diff, 101 GB

11/9 1:17pm, inc, 101 GB

11/9 2:03pm, inc, 182 MB

11/9 3:03pm, inc, 241 MB

11/9 4:03pm, inc, 34.9 MB

11/9 4:04pm, diff, 1.95 GB <---This should be slightly larger than the 101 GB diff from 12:49

11/9 4:20pm, diff, 2.73 GB

11/9 4:30pm, diff, 2.73 GB

11/9 4:34pm, inc, 2.73 GB

11/9 4:38pm, diff, 6.15 MB <---Again, after running an incremental, the differential got smaller.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

It is not a good idea to mix full, differential and incremental in same job

When the differential follows another differential OR the full then all is OK as the differential remains chained to the last full.

However when a differential follows an incremental  then the differential is chained to the last incremental AND not the last full and to really complicate things  if an incremental then follows that differential, then that new incremental will depend on the previous incremental as well.

To give a bit more detail:

Full on Friday = not chained to anything

Hourly Incrementals through Monday = chained through each other to Full

Differential on Monday  = chained through Monday incrementals to Full  (makes this differential into just another incremental and means a duplicate to tape of this set is also linked through incrementals on disk and not directly to the full and could means restores from tape might fail if the on-disk incremental sets have been erased and could also mean DLM reclaims of the incrementals are locked from deletion by  the differential sets on tape.)

Hourly Incrementals through Monday = chained through each other and Monday's incrementals to the Full

Differential on Tuesday   = chained through Tuesday + Monday Incrementals

... etc (until next full resets the seqeunce)

I believe that the backup industry in general often states, in ERROR,  that differential always depends on last full because the scenario of mixing incremental and differentials is rarely discussed and thus it is common usage to just say "Incremental depends on last full but differential only depends on full"

Unfortunately the above, simplified definition (while often being quoted in IT circles) is wrong, differential jobs actually depend on when the archive bit OR change journal was reset and because Incremental jobs do reset this information, the differential does depend on the last incremental OR full (and incidentally an incremental also depends on last incremental or full but not a differential which does not do the reset) I think that we may have some documents saying differential depends on full (ONLY) just because of the industry practice of saying the same thing.

This does cause confusion for Backup Admins in terms of sets required for a restore, overwrite protection, duplication to tape and also causes disk space issues as it has an effect on DLM chains as well.

If you have a case number for working with Veritas Support on this issue, can you please send it to me (suggest by Private Message)

 

 

 

 

 

 

View solution in original post

Colin, thanks for clarifying the definitions of incremental and differential. (Alternatively, thank you for giving accurate definitions of incremental and differential where the documentation, UI, and first-level support do not.)

I'll soldier on with a different approach.

 

I have a question about another approach I'd like to try. Will this work?

Two separate jobs targeting the same data:
1) Full on Fridays at 7pm, with incremental hourlies; targeting disk.
2) Full on Saturdays at 7pm, with daily differentials; targeting tape.

I'm using the modified time. Will these two jobs interfere with one another?

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

If it was archive bit then definitely those two strategies won't work either, not sure for modified time as it would depend on if the change information is separated for each job definition or actually against the path being backed up, gut feeling is that two job definitions  probably won't help you either.

One thing I should point out - I am in the process of trying to clarify if our intention for modified time backups with Full + Inc + Diff should work as your results suggest or whether we did intend to change the behaviour to get rid of the archive bit problem when using modified time with Full + Inc + Diff (in effect looking to confirm if working as expected or a possible defect)