cancel
Showing results for 
Search instead for 
Did you mean: 

File attribute N

r3v0ke
Level 4
Partner Accredited

Hello everyone,

I just finished a backup and my DVS files are with the attribute N

In VAC there is a critical error still saying that my files aren't backep up, by the backup job on Netbackup  was 100% fine

Any suggestions ?

Thanks!

 

 

30 REPLIES 30

JesusWept3
Level 6
Partner Accredited Certified
The attribute is A for ArchiveBit I promise you Also the query should be ran against the Vault Store database, so make sure you don't run it against the EnterpriseVaultDirectory database or master etc
https://www.linkedin.com/in/alex-allen-turl-07370146

r3v0ke
Level 4
Partner Accredited

It was A, but after backup it turned out to N

I could ran the query, there are Archives with BackupComplete 1 and others with 0, I want then to be 1 right ?

JesusWept3
Level 6
Partner Accredited Certified
Go to the Watchfile table Find a sample of files Find them on the file system Check for the archive attribute Any file in the Watchfile table means that it is awaiting for the archive bit to be removed, then the item in WF is deleted and BackupComplete in JournalArchive is set to 1 Do not just change the columns to be a 1 manually
https://www.linkedin.com/in/alex-allen-turl-07370146

r3v0ke
Level 4
Partner Accredited

Here after the ran of the query:

watchtable.png

Them I went to the location of this file here

dvslist.png

Maybe the lines are not equal, but that file is in this folder, and all the files in this folder are marked with N

Wayne_Humphrey
Level 6
Partner Accredited Certified

*g*

N is for "Not Content Indexed" it has NOTHING to do with backup....

FILE_ATTRIBUTE_NOT_CONTENT_INDEXED

r3v0ke
Level 4
Partner Accredited

Well, if anyone is having the same problem, here is what I experienced:

With the differential incremental backup the archive bit is cleared, BUT NOT ON THE FIRST TIME, if it is a new partition, run first a full backup, and then run differential incremental backups.

This should solve

Thanks everyone for the replies

PeterWendell
Level 4

We were experiencing this problem intermittently with Netbackup on EV 10.0.1. Sometimes the archive bits would not be toggled even though the backup job had completed successfully. Switching to the Trigger File method solved the problem permanently. Netback automatically creates the trigger file when backing up EV, so it was simply a matter of selecting the Check for Trigger File option on the VS partition properties backup tab.

Rob_Wilcox1
Level 6
Partner
Interesting. So as was discussed at the beginning of the issue, the file attribute (N) isn't related to the problem, right?
Working for cloudficient.com

PeterWendell
Level 4

Rob,

Yes, that's correct. What I saw was that the archive bit was simply not being set by Netbackup even though the backup job completed successfully. The issue usually only happened on incremental backups and happened intermittently on the same job/profile/schedule. We verfied in the netbackup logs that the savesets were being properly backed up. Once the archive attributes were not set by a differential job, they continued to be left unset until the next full backup. Once the archive bit was successfully set on a saveset, EV always flagged the item as secured during it's partiton scan.  The trigger file method has worked flawlessly.

JesusWept3
Level 6
Partner Accredited Certified
To be honest the ignore archivebittrigger file is a sledgehammer approach You can look at this technote to determine what backup types clear the archive bit http://www.symantec.com/business/support/index?page=content&id=TECH15682 If the archive bits aren't clearing then this may indicate that backups are mis configured or not all items are getting backed up With the ignore archive bit trigger, it's little more than a guess as to whether items are being backed up
https://www.linkedin.com/in/alex-allen-turl-07370146

PeterWendell
Level 4

Jesuswept,

We are using a supported version of Netbackup with the EV agent. I made several pretty thorough investigations of the netbackup logs and could see that the savesets were definetly being successfully wrtitten to tape.

 

There was another thread on this a few months ago from a user with an identical configuration to ours who was experiencing the same issue and who worked it through with Symantec Support. Their soultion was to use the trigger file method. https://www-secure.symantec.com/connect/forums/items-stuck-pending-all-users