cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with my differential Incremental backups

raist25bd
Level 3
Hello all,

I have problems with my incremental backups. I have created my policies with a full schedule, that writes in one volume pool (Full_Pool), and incremental backups that writes in a different volume pool (Inc_Pool). I have observed a month ago that my incremental backups are growing day by day, if the filesystem that i have backed up have grow 10Gb i suppose that my incremental backup cannot grows 900Gb... I don't know what happens, i check that i am making diferential incremental and no cumulatives backups, i checked that the incremental backup is taken files that have no changes for  weeks...
Any idea will be welcome

Thanks for all
1 ACCEPTED SOLUTION

Accepted Solutions

Yasuhisa_Ishika
Level 6
Partner Accredited Certified
Check NDMP backup levels on NDMP Administrator's Guide, page 74.
support.veritas.com/docs/290205
I guess NDMP level comes up to 9, and backups can not work as differential backup.
Before NDMP level comes up to 9, you should run full backup to NDMP level set back 0.

Otherwise it might be came from bug. Which MP/release have been applied?

View solution in original post

11 REPLIES 11

Yasuhisa_Ishika
Level 6
Partner Accredited Certified
that mtime of each file is set in future date, or in windows env archive bit of file attribute can not be overwritten by some reason(read only FS and so on). Both leads to diff cannot work as dedired.

raist25bd
Level 3
I have checked some files and all have a past date, in one case in concrete 05/18/2009 1:40, this is the mtime in the backup and in windows. I have checked this file in the incremental backup of the 05/21/2009, i suppose that this file shouldn't be saved

Yasuhisa_Ishika
Level 6
Partner Accredited Certified
By default, Differential Backup get files with archive bit on, and after successful backup clear bit of each file.
Or try Incrementals Based on Timestamp (in client host properties) instead.

Stumpr2
Level 6
do you have some application like tripwire running?

DOCUMENTATION: After a UNIX backup, inode change times (ctime) change to the actual time of the backup. This may cause alerts in some security programs.
http://support.veritas.com/docs/240723

Details:
Manual:
Veritas NetBackup (tm) 3.4 Troubleshooting Guide for UNIX
Veritas NetBackup (tm) 4.5 Troubleshooting Guide for UNIX
Veritas NetBackup (tm) 5.0 Troubleshooting Guide for UNIX and Windows
Veritas NetBackup (tm) 5.1 Troubleshooting Guide for UNIX and Windows

Modification Type: Addition

Modification:
Security programs that monitor intruder detection, such as Tripwire, Symantec Host IDS or Symantec Intruder Alert (ITA) perform checks on system integrity. This includes monitoring changes in inode times.

When Veritas NetBackup performs a backup, it changes the inode of every file so that the inode change time (ctime) reflects the actual time of the backup. This can cause security programs to flag the system administrator that every single file may have been compromised, thus potentially causing unexpected alarms.

By default, with UNIX backups, NetBackup will store the atime (last accessed time) and mtime (last modified time) of a file, back it up and then restore the atime with the UNIX system call, "utime". The reason for this is because the backup procedure would otherwise change all the last accessed times on the server to the backup time. The "utime" system call changes the inode time, which causes the aforementioned alarms.

Appending the following line to the client's /usr/openv/netbackup/bp.conf file can change this behavior:
DO_NOT_RESET_FILE_ACCESS_TIME

This means that the client's atimes would be changed to the time of the backup, but the ctime will no longer be changed; therefore stopping the security alarms. If there is concern about atimes being changed for every backup, also consider that the UNIX find command does this as well when executed.

NOTE: This solution should not be used if also running Storage Migrator on the client in question, as it can affect migration of files. See the NetBackup System Administrator's Guide for more details.

An additional document is available on this issue for Symantec Intruder Alerts (ITA):
http://entsupport.symantec.com/docs/n2002112214515853

CY
Level 6
Certified
Do you have Kazeon or some AntiVirus program that could change the ctime?

Like Yasuhisa said, try use incremantals "based on timestamp" instead of "based on archive bit" for your Windows client.


raist25bd
Level 3
I don't have any program that can change the timestamps or this i think... I am making backup of filesystem of a NAS (Bluearc), the backup are made by NDMP protocol. The media and the master server have installed windows 2003 server, could i change this parameter in the master or media server (is the same)  DO_NOT_RESET_FILE_ACCESS_TIME

Yasuhisa_Ishika
Level 6
Partner Accredited Certified
Check NDMP backup levels on NDMP Administrator's Guide, page 74.
support.veritas.com/docs/290205
I guess NDMP level comes up to 9, and backups can not work as differential backup.
Before NDMP level comes up to 9, you should run full backup to NDMP level set back 0.

Otherwise it might be came from bug. Which MP/release have been applied?

raist25bd
Level 3
I don't understand what's MP/release? But i read the NDMP level that you recomend me and i think that i understand what's happening with my backups, but my question is, i can't make incremental backups more than 9 days consecutively, doesn't it?  Since the 9th day all my incremental backups becomes cumulative backups, doesn't it?

Yasuhisa_Ishika
Level 6
Partner Accredited Certified
that's correct.

raist25bd
Level 3
ok, i think that then i know what's the problems with my backups.

Thanks to all for your help
Regards

Stumpr2
Level 6
Please share with everyone what the solution was to your problem.