Files backed up in previous incremental backups continue to get backed up on subsequent incremental
Files backed up in previous incremental backups continue to get backed up on subsequent incrementals.
Running HP Data Protector v9.05 on Windows 2008 R2 professional as my Cell Manager.
I'm backing up a Windows 2008 R2 client and have noticed for several months that the Incremental backups are running a very long time (over 3days). FIles that were backed up in previous INC backups and that have not changed (modified date still the same) are being backed up over and over. I made sure the backup schedule is set to INC (regular INC) not INC1 or INC2 (differential).
10/01/2016 - FULL backup runs - All files are backed up.
10/02/2016 - INC backup runs - new and modified files are backed up.
10/03/2016 - INC backup runs - new and modified files PLUS the files from day before are backed up.
10/04/2016 - INC backup runs. files that were backed up on 10/02, 10/03 are again backed up.
Like I said....I checked the schedule to ensure they are regular INC and not INC1.
When I create a backup listing using omndb -winfs object -session -catalog I get the modify time stamp for files and I see that DP is backing up files that have not been modified.
I just opened a case with HP Support but was wondering if anyone has seen this behaviour before and can offer any tips or suggestions. Could it be a setting on Windows OS on the client.
Thanks in advance for any suggestions, tips, help.
Yes, the last FULL backup (successfully completed) was 3 weeks ago and it has catalog protected for 6 months and tape protected "permanent". I open a case with HP and they suggested recreating the datalist (backup job) and kiking off a new FULL backup. This backup is very large and it takes a few days to complete so I have not been able to see if files on the 2nd INCremental will grab files from 1st INC.
Thanks for your response.
Yes, the last FULL backup (successfully completed) was 3 weeks ago and it has catalog protected for 6 months and tape protected "permanent".
That doesn't exactly prove the chain is intact. Cases like yours often involve different backup specs backing up the same objects. This is completely valid with DP and it will put them into the same backup chain, provided
- The specs have the same owner.
- The specs name the objects in question 100% identical.
While (2) is usually a given with only one spec (and the chain of fulls and incrementals specified by that spec's schedule), there still can be different owners even with a single spec. It happens when specs are manually started by different users, typically in backup testing. It's easily avoided by scheduling everything, even when testing - or by explicitly setting an owner in every spec.
If you are sure the chain is consistent (an incremental falling back to full explicitly is easy to spot, it produces a warning after all), I'd check the exact settings for the source. There are mechanisms to detect which files should be part of an incremental, and those mechanisms may fail. E.g. it obviously makes no sense to rely on the archive bit with WinFS when you are doing your backup via a VSS snapshot (in general, the archive bit is evil, it also doesn't scale in other ways - just imagine two different backup systems fighting for it). Journal based mechanisms may fail for one reason or another, too. Pure timestamp-based mechanisms work most reliable, so that's what most enterprise backup systems including DP default to.