10-20-2014 03:00 AM
Hi
I have an issue in several policies where an incremental backup does a full backup.
It only seems to affect policies with Synthetic backups configured. Sometimes, but not always, the incremantal schedule does a backup of everything although almost no data in the selection list is modified. The problem often appears again after 3-5 weeks (the synthetic full backup still exists when the problem occurs).
The client have multiple policies - 8 with full synthetic / incr to basic disk, and one full / incr to MSDP w. accelerator so incremenrals are based on time stamp. Timeoverlap is default, 60 minutes, data is almost never changed on the client, it's only used for archived data.
Server is 7.6.0.3 on Win2008R2
Client is 7.6.0.3 on Win2012R2
thanks
10-20-2014 07:12 PM
Look at your policy schedule retention period, how long is it set for a synthetic full?
A synthetic full backup requires a base full backup and subsequent incr backup to work. If an incr backup could not find a base full backup to work with (due to expiration), it could run as a full.
10-21-2014 04:07 AM
The retention period for both the synthetic full and incrementals are the same (6 weeks in this policy), and the previous synthetic still exisit. The *original* full backup is expired since long ago.
johan
10-21-2014 04:31 PM
Any clue in bpbkar log like date and time which bpbkar backs up files modified after? If never enabled bpbkar logging, enable it and post logs as attachment. Be sure to tell backup histories.
10-22-2014 06:36 AM
Yes, I have bpbkar logging enabled, bit I'm not sure what to look after.
For example, yesterday (oct 21st) at 11:10 an incremental started and ran for 8 hours (it took a complete backup of the selection list instead of increments). In yesterdays bpbkar log (102114.log) there is nothing at all at ~11am or ~7pm when the backup completed.
I don't know what you mean by "Be sure to tell backup histories"
johan
10-22-2014 04:41 PM
Date and time is logged which bpbkar compares with modified time of files to determine file need to be backed up in incremental backups, if I remember right and logging level is enough high. This record is helpful when incremental backup works like full backup.
I don't know what you mean by "Be sure to tell backup histories"
We need date and time when former full and incremental backups ran to check if record in bpbkar is correct or not.
BTW, how many days you set as "Keep true image restore information for" in Clean-up section of host properties?
For logging issue, please check if you have created bpbkar folder in sufficient path on this client. Or run mklogdir.bat again on the client.
10-22-2014 11:59 PM
Hi,
The loggs dirs. are created long ago with mklogdir.bat, but maybe the default level for bpbkar might not be sufficient? Also, the bpbkar directory only holds files for one month back is seems (maybe it's a configuration setting).
For one of the policies with the issue I have attached a spread sheet with details (it's copied from "Report - Client Backups). The full synth (taken on sept 26th) still exists (the L-colomn is the expire date). In the bpbkar log from that day there's nothing at all from that time frame. The backup was taken 9:10:01am and the last entry in the log is 01:04:09am
Keep true image restore information for is set to 2.
11-06-2014 09:53 PM
The Incrementals in your attachment are significantly smaller than the Fulls.
1103060 | 4808794155 | Synthetic_Full |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
47105 | 600398 | Incremental |
1150185 | 4822205440 | Baseline_Full_Backup |
Not sure why you feel Incrementals are running as Fulls?
01-08-2015 12:18 AM
The issue is still there, the log I posted just doesn't show the affected incr. I have an ongoing case with this and according to this:
http://www.symantec.com/business/support/index?page=content&id=TECH76648
On Windows 2012 the option "True Image Restore information" is not supported on NTFS deduplication volumes.
The selection list of the affected policies are acctually on Win 2012R2 NTFS deduplication. The policies don't have "Enable optimized backup of Windows dedup..." enabled, so the NTFS dedup should not be "visible" to Netbackup (and system volume information if not being backed up, just some flat files). However, it's maybe a case of "not supported, might work sometimes, sometimes not"...
Right now I have disabled TIR & synthetics from one of the policies and waiting to see if the problem manistests again.
01-08-2015 12:54 AM
Wondering why on earth you would post output of a policy that is clearly not having an issue???
01-08-2015 01:32 AM
It have the issue, just not under during that time period.