cancel
Showing results for 
Search instead for 
Did you mean: 

Incrementals based on timestamp

Richard_Senda3
Level 4

Dear all,

I have a Windows 2008 file server which I would like to back up.  I have configured a policy in NetBackup to take a Full backup once per month and a Differential Incremental backup once per day.

In the Client properties -> Client Settings, I have enabled the option "Incrementals: Based on timestamp".  I have done this because the file server being backed up is Read Only so NetBackup cannot clear the archive bit.

I ran a Full backup on the file server which completed with Status Code 0 and then verified this in the BAR GUI.

2 days later, I ran the Differential Incremental backup.  When this ran, I noticed that NetBackup backed up a lot of files that had not changed since the Full backup, the files had not been modified and not accessed since the last Full backup - the date stamp was exactly the same as the Full backup.  I then ran another Differential backup and noticed the same thing - files where the timestamp had not changed since the last Full/Differential backup were being backed up again. 

I have attached a screen shot of one of the files.  In the screen shot you can see that the file "cine00053.tif" has a Modified timestamp of 07/01/2008 and was backed up 3 times, first in the Full backup and then again in both of the Differentials.  This is not the correct behaviour, this file should not have been selected for backup in either of the Differential backups.

Does anyone know why this is happening and how I fix it?

The NetBackup version I am using is 7.0.1

Many thanks.

Richard.

1 ACCEPTED SOLUTION

Accepted Solutions

Richard_Senda3
Level 4

After turning on the bpbkar log, I can see this entry:

00:02:42.664: [4984.2636] <4> dos_backup::tfs_include: INF - folder (Bilder) has been created recently (since 10/01/2011 22:55:25).  It will be backed up in full.

When I checked this folder, the "modified date" is set to 17/12/2010, but the "Date created" is set to 06/02/2040, which is newer than 10/01/2011 so it got selected for backup. 

So when the option "Incrementals: Based on timestamp" is selected, NetBackup does not compare file/folder dates with what they were when the last backup was taken, but instead compares the file/folder dates with the date of the last Full/Differential backup.

In my case above, the date of the last backup was 11/01/2010 (which translates to 10/01/2010 allowing for the 60 minute time variance), so the folder "bilder", the date (06/02/2040) was compared not with itself in the last backup, but with the date that the last backup was run.

To fix this problem, I need to correct/reset all of the time stamps on the affected folders, clearly setting these to 2040 is not right.

Regards,

Richard.

View solution in original post

6 REPLIES 6

Marianne
Level 6
Partner    VIP    Accredited Certified

Please confirm that the Full and Incremental schedules are in the SAME policy.  If they are in separate policies, the incremental will be treated as if there was never a Full backup.

Nicolai
Moderator
Moderator
Partner    VIP   

Pls verify the schedule really is a differential incremental schedule and not a cumulative schedule. If the the schedule is a cumulative is explain the behavior you are seeing.

Richard_Senda3
Level 4

Marianne, Nicolai,

Many thanks for your help.  I can confirm that both Schedules (Full and Differential Incremental) are contained in the same policy.  I can also confirm that the schedule type has been set to Differential Incremental - you can see this from the screen shot I supplied previously.

What's wierd is that the backup selection list has been split into multiple streams.  Some streams perform a differential backup correctly, others do not.

I'll have to turn on the logging for bpbkar and see what's going wrong, but I think that Marianne may be saying that the Full backup I did may not have been successful (even though it finished with status code 0).  Hmm, I'll have a look at the logs and re-try it if they don't reveal anything useful.

Thanks.

Richard.

Marianne
Level 6
Partner    VIP    Accredited Certified

NBU has definitely backed up the file during a Full and the next 2 Diff's (as per your screenshot). I just needed confirmation that the schedules were in the same policy.

The question now is - was client properties successfully updated?

Please check by running the following on master:

bpgetconfig -M <client-name>

There will be lots of output. Look for:

Use_Archive_Bit =

You are 100% right about bpbkar - if all the config was done correctly, bpbkar will hopefully shed light on file selection...

Nicolai
Moderator
Moderator
Partner    VIP   

Do you by change have True Image Restore with move detection enabled as well ?. Can Netbackup write to [install_path]\netbackup\ ?

If Netbackup can' create TIR indexes or they are damaged every thing will be backup again.

This is just a guess -  The detailed status of the activity monitor will display a message about corrupt/missing indexes.

Richard_Senda3
Level 4

After turning on the bpbkar log, I can see this entry:

00:02:42.664: [4984.2636] <4> dos_backup::tfs_include: INF - folder (Bilder) has been created recently (since 10/01/2011 22:55:25).  It will be backed up in full.

When I checked this folder, the "modified date" is set to 17/12/2010, but the "Date created" is set to 06/02/2040, which is newer than 10/01/2011 so it got selected for backup. 

So when the option "Incrementals: Based on timestamp" is selected, NetBackup does not compare file/folder dates with what they were when the last backup was taken, but instead compares the file/folder dates with the date of the last Full/Differential backup.

In my case above, the date of the last backup was 11/01/2010 (which translates to 10/01/2010 allowing for the 60 minute time variance), so the folder "bilder", the date (06/02/2040) was compared not with itself in the last backup, but with the date that the last backup was run.

To fix this problem, I need to correct/reset all of the time stamps on the affected folders, clearly setting these to 2040 is not right.

Regards,

Richard.