File attribute N

[r3v0ke]

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!

[Wayne_Humphrey]

Firstly you would need to remove the Archive attribute not "N" or whatever that is.....

attrib -A /S /D

[Rob_Wilcox1]

I believe N means not to be content indexed:

http://msdn.microsoft.com/en-us/library/gg258117(v=vs.85).aspx

[Rob_Wilcox1]

> Found this also, sorry, hit send too soon on previous post:

http://www.vistax64.com/vista-general/79955-explorer-file-attribute.html

[r3v0ke]

Wayne and Rob

Thanks for the replies, with the Rob links I got this:

You cannot add/delete/change this attribute in the normal way, ie: it cannot
be changed using the attrib command.

To change this attribute, right click the folder/file and select
Properties/General Tab/Advanced Button. In the Archive and Index Attributes
section, place a check mark in the "Index this folder for faster searching"
option. Apply/OK. This will remove the "N" attribute.

So I can't attrib them... the last time that I checked the attribute of these files they were A

After the backup they became N

So, I need to change the attributes one by one ?

Since I can't do something like -attrib *.* -a /s /d

[r3v0ke]

In addition please see the printscreen below...

iN

[Wayne_Humphrey]

why cant you run attrib?

[Rob_Wilcox1]

I (personally) don't think the N is anything to do with it.

What errors in the VAC are you seeing exactly?  Does the Netbackup job put EV in and out of backup mode, and backup the files? 

[r3v0ke]

Well, the supported told me that N is nothing to worry about, but I'm still getting this:

There are 1080937 savesets that have not yet been backed up or replicated for Vault Store 'Mail Archiving'.

I'm trying to run a full backup on these DBs

EV_DIR_DB

EV_MONITORING_DB

EV_AUDIT_DB

EV_FSAREPORTING_DB

And already ran on these:

EV_VAULT_STORE_DB=Mail Archiving

EV_FINGERPRINT_DB= File Archiving

EV_VAULT_STORE_DB= File Archiving

EV_FINGERPRINT_DB=Mail Archiving EZSV126

EV_VAULT_STORE_DB=Mail Archiving EZSV126

EV_FINGERPRINT_DB=Mail Archiving EZSV125

But I have a question, maybe those savesets are old, and the Vault Store Name (Which tells the fingerprint db name) was just "Mail Archiving" back then. Then it was changed for "Mail Archiving EZSV125", could it be this the problem ?

If this is correct how can I confirm the name that this DB is using ?

[JesusWept3]

The error or warning you are getting is because items aren't being backed up or secured properly Each item is placed in to the JournalArchive and Watchfile table The journal archive table lists whether an item has been backed up or not via the column BackupComplelte And there is also an entry in the Watchfile table that links to the JournalArchive table and is the full path to the particular DVS file When storage starts or comes out of backup mode or whatever time you have your scan, it goes and gets a list of all the items in the WatchFile table and it scans the item and sees if the Archive Attribute exists on the file If it does not exist then it's considered backed up, removed the Watchfile entry and sets BackupComplete to 1 in the JournalArchive table Note that not all storage types support the archivebit (such as a NetApp using CIFS) and you would have to use a different backup mechanism such as the partition secure notification of the archivebittrigger.txt file Also note that not all backup software removes the archive bit and not all backup types (like differential) remove the archive bits

[r3v0ke]

JesusWept3, thanks for the reply

I'm using NetBackup and I had other savesets that were removed using the media that I'm using (don't know what media it is, but this number of savesets is new)

The items are being backed up, as I confirmed with the Netbackup logs and with the change of the file attribute from A to N

I'm performing incremental differential backups and the whitepapers that I read says that it is ok to do that, only the cumulative differential that doesn't remove the archive bit

Everytime that I perform a backup I take clear the backup mode, restart the Storage service and re-run all the checks, but I still got this error.

My last resource is to run a full backup on everything and see what I got

Any other suggestions ?

[killerbootz]

I'm having a similar issue right now. Attrib'ing the files to clear the archive bit and then manually settting/unsetting the backup mode on the vault stores should clear the savesets and start post processing. Just watch the size of your queues and adjust accordingly if it's not large enough. Also above i see the directives your backing up. are you also backing up your open/ready/closed partitions?  

[JesusWept3]

You shouldn't be using the attrib commands as that is shotgunning the issue You need to find out why the backup software isn't removing the archive bit itself

[r3v0ke]

There is a query to execute on the DB that I can see if the archive bit is removed or not ?

[JesusWept3]

You can do something like SELECT TOP 100 RelativeFileName FROM WatchFile This should give you a list of physical paths and files that it's awaiting to scan, you when then have to browse to those files check the archive attribute there

[r3v0ke]

Sorry, didn't understand, what you mean with RelativeFileName ?

[JesusWept3]

You asked for a SQL query?

[r3v0ke]

Yes, I tried the one that you said, and some variations but just got erros like No Object Name WatchFile

[JesusWept3]

Ok I might have got the column name wrong just do a SELECT TOP 100 * FROM JournalArchive One of those columns will be the full path and DVS file name

[r3v0ke]

Invalid object name 'JournalArchive'.

Anyways, I know where these are, the DVS are those on the printscreen that I sent on this topic, the attribute is N