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: 2014-12-31|||||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, EV 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, EV can 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.
EV 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 EV 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 of these cases, EV will remove the safety copies that correspond with the secured saveset files and will create shortcuts if appropriate.
Note: When EV finds a PartitionSecuredNotification.xml that is somehow invalid or malformed, it does not go on to search for IgnoreArchiveBitTrigger.txt. Instead, it logs an event to show that the partition is not secure.
If neither file is found, EV considers that the partition is not secure, 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 EV 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.
EV checks partitions for a trigger file when the Storage service starts and when backup mode is cleared from a vault store. In addition, if the Vault Store partition has been configured for a scan interval, EV checks the partition at intervals determined by the value set.
Note: Partitions on EMC Centera, which does not support the Archive bit, also do not support the creation of trigger files. These partitions utilize the Centera API to test whether the partition data has been replicated. Enterprise Vault checks Centera partitions when the Storage service starts and when backup mode is cleared from Vault Store, as well as at the scan interval configured on the partition.
Configure Enterprise Vault to search for the trigger file:
- Open the Vault Admin Console (VAC).
- Expand Vault Store Groups.
- Expand each Vault Store group.
- Select the appropriate Vault Store.
- Right-click on the appropriate Vault Store partition and go to Properties.
- Select the Backup tab, enable Check for a trigger file and choose the appropriate scan interval time.
- Click OK to save the settings.
- Restart the Enterprise Vault Storage service to update the new settings.
- 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>
- Create an empty text file (using Notepad, or any other text editor) saved with ANSI encoding in the root folder of the Vault Store partition location. Follow the steps below to determine the path for each partition.
- Open the Vault Admin Console.
- Expand Vault Store Groups
- Select the appropriate Vault Store.
- Go to the properties of the Partition.
- On the General tab will display the path.
- The IgnoreArchiveBitTrigger.txt needs to be created for each partition.
- The backup procedure should be modified so that the IgnoreArchiveBitTrigger.txt is created with a current creation date. The command used to place the IgnoreArchiveBitTrigger.txt in the Vault Store must not retain the original creation date. Otherwise, DVS files created after the file date of the IgnoreArchiveBitTrigger.txt will not be processed.
Symantec recommends that the backup procedure should be modified so that the IgnoreArchiveBitTrigger.txt is created with a current creation date. Using the examples below in the post backup script will create a new IgnoreArchiveBitTrigger.txt.
ECHO > "E:\Enterprise Vault Stores\FSAArchiving Ptn2\ignorearchivebittrigger.txt"
ECHO > "E:\Enterprise Vault Stores\MailArchiving Ptn1\ignorearchivebittrigger.txt"
NOTE: If pre and post scripts mechanism is included in the backup job application, then IgnoreArchiveBitTrigger.txt creation should be placed before the clear backup mode lines in the script. The IgnoreArchiveBitTrigger.old file should also be deleted.
- Pre-backup script will delete the IgnoreArchiveBitTrigger.old file. For example:
del "E:\Enterprise Vault Stores\FSAArchiving Ptn2\ignorearchivebittrigger.old"
del "E:\Enterprise Vault Stores\MailArchiving Ptn1\ignorearchivebittrigger.old"
- Pre-backup script will set all EV Vault Stores (and Indexes locations) in backup mode (read only mode).
- Backup job will run.
- Post backup script will create a new IgnoreArchiveBitTrigger.txt file.
- Post backup script will clear all EV Vault Stores (and Indexes locations) from backup mode.
- Storage service will check for a trigger file and rename the file to 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