Items awaiting backup never decreases

[yarg]

Hi all,

We are experiencing an issue which I hope is relatively easy to resolve, but for which I do not have sufficient experience myself and so I hope that you will be able to assist. 

Our environment is EV8.0 SP2, running on a Windows 2003 box.  The problem is that the number of items awaiting backup is increasing all the time, currently sitting at 3.8 million.  This is impacting our users in that some are maxing our their Exchange mailboxes and being prevented from sending mail, because they have so many items which are stuck in "Pending archiving" status.
All backups are functioning correctly, so I'm sure that the problem lies somewhere in the scripts which are supposed to set/remove the archive bits etc, but I'm afraid I don't understand the mechanism well enough myself to troubleshoot it, and the person who wrote the scripts/put them in place is no longer around.  So I would appreciate any help anyone could provide please.  If there is any further information you need, or you need to see the script(s) etc, please let me know.

Many thanks,
G

[TonySterling · Accepted solution]

Hiya,

You need to verify that the archive bit is being removed.  If not then you need to use what is called a trigger file.  It the Admin help there is a secion on backups.

Also, what version are you?  If you are EV 8 you can refer to this technote and docs:
http://seer.entsupport.symantec.com/docs/312327.htm

http://support.veritas.com/docs/320294

[GertjanA]

Hello G.

EDIT - Tony beat me..

In short, you have 2 ways for backing up ev 8.0
1 - set ev in backup mode
2 - backup vaultstores, indexes, db's etc.
3 - have your backup software set the archivebit on the backedup vaultstore files (dvs, dvssp etc)
4 - set ev out of backupmode
5 - ev will process the files and the 'awaiting backup'  number will decrease.

second option
1 - set ev in backupmode
2 - backup ev
3 - place the triggerfile (IgnoreArchiveBitTrigger.txt) in the vaultstore-partition (only if backup succesfull ofcourse)
4 - take ev out of backup mode
5 - ev will process numbers will decrease.

There are some things to watch out for.
Make sure your ev is taken out of backup. Check VAC, to see if they are indeed not in backupmode.
Make sure the triggerfile has the current date/time, and is not copied from somewhere, having an old date.


Check documents:
http://seer.entsupport.symantec.com/docs/322930.htm
https://www-secure.symantec.com/connect/articles/enterprise-vault-best-practiceev-backups

There are some more documents on backing up EV8.

[yarg]

Hi gents,

Thanks a lot for taking the time to reply.  Actually, in the time since posting, I was asked to escalate and open a call with Symantec about the issue, so it's under investigation with them as well. 
Early signs are that when we went from v7.5 to v8.0 that the backup strategy was not correctly migrated, ie it seems that the scripts are now supposed to be in powershell (whereas ours were still the original batch files) and also we may not be backing up the new fingerprint DBs in SQL, which needs to be done or else EV will not consider the whole environment to be being successfully backed-up.

So I'm double-checking those items at the moment....

Thanks again,
G

[JesusWept3]

i could have sworn that the database being backed up required is optional and is turned off by default?

[GertjanA]

The files being in ' awaiting backup'  are related to the Vaultstore partitions being backed up. Not backing up the db is going to be a problem is you have a sql problem, but is not necessary for the EV-backup to work. (pending to archived change.)

[JesusWept3]

Well the thing is there IS an option that savesets aren't considered secure until the database is backed up, but i could have sworn it was off by default?

[Michael_Bilsbor]

Hi,

No there is no check on the database being backed up.  As long as the files are secure EV will post process the requests.

[JesusWept3]

Mike,
You can use the registry key to check the backup date of the database to determine whether an item should be considered secure or not.
It works very much like the changes to the IgnoreArchiveBitTrigger.txt mechanism.

i.e if you have a create date of 01/01/2010 on your ignoreArchiveBitTrigger.txt then an item that is 12/30/2009 will be considered secured, but an item that is 01/02/2010 will not be considered secured.

In the registry you can have it check the backup of the database, so if the database last backup was 01/01/2010 then only items older than that date would be secured. but by default it is turned off. There are two registry keys that control this, one to use the date of the database backup as the ONLY thing that SFW checks (i.e. it ignores the archive bit and just looks at the date of the item compared to the date of the last database backup) OR it uses it in conjunction (i.e if the archive bit is cleared AND its older than the last database backup, then it will post process the item as long as the other parts are secured)

but the point is moot as the reg key is obscure and not included by default