• Facebook
  • RSS Feed
  • Instagram
  • LinkedIn
  • Twitter
Jul 142013

IMG_20120824_135308From time to time it happens that your Vault Store partitions might get almost completely full. As we’ve seen Enterprise Vault has a number of protection mechanisms in place which try to prevent the situation where the partitions become 100% full. These are similar mechanisms to the ‘old’ Exchange reserve log files, and try to ensure that the services remain in a good state, rather than just crashing when the space is completely consumed.

But, when you’re getting very close to the maximum size of your vault store partitions, what is there that you can do?

The first port of call is that you can create a new partition and close the current one. This will prevent more data being written to the current partition.

Another option would be to do the same, but, also enable and run collections on the now closed partition. But sometimes this isn’t desirable because the data that is on the partition is still actively used by end-users – so if that’s the case there isn’t much point in doing collections to reduce any space usage, because the CAB files will constantly being extracted back to the originals.

Yet another option is that you can create a new Vault Store, and a new underlying partition, and then create new archives for new users on the new vault store. Of course doing this will mean that the old vault store will grow over time, because the users there are still active.

In fact all of these options don’t actually reduce the size of the current data spread on to the Vault Store partitions.

The ‘cure’ for that is to use something like the native Enterprise Vault ‘Move Archive’ utility or a third party product like Archive Shuttle from QUADROtech to move some of the existing mailbox archives to the new Vault Store.

Yet another caveat of going the new vault store route is that what you will get back in terms of space is very much dependent on the sharing level within the vault store group. If sharing is enabled across the group, then having another vault store in the same group, and moving archives to that vault store will mean no storage gain – this is because the data in the new vault store is just referencing back to the existing one — because of the sharing level.

If sharing is enabled across the vault store group, and you don’t want to change that, then the remaining option is to create a new vault store group, a new vault store, and then a new partition … finally you can then move the mailbox archives using the ideas provided above.

A secondary question which comes up when data is moved to a new vault store is what happens with the existing shortcuts in the mailbox? Well, those will be rewritten by the utilities that I mentioned to point to the new location.


If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>