How to use a trigger file (IgnoreArchiveBitTrigger.txt or PartitionSecuredNotification.xml) for devices that do not support the Archive bit
|Article:TECH35610|||||Created: 2004-01-19|||||Updated: 2013-05-10|||||Article URL http://www.symantec.com/docs/TECH35610|
When the Vault Store property is set to Remove Safety Copies: After backup, Enterprise Vault (EV) does not remove safety copies until the partition that contains the archived items has been backed up. By default, Enterprise Vault determines that an item is backed up when the archive bit on the file is reset. In order to use devices that do not support the use of an archive bit, or backup software that does not reset the archive bit, Enterprise Vault can alternatively check for a trigger file to determine whether the files in a vault store partition have been secured. Enterprise Vault 8.0 and higher supports two trigger file methods, PartitionSecuredNotification.xml and IgnoreArchiveBitTrigger.txt.
Enterprise Vault first checks each partition for a trigger file named PartitionSecuredNotification.xml. If it is present, and contains valid XML data, all the partition's saveset files that were created before the date in the file are considered backed up. If Enterprise Vault does not find PartitionSecuredNotification.xml, it then checks for a text file that is called IgnoreArchiveBitTrigger.txt. If this file is found, all the partition's saveset files that were created before the creation of IgnoreArchiveBitTrigger.txt are considered backed up. In both these cases, Enterprise Vault is then free to remove the safety copies that correspond with the secured saveset files, and to create shortcuts if appropriate.
Note: When Enterprise Vault finds PartitionSecuredNotification.xml but it is in some way invalid, it does not search for IgnoreArchiveBitTrigger.txt. It logs an event to show that the partition is not secure.
If neither file is found, Enterprise Vault considers that the partition is not backed up, and safety copies are not removed. The storage service also logs an event to show that no trigger file has been found.
Whichever trigger file Enterprise Vault finds, a valid PartitionSecuredNotification.xml or IgnoreArchiveBitTrigger.txt, it renames the file with a .old extension to show that the file has been processed and that the relevant files on the partition are secure.
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 setting a scan interval for the partition, Enterprise Vault checks the partition at intervals determined by the values set.
Although the trigger file mechanism cannot be used 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 the scan interval is set for the Centera partition, Enterprise Vault checks the partition at intervals determined by the value set.
Configure Enterprise Vault to look for the trigger file:
- PartitionSecuredNotification.xml (Enterprise Vault 8.0 and higher)
- IgnoreArchiveBitTrigger.txt (All Enterprise Vault versions)
<?xml version="1.0" encoding="utf-8" ?>
<VendorName>required free form string</VendorName>
<VendorAppType>required free form string</VendorAppType>
2. The IgnoreArchiveBitTrigger.txt needs to be created for each partition.
ECHO OFF > "E:\Enterprise Vault Stores\FSAArchiving Ptn2\ignorearchivebittrigger.txt"
ECHO OFF > "E:\Enterprise Vault Stores\MailArchiving Ptn1\ignorearchivebittrigger.txt"
del "E:\Enterprise Vault Stores\FSAArchiving Ptn2\ignorearchivebittrigger.old"
del "E:\Enterprise Vault Stores\MailArchiving Ptn1\ignorearchivebittrigger.old"
Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.
Article URL http://www.symantec.com/docs/TECH35610