cancel
Showing results for 
Search instead for 
Did you mean: 

Incremental backup has the same size as a full backup

Bogdanl
Level 4

Hello,

Could you please let me know if you have any ideas why the incremental backups has the same size as a full backup ? This happened only on the GPFS Filesystem. The filesystems are mounted directly on the media server and for the other backups everything works fine !

The data backup are Unix

The policies backup Unix data (ascii files) on a GPFS filesystem

Version of NBU is 7.6

The timestamp of files has not been modified

Thank you

 

1 ACCEPTED SOLUTION

Accepted Solutions

After remove  the accelerator i noticed an improvement for incremental backup compare to last week, this workaround seems to be OK. Thank you all for your answers !

View solution in original post

11 REPLIES 11

Thiago_Ribeiro
Moderator
Moderator
Partner    VIP    Accredited

Tell us more about your environment?

OS version
GPFS version

Can you check this TN?

https://www.veritas.com/content/support/en_US/doc/18716246-126559472-0/v107946958-126559472

 

 

Thiago

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
Probably a silly question, but can you confirm that the Full and Incr schedules are in the same policy?

For troubleshooting, please ensure that bpbkar log folder exists on the client with logging level at 3.
Please copy the log after next Incr backup to bpbkar.txt and upload here.

Hello Marianne,

Yes, the Full and Incr schedules are in the same policy .

Incremental  is configured to use  option “ Based on archive bit”, do you think we can safely switch to “ Based on timestamp”?

Thank you

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

'Archive Bit' is only applicable to Windows clients.

For Unix/Linux, NBU uses mtime.
See this extract from the Admin Guide: 
https://www.veritas.com/content/support/en_US/doc/18716246-126559472-0/v41780104-126559472

Customers can choose to have NetBackup use the ctime and the mtime of the file to determine what files to include in an incremental backup. Normally, these two options are used together, but there may be some sites that want to use one without the other. By default, NetBackup uses only the mtime of the file to determine what files and directories to back up.

I forgout to mention, the same issue is also on windows.It seems that the issue appear after customer migrate the BasicDisk to PureDisk. An example below the Full equal the Incr whereas few data were modified

 

02/26/2018 19:00  03/29/2018   799563 552122844  N  Differential In 0       0            BK_NC_NT_DATA_SAN9940_PUAQU-FS002_F_TAPE

02/26/2018 19:00  03/29/2018    75041 572838054  N  Differential In 0       0            BK_NC_NT_DATA_SAN9940_PUAQU-FS002_P_TAPE

 

 

02/25/2018 12:42  03/28/2018   799563 552122843  N  Full Backup     0       0            BK_NC_NT_DATA_SAN9940_PUAQU-FS002_F_TAPE

02/25/2018 12:42  03/28/2018    75041 572838054  N  Full Backup     0       0            BK_NC_NT_DATA_SAN9940_PUAQU-FS002_P_TAPE

Mouse
Moderator
Moderator
Partner    VIP    Accredited Certified

A potentially stupid question since you've mentioned Pure Disk (I guess MSDP) - did the policy has Accelerator enabled and you indeed create full backups at the back end? In this case the outcome is perfectly in line with the documented behavior

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
So, your opening post clearly said " This happened only on the GPFS Filesystem".

Are you saying this is happening on all, or some, or 1 or 2 systems?

Besides the STU in the policy, what else has changed in the policy config?

My suggestion is to select 1 client to troubleshoot.
Create bpbkar log folder and set logging level to 3.
Check the log after next Incr backup.
This should tell us how files are being evaluated for backup.

Hello Marianne,

The bpbkar log set to level 3 has 3gb !

Yes the same issue is happening on Windows Server 2008 R2

The version of NBU is 7.6.0.2  ,pure disk configuration with accelerator enabled for all policies and each one have 2 schedules for Full backup:

 -a schedule the with the option “Accelerator forced rescan” executed every month

-a schedule without this option executed every weeks

Both schedules Full and incremental are in the same policy !

Parameter has been change from Based on archive bit to  Based on timestamp without success

This issue appear after migrated from BasicDisk to PureDisk in december last year !

As far as i know version 7.6.0.2 is out of support , could be a bug related to PureDisks configuration ?

Thank you

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

You are right - 7.6.x has been EOL'ed for over a year. I really don't know (can't remember) if there was an issue with Incr and MSDP. 
My guess is that something else is wrong. 
If it was MSDP, then ALL backups going to MSDP will be affected. 

Here is how you can test:
Create a small folder with 10 or so text files. 
Rename current bpbkar log.
Create an new policy with full and diff schedule for this policy.
Run full backup.
Rename bpbkar log to bpbkar-full.txt.
Modify one of the text files.
Run diff backup.
Rename bpbkar to bpbkar-diff.txt and upload both. 

Thank you for your answer. I will try this. First i want to check how is goes without accelerator enabled. I found this bug

https://www.veritas.com/support/en_US/article.TECH225783  even if it say that was solved in 7.6.0.2 i will try to see what happened

After remove  the accelerator i noticed an improvement for incremental backup compare to last week, this workaround seems to be OK. Thank you all for your answers !