cancel
Showing results for 
Search instead for 
Did you mean: 

Savesets not backedup

EV7
Level 4

HI

 

Iam getting the following...

 

Event Type: Warning Event Source: Enterprise Vault Event Category: Monitoring Event ID: 41008 Date: 25/02/2009 Time: 9:00:18 a.m. User: N/A Computer: NTATCA511 Description: There are 30160 savesets that have not yet been backed up or replicated for Vault Store 'Exchange Vault Store 1'. Review your procedures and make any changes needed to ensure that backups happen in a timely fashion. If you are using an EMC Centera, check the size of the Centera replication queue. For more information, see Help and Support Center at http://evevent.veritas.com/rosetta/showevent.asp

 

Its always the same number of savesets. I have checked with the backup guys and they have advise its all backedup.

 

Anyways to change this so that the pst migration which are on completing state will be chaged to complete ?

5 REPLIES 5

Liam_Finn1
Level 6
Employee Accredited Certified

What kind of storage are you using, NTFS or Centera

 

What version of EV

 

There is an easy way to stop this but it means that EV will no longer  wait for the items to be replicated/backed up before it removes the safety copies

 

Select Properties of the Vault sore in question

In the General Tab there is a section for Settings, remove safety copies,

Set this to Immediate after archive

 

The system will no longer store safety copies of the items being archived to that vault store and the message will go away.

 

NOW saying that it is not a good idea to do this unless it is a vault store for journaling and the data is being stored on a Centera because this is a safety system to ensure that the data on your system is backed up or replicated to a DR device

 

If you see it as just an annoying message being created when you are doing a PST migration then do the above setting change during your PST migration project but i advise you set it back to its present setting once the PST import is complete

Paul_Grimshaw
Level 6
Employee Accredited Certified

Ok so as Scanner has stated you can switch to immed after archive but that will not help you in this situation as the change is not retrospective and these items are in the system as awaiting backup.

 

So what we need to do first is sanity check this warning as sometimes this appears and it is not true and this is usually down to statistics in SQL not being updated.

 

So at the time of you writing it was quoted that there were 30160 items awaiting backup. Now the 2 SQL tables we are interested in here are called watchfile and journalarchive.

 

What you should see if this warning is valid is 30160 rows in each of these tables within the Exchange Vault Store 1 database. SO first open up these tables and see if there is indeed any rows in there of that magnitude. Within the journalarchive table you will see that there is a backupcomplete column and an indexcommited column. If we are waiting for the archive bit to be reset then backupcomplete will be 0 and indexcommited will be 1.

 

If these tables are empty or have a lot lower value then I suspect that the warning is incorrect and I can advise you on how to deal with that should that be the issue.

 

EV7
Level 4

Hi Paul

 

I have checked both tables and they have info in them .Also checked the backupcomplete and indexcommited ,backupcomplete has 0 value and indexcommited has 1.

So looks like its a legitimate warning.

What now

 

Thanks P

Paul_Grimshaw
Level 6
Employee Accredited Certified

OK so we have ascertained that there is an issue. I think what I need to get from yiu is on what type of storage your DVS files reside on as this will depend on how the item is post processed.

If your storage is centera then we rely on Centera giving us a clip exits which tells us that the clip has been replicated to the replica Centera

If your store is netapp then we use a trigger file to indicate that the items have been backed up

If you use just NTFS storage then the post processing either takes place every 12 hours or on a storage service restart.

In the watchfile table as well should be the location of these files so if they are on an NTFS partition you can navigate and see if your backup guys are telling you the truth and that the archive bit for these files has been reset. If not then that is the issue.

If the items have had the archive bit reset then setup a DTRACE of the storagefilewatch process and restart the storageservice. This should trigger the post processing thread and then you will either need to look through this and see if there is anything obvious in there or open a case with support for analysis

Paul_Grimshaw
Level 6
Employee Accredited Certified

OK so we have ascertained that there is an issue. I think what I need to get from yiu is on what type of storage your DVS files reside on as this will depend on how the item is post processed.

If your storage is centera then we rely on Centera giving us a clip exits which tells us that the clip has been replicated to the replica Centera

If your store is netapp then we use a trigger file to indicate that the items have been backed up

If you use just NTFS storage then the post processing either takes place every 12 hours or on a storage service restart.

In the watchfile table as well should be the location of these files so if they are on an NTFS partition you can navigate and see if your backup guys are telling you the truth and that the archive bit for these files has been reset. If not then that is the issue.

If the items have had the archive bit reset then setup a DTRACE of the storagefilewatch process and restart the storageservice. This should trigger the post processing thread and then you will either need to look through this and see if there is anything obvious in there or open a case with support for analysis