Veritas NetBackup "Skipping" files during backup

[Mike_316]

Hey Gang,

Has anyone had any difficulty with Veritas NatBackup 4.5 â skippingâ files during backups?

I have been running Veritas NetBackup for about 3 months. I did a test restore after the initial install, after which I simply monitored the output codes daily. Every day, the backups reported successful (code 0), but when I went to do a restoreâ ¦only the directories were getting backed up, not all the files. Of the approximately 500,000 files that should have been getting backed up, only about 70,000 were getting backed up.

I have had Veritas search through the verbose logs, the setup, the policiesâ ¦and they cannot come up with a reason. The â fixâ was to simply create a new, identical, policy to the one that was failingâ ¦which has been workingâ ¦but I need to determine a root cause, to verify that the NEW policy wonâ t start having the same issue.

[Steven E. Protter · Accepted solution]

No, we have not gotten this issue with 4.5 and 5.0 which we have implemented on one machine.

We're not backing up open oracle databases with it though.

SEP

[Dave La Mar]

Sorry if I am being over simple, but
1. Are any . (dot) type files. (Veritas specifically states these will not be backed up dependent on whether the back up is run from a schedule or script.
2. Are any of the files hanging off links? The link only will be backed up.
3. Have you defined cross mount points in the policy?

Stick with us. We'll get it. 4.5 FP3 in our shop.

Regards,

dl

[Mike_316]

Hey Dave,

I appreciate the optimism. I will stick with it! Veritas support has pretty much come to the end of their rope, so if we can't figure it out it will remain a mystery.

Veritas was backing up the entire system, so there were some ".filename" files, as well as some links. It is actually good that it does not follow links, however, as this would create redundancies. I DO, also, have it set to cross mount points.

I am suspicious these problems were probably not related to the issue, as less than 17% of the total files were getting backed up (don't have THAT many "." files :-), but I wonder if Veritas was MIS-identifying some files? And the biggest confusion is the fact that the new policy I created was identical to the failing one (Veritas confirmed) and yet the new one worked, and the old one didn't. No one seems to know why, and the logs didnâ t pick anything up (they thought everything was chugging along just fine.)

One tech mentioned something about having heard of the policy files â â ¦becoming corruptâ ¦â and causing behavior like this, but could not narrow down as to what KIND of corruption.

Also, we do have an exclude file, but Veritas says it was correct and was not causing the issue...plus it is the same file that is working with the new policy. The only other thing that may be throwing wrenches in the works, is that we have clearcase installed on the machine (administrative nightmare) but, again, the new policy has been working fine???

Its really bizarre, and I was just hoping someone else had run into this.

[Brian Butscher]

Dave,

We are running Veritas 4.5 MP6 with no problems. How are your policies set up for backing up your systems? Do you perform a full backup every day or once a week, are you performing incrementals or differentials? If you perform a full once a week then you will need to restore from your full and then from your incremental or differential to restore all the filles you need. It sounds like with the successful backups (code 0) you may be performing a full backup once a week but when you restore you are only seeing your incremental. Also update 4.5 to MP6.

Regards,

Brian

[KapilRaj]

i hv no idea abt netbackup but have worked on tivoli . An incremental backup will not backup files that have not changed from the last backup. Also (we call it management class in tivoli) has to be correctly set if u want to backup an open file else it would fail (?)

Kaps

[Todd McDaniel_1]

You arent expecting a full very day are you?

Or are you updating that many files everyday that they would be backed up normally? and backup failures are still being missed on current files?

Otherwise I am inclined to think it is normal behavior.

[Sanjay_6]

Hi,

check your bp.conf file at /usr/openv/netbackup/bp.conf

If there is an entry like this,

LOCKED_FILE_ACTION = SKIP

netbackup will skip all files that it is unable to lock. we have set this option since the absense of this option would fail the backup with error codes in case of files that are opened by apps and if veritas is unable to lock the file for backup. In our case we observed this problem primarily with DB2.

Hope this helps.

Regds

[Mike_316]

Hey Gang,

All good thoughts...I have replied in order... :-)

Brian: I was running a full every two weeks, and an incremental every day, with an expiration of one month. Unfortunately, when I went to do the restore...there were no files listed as available for restore (when browsing through the GUI, or searching) from any of the fulls or incrementals for the prvious two months.

Kaps: The files in question changed nearly every day, but part of the issue is I could not find the files within the fulls, OR the incrementals.

Todd: (see also note above) The files I attempted to restore actually changed almost every day...but, I was not able to find them within a full to restore either. The NEW policy I created, after discovering the issue, is working normally.

Sanjay: Great thought...but unfortunately, no. I did not have the lock files set to skip. I have SINCE set the locked files to skip within the new poilicy, but the new policy is successfully getting 95% of the expected files backed up...so I do not suspect a locked files issue.

Thanks again for the ideas. Keep 'em comin!

Mike

[Mike_316]

Alright...I think I figured it out. It is called a "comedy of errors."

It appears that the large majority of the files in question were being tagged with an incorrect "mtime", due to the manner in which they were being updated and brouhgt into the server.

The result was the incremental backups thought (since they use the mtime to determine if the file needs to be backed up) that file file needed to be skipped.

The files WERE actually appearing in the full backups, but due to the incorrect date tag, appeared to be invlaid versions from much earlier backups.

At least I can feel confident the mystery is solved, and the issue will not recurr.

Thanks again for all the help and suggesstions!
Mike