Video Screencast Help

setting or clearing backup mode hangs

Created: 27 Sep 2013 • Updated: 17 Nov 2014 | 10 comments
This issue has been solved. See solution.

Been running the same backup script - pre + and post for several years and has been running successfully until... this week

Tracked down problem -

When trying to put the Vault stores into or out of Backup mode - the process hangs

either from powershell or from gui

from the gui - the message box reports:

"updating Vault Stores Backup mode..."

and there it stays

a look at the message queues - apart from the A5 - all else is zeros, no journaling is done

Placing the indexes into and out of backup mode works all okay

problem remains AFTER restarting the EV database server and EV server
no errors in event logs
by 'killing' the gui or powershell - shows the backup mode HAS changed - so I am guessing the there is some other activity as part of the setting or clearing the vault store backup mode that is causing the hang

Any thoughts ?

Operating Systems:

Comments 10 CommentsJump to latest comment

Pradeep_Papnai's picture

What is the version of EV in your environment?, Are you running SQL maintenance regularly, database should not be fragmented.

What's the size of JournalArchive & watch file for Vault store database?

Do you have any error/warning in event viewer?

mjscreen1's picture


we do not have journaling enabled

no sql maintenance is done - we backup the SQL databases and logs whilst in backup mode

There are no errors in the event log to give additional clues

Rob.Wilcox's picture

Have a look at the journal* tables in your Vault Store databases, have they got MANY, MANY rows?

mjscreen1's picture

Here ae the figures:




I see that journaling is different to Journal - hey ho - live and learn...

"Enterprise Vault 8 introduced a new feature called Transaction history. The Transaction history is used to determine how long to record updates to archives. Updates include adding new items, deleting items and moving items. The update records significantly improve the performance of vault cache synchronization by providing records of the changes to an archive since the last vault cache synchronization. If a user has not synchronized their vault cache within the transaction history period, then Enterprise Vault will process the archive to determine the updates."


Thank you for the maintenance clue

discovered the sql agent on the SQL server has been set to manual startup
last time the EVDBPlan was run April 2011

have started the EVDBPlan SQL job

will await progress of the job and review the row count in the journal* tables in the SQL vault store database 0
thank you

Rob.Wilcox's picture

Hopefully after some SQL maintenance it won't be too bad - you certainly don't have 'alot' of records in the journal* tables, so the slow down is likely to come from SQL.

John Santana's picture

So in this case, what is the recommended maintenance period for the EV with EVJournal enabled ?

Kind regards,

John Santana
IT Professional


Please be nice to me as I'm newbie in this forum.

mjscreen1's picture

The original problem has gone away - can stop and start the backup mode of the vault stores withou having to wait an excessive amount of time

Coming back to the number of rows in the Journal* tables within the database - these have not changed much

So I assume the reindexing done as part of the Symantec created maintenance job EVDBPlan helped.

I see the reindex part generates enough SQL transaction log entries to match the size of the vault store SQL databases - so we have increased the disk capacity of the drive holding the sql transaction logs.

Coming back to John Santana question above - recommended maintenace period - what I found on our server was that the job was set to run once a week -  or would have done if the SQL agent had not been diasbled :)

This is not a recommendation - it is an observation on our server - have not done any reading up on what is a good value

A_J's picture

The count in Journal delete will go down once the retain transcation history set under the site properties is over.

By default retain transaction history is set to 32 days.