Video Screencast Help

EV vault stores and indexes backup mode question

Created: 05 Oct 2012 • Updated: 19 Oct 2012 | 7 comments
This issue has been solved. See solution.

Hi

Environment is EV 9.0.2

At the moment, we put indexes and vaultstores in backup mode for the duration of tape backups.

The downside to this is that some of the EV servers have massive indexes, so full backups can run for a long time, and the journal mailbox backs up significantly for this duration.

So I am considering removing the requirement for vault stores to be in backup mode during full backups (still leaving indexes in read only mode), and leaving vault stores and indexes in read only mode during incrementals.

Any caveats with this approach? Am I increasing risk to the environment?

Thanks

 

 

Comments 7 CommentsJump to latest comment

TonySterling's picture

Yes, you will be increasing risk as your backup won't be a true point in time you can restore to.  While it may be a minimal risk it is still a risk and really doesn't solve the problem of your backups taking too long.

You really should look at upgrading to EV 10.  In EV 10 you can close the index locations like you can for Vault Store Partitions.  This will allow you to better control the size of the Index locations to keep you backups running better.

goatboy's picture

Thanks Tony. Even if I upgrade to EV10, sounds like I am still stuck with the current massive indexes... So looks like I need to look at a faster backup solution.

TonySterling's picture

So if you upgrade to EV 10 and open new Index Locations you won't have to back up the closed partitions as often.  Also, as you upgrade the 32bit indexes to 64bit those old locations will decrease as new indexes are created in the open locations.

I think with a little planning you could more easily manage your backup times.  It is definitely worth a look.

best regards,

Tony

SOLUTION
Jeff Shotton's picture

Assuming that journal archiving is on its own server:

In the meantime you could close all the current open index locations and open a new indexing location (you dont want 8 - just another 1, so close or delete the extra locations that appear).  If you are archiving to a single journal archive then although you have 8 indexing locations, only one is effectively being written to at any point. Assuming you are doing a reasonably significant volume of journaling (say a million items a week) then you will likely have a new index volume created for the journal archive after a week or so. At this point it will roll over into the new open location, and your old locations will become read only.

There is generally not much point in having multiple OPEN index locations for journalling, especially when you are storing everything on the same SAN. You are better off controlling where the data is actively being written so you know which folder to back up.

You can then back them up less often because the indexes will effectively be static until storage expiry time (unless you are into deleting portions of the journal on occasion)

Regards,

Jeff

 

 

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

goatboy's picture

question, we have Centeras, so do I still need to put the vaultstores into backup mode while tape backups are running? I know I have to do this for indexes., why the vaultstores if I have Centeras?

GertjanA's picture

should be new question, but you need to put stores also in backupmode to prevent changes during backup.

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS
Company: www.t2.nl

www.quadrotech-it.com

www.symantec.com/vision

goatboy's picture

The "Symantec Enterprise Vault and EMC Storage Applied Best Practices" doco says "when archiving to EMC Centera, as opposed to any other storage device, it is not required to back up the vault store partitions."

The Centera is replicated, there are no tape backups so we can't restore from a point of time to it.

If I lose Exchange, or SQL, what advantage is there if the vault stores were in read only mode when tape backups of the EV servers were running?

thanks