Using the trigger file mechanism to determine whether a partition has been backed up

Some backup software clears the archive bit on files after backing them up. This attribute is visible as the File is ready for archiving option in each file's properties.

However, some backup software and other methods of securing data do not clear this attribute. In this case you must use the trigger file mechanism to indicate that data on each partition is secure.

The use of trigger file mechanism would be necessary in the following examples:

You take snapshots of the partition to secure its data.
You use backup software that does not clear the archive bit, such as Tivoli Storage Manager (TSM).
You take differential backups, which clear the archive bit only when a full backup occurs.

Note:

You must ensure that your backup scripts do not create a trigger file unless the backup has completed successfully.

The Check for a trigger file option determines whether the files in a vault store partition have been secured by checking for a trigger file called IgnoreArchiveBitTrigger.txt. At each backup, your backup software or script must place a newly created IgnoreArchiveBitTrigger.txt in the root of the partition to show that a backup has taken place.

For example, if you have a vault store called "Sales", and you have placed its partitions in E:\EVStorage, you might have a partition folder called E:\EVStorage\Sales Ptn1. In this case, your backup software or script must place IgnoreArchiveBitTrigger.txt in E:\EVStorage\Sales Ptn1 to indicate that it has backed up the partition.

Note:

It is essential that your backup script creates a new IgnoreArchiveBitTrigger.txt file when it backs up a partition. It is not sufficient to rename another file because its file creation date does not match the time of the backup.

For example, you can use the following command in your backup script to create a new file:

echo "Enterprise Vault trigger file" > "E:\EVStorage\Sales Ptn1\IgnoreArchiveBitTrigger.txt"

When Enterprise Vault finds IgnoreArchiveBitTrigger.txt, all the partition's saveset files that were created before the creation of IgnoreArchiveBitTrigger.txt are considered backed up. Enterprise Vault is then free to remove the safety copies that correspond with the secured saveset files, and to create shortcuts if appropriate.

If Enterprise Vault does not find IgnoreArchiveBitTrigger.txt, it considers that the partition is not backed up, and safety copies are not removed.

When Enterprise Vault has completed the removal of safety copies, it renames IgnoreArchiveBitTrigger.txt with a .old extension to show that the file has been processed and that the relevant files on the partition are secure.

At the next backup, your backup software creates a new IgnoreArchiveBitTrigger.txt.

Enterprise Vault checks partitions for a trigger file when the storage service starts and when backup mode is cleared from a vault store. Additionally, if you set a scan interval for the partition, Enterprise Vault checks the partition at intervals determined by the value you set.

Although you cannot use the trigger file mechanism on Centera partitions, Enterprise Vault queries the Centera API to determine whether or not a partition has been replicated. Enterprise Vault checks Centera partitions when the storage service starts, and when backup mode is cleared from a vault store.

Additionally, if you set a scan interval for the Centera partition, Enterprise Vault checks the partition at intervals determined by the value you set.