The Enterprise Vault Trigger File
Created: 06 May 2013 | Updated: 13 Nov 2013
One of the great features of Enterprise Vault is the ability for it to keep safety copies of data before they are removed from the archiving target. What this means in practice, when it relates to something like email in Microsoft Exchange is that the mail items aren’t removed from Exchange, until after they are ingested into Enterprise Vault AND backed up. This is added level of protection then against data loss, without it, there is always the chance that an email which arrives in a users mailbox today, gets archived this evening (before an Exchange backup takes place) and is then lost forever if the Enterprise Vault system suffers a disaster.
When it comes to the safety copy mechanism it’s a setting which can be configured on the properties of a Vault Store partition as shown below:
There are three different ways that the safety copy mechanism can be used to make sure that the files on disk have been backed up before the items are post processed (and turned in to shortcuts):
- Archive bit
- Trigger file (old style! – IgnoreArchiveBitTrigger.txt)
- PartitionSecuredNotification.XML (new style! – Introduced in Enterprise Vault 8)
The aim of this blog is to tell you a little bit about the trigger file mechanism – rather than to go into the pro’s and con’s of using one type of safety copy mechanism over another. Besides sometimes, as an Enterprise Vault administrator, you might not have a choice. The location your items are stored on, or the backup software that you use might not support one or more of the types of safety mechanism, therefore your ‘choice’ might be no-choice-at-all.
The trigger file has been in the Enterprise Vault product for a very long time, essentially it’s a file which needs to be created following the successful backup of items on the Vault Store partition. It is no use in just ‘copying’ or renaming or anything else that you might think of, for the file. Your post-backup routine must create a new file. It is the create date / time of the file which is used to determine which items to go through and post-process (it’s the storagefilewatch process that does this by the way).