Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Enterprise Vault 11 - Backing up Storage Queue Location

Created: 30 May 2014 • Updated: 09 Jun 2014 | 5 comments
ChayDouglas's picture
This issue has been solved. See solution.

Hi Guys,

Something I'm confused about is with Enterprise Vault 11 and the new Storage Queue Location - if we chose to use the Storage Queue Location for safety copies, these files need backing up, correct?

If this is the case, how does Enterprise Vault know that this location has been backed up?

Or does Enterprise Vault just automatically delete the files in the storage queue location as soon as the normal archive partitions have been backed up?


Operating Systems:

Comments 5 CommentsJump to latest comment

TonySterling's picture

Not sure if you saw these:

About the Storage queue

Article:HOWTO98318  |  Created: 2014-05-07  |  Updated: 2014-05-07  |  Article URL

How the Storage queue keeps safety copies

Article:HOWTO98319  |  Created: 2014-05-07  |  Updated: 2014-05-07  |  Article URL

 Doesn't seem like you need to back it up but it needs to be on a fault tolerant device.  After the partitions are backed up the items are removed from the storage queue.


ChayDouglas's picture

I was reading them, myself ,as well as Backing Up EV (April 2014) whitepaper and EV 11 Performance Guide. I think I agree that it just clears when the normal partitions back up. However, the back up programs with EV agents do not work with the Storage Queue Location.

I don't like the idea of the Storage Queue, but that's a separate discussion. Don't think I could recommend using it to customers.

JesusWept3's picture

well if you go to EV11, you have no choice, the Storage Queue is there to stay, you can't *not* use it.

ChayDouglas's picture

But we don't have to use it for safety copies, right?

Patti Rodgers's picture

You are not required to store Safety Copies in the storage queue. If you choose not to, your Storage Queue will function quite similar to how the MSMQ's Storage Archive queue does in EV10 and earlier, at least conceptually (although that is a bit over-simplified). Work will go in and go right back out.   You can go without safety copies at all or you can leave them in the source (usually Exchange).

The backup programs with agents do not need to work "with" the EVSQ. The EVSQ will take its cue from the database; when the partition is backed up (your normal storage partition), the database will be updated to reflect the status, and the EV processes will begin to clear he EVSQ accordingly. 

The obvious challenge/obstacle is around the storage requirements, but in the grand scheme of things a customer may decide this is not that big of a hurdle in light of the benefits returned.  For our Exchange journal archving customers, I see this as a huge step forward; in the past, customers have had to choose between storing safety copies in Exchange journals till the Vault Store Partition is backed up (very impractical in even moderate-volume journaling environments-- the Exchange journal will bloat by the end of even one day) or not having any redundancy.  If you did not keep safety copies in your journal, and you ran a good backup Tuesday night but then your SAN failed on Wednesday evening, that was a whole work day of data that might not be recoverable depending on how you had Exchange set up.  To be able to offload from Exchange immediately, yet still have two copies of the data in two different storage arrays until you confirmed you had a good backup, that's a huge win in my book.  

Plus for mailbox archviing, the ability for the users to have fully functional shortcuts (move, forward item, etc) immediately *and* see their mailbox size go down ASAP without waiting for backups is going to make for some very happy end users.

I'm  happy to be able to offer this to my customers.