Incremental runs as full backup

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.

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

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.

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

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.

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.

The Incrementals in your attachment are significantly smaller than the Fulls.

Not sure why you feel Incrementals are running as Fulls? 

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.

Wondering why on earth you would post output of a policy that is clearly not having an issue???

It have the issue, just not under during that time period.