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-05-02  |  Article URL http://www.symantec.com/docs/TECH35610
Article Type
Technical Solution


Issue



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 of these cases, Enterprise Vault will remove the safety copies that correspond with the secured saveset files and will create shortcuts if appropriate.

Note: When Enterprise Vault 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, Enterprise Vault 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 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. In addition, if the Vault Store partition has been configured for a scan interval, Enterprise Vault checks the partition at intervals determined by the value set.

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.


Solution



Configure Enterprise Vault to search for the trigger file: 

  1. Open the Vault Admin Console (VAC).
  2. Expand Vault Store Groups.
  3. Expand each Vault Store group.
  4. Select the appropiate Vault Store.
  5. Right-click on the appropriate Vault Store partition and go to Properties.
  6. Select the Backup tab, enable Check for a trigger file and choose the appropriate scan interval time.
  7. Click OK to save the settings.
  8. Restart the Enterprise Vault Storage service to update the new settings. 
     

 

Select from one of the options below to enable the trigger file.
 
PartitionSecuredNotification.xml
 
The PartitionSecuredNotification.xml file is created by the backup software, not by Enterprise Vault. If the file does not exist Enterprise Vault will look for the IgnoreArchiveBitTrigger.txt file.
 
The following XML shows a valid example of the content in PartitionSecuredNotification.xml:
 
<?xml version="1.0" encoding="utf-8" ?>
 
<PartitionSecuredNotification
 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 
xsi:noNamespaceSchemaLocation="PartitionSecuredNotification.xsd">
 
<VendorName>required free form string</VendorName>
 
<VendorAppType>required free form string</VendorAppType>
 
<PartitionSecuredDateTime> 2008-03-25T09:30:10+05:30 </PartitionSecuredDateTime>
 
<VendorTransactionId>optional string</VendorTransactionId> </PartitionSecuredNotification>  
 
IgnoreArchiveBitTrigger.txt
  1. 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.
    1. Open the Vault Admin Console.
    2. Expand Vault Store Groups
    3. Select the appropiate Vault Store.
    4. Go to the properties of the Partition.
    5. On the General tab will display the path.
  2. The IgnoreArchiveBitTrigger.txt needs to be created for each partition.
  3. 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.

    For example:

    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. 
 
Using pre and post scripts
 
  1. 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"
     
  2. Pre-backup script will set all EV Vault Stores (and Indexes locations) in backup mode (read only mode).
  3. Backup job will run.
  4. Post backup script will create a new IgnoreArchiveBitTrigger.txt file.
  5. Post backup script will clear all EV Vault Stores (and Indexes locations) from backup mode.
  6. Storage service will check for a trigger file and rename the file to IgnoreArchiveBitTrigger.old.
 
For Enterprise Vault installations in Windows Server 2008 Cluster
 
For Enterprise Vault installations in Windows Server 2008 Cluster, refer to the following technote:
 
How to use the IgnoreArchiveBitTrigger.txt file with Enterprise Vault (EV) 8.0 and later in a Windows Server 2008 Cluster
http://www.symantec.com/docs/TECH142943
 
 
For Enterprise Vault 2007 and below
 
For Enterprise Vault 2007 and below, it is required to enable the use of the trigger file via the Registry, rather than the Properties of the Vault Store partition. Create the following Registry value:
   
FileWatchEnableIgnoreArchiveBit
   
This is a DWORD value registry key created under:
 
For Windows Server 32-bit:
HKEY_LOCAL_MACHINE\SOFTWARE\KVS\Enterprise Vault\Storage
 
For Windows Server 64-bit:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Storage
 
When set to 1, this Registry key enables the StorageFileWatch mechanism described above.

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.

 




Legacy ID



273151


Article URL http://www.symantec.com/docs/TECH35610


Terms of use for this information are found in Legal Notices