Savesets are not cleared after Backup

[EVRocks]

Hi,

The introduction of the latest version of NetBackup has caused many issues on our EV the latest issue that we have is that the savesets are not clearing therefore the awaiting archive items are not clearing out.

The environment consist of one EV (10.0.4) server, archiving emails and files and also journaling. for the last two weeks despite of having success full backup the EV still thinks the store are not backed up. initially we tried to introduce the EV backup instead of Windows flat files but this did not work. Now we back to Windows flat file mode.

the remove safety copies are configured after backup and the partition is set to use the archive attribute to secure the items after backup. I am not sure where the problem is but based on the attributes of the DVS files it seemed the backup does not clear the "File is ready for archiving". 

EV is off the backup mode and not sure where else in EV to check. The MSMQ queues are cleared. The fact that the file attributes is not changing I suspect it's Netbackup related issue due to all the changes but how can I be 100% sure the problem is not EV.

appreciate your advice.

[JesusWept3]

OK well, you stated you use After Backup with the Archive Attribute and when you check the DVS/DVSSP/DVSCC files, the "File is Ready for Archiving" attribute is checked, meaning the archive bit has not been cleared. Therefor its not EV.

I know some types of backup don't clear the archive bits (i think differential in Backup Exec doesn't clear them), so you're best off trying to work with your backup admins and symc support for NBU to determine why they're not clearing

[Switch]

This is a configuration issue with Netbackup. EV will only look for A attribute of the files. However, If you have to override that behaviour, you will have to use IgnoreArchiveBitTrigger file as mentioned in TechArticleTECH35610 http://www.symantec.com/docs/TECH35610

[JesusWept3]

IgnoreArchiveBitTrigger is a bit of a shotgun use, really should only be used for systems such as NetApp where archive bits don't get used or if you're using a backup method like Flash Backup where archive bits will never be removed

[EVRocks]

I have always been advised not to use the trigger file option.

Am I right to think that during the backup process EV is not invloved and it's Windows files and Netbackup that involved in th eprocess.

But what I would like to know is how EV knows or checkes the archive bit on the files that have been reset. Does EV goes through the dvs files or is it the backup mode that tells EV the dvs files have been backed up.

[JesusWept3 · Accepted solution]

When an item is archived, it goes to two tables, JournalArchive and WatchFile

JournalArchive has a column named "BackupComplete" and "IndexCommitted"
It tracks to make sure the items have been backed up and and the items have been added to the index
After a period of time, after the items are indexed and backed up, the items are removed, depending on how long you have your Transaction History set to.

Each saveset with a BackupComplete = 0, links to an item in to the WatchFile table
The watchfile table contains a a full link to the DVS file.

The StorageFileWatch process then goes through each file listed in watch file and checks to see if the archive bit exists or not, it kicks off after you come out of backup mode, or after you restart the storage service or on an internal schedule after a period of time, i think 12 hours?

If the item has the Archive Bit removed, then the watchfile entry in the vault store database is removed, and then BackupComplete gets changed from 0 to 1 in the JournalArchive table

It gets a little more complex than this when you have VaultStoreGroups with sharing enabled across all of them, for instance you may have an item that you link to in another partition and unless thats backed up and secured, then the other items will remain awaiting backup

In your situation, you could have EV turned off and it doesn't matter, its totally up to the backup software to remove the archive bit, then when you come out of backup mode, EV will check each file looking for the archive bit attribute

[EVRocks]

it turns out the problem was the NBU as expected. the Accelerator was enabled on the NBU policy. By design the accelerator will back up the flat files but does not reset the archive bit attribute on the files.

thank you all for your valuable input.