Video Screencast Help

IgnoreArchiveBitTrigger.old is not being created

Created: 26 Oct 2012 • Updated: 15 Nov 2012 | 8 comments
This issue has been solved. See solution.

Hello, I'm backing up my EV Server with Veeam Backup, part of the scripting solutionI I have to reset the archive bit using the IgnoreArchiveBitTrigger.text file which will be placed in the root directory of the VS.

As per Symantec, this file should be converted to .old automatically by the RV Storage service, but this is not happening at all and I need to reset the archive bit of the .DVS files to be considered as backed up.

Discussion Filed Under:

Comments 8 CommentsJump to latest comment

JesusWept3's picture

What version of Enterprise Vault are you using?
where are you placing the .txt file?

habibalby's picture

In the directory of the VS e:\data\High\High VS ptn\

JesusWept3's picture

Actually testing it, it renames it to .old straight away, not right at the end.
You have configured the partition to look for the Trigger on the Backup tab, correct?

Here is the bit in the dtrace that you should look for.
So DTrace StorageFileWatch, restart the Storage Service and see what you get, you should see something like this 

1390 09:43:31.542  [3596] (StorageFileWatch) <4736> EV:L {CWatchFileTimer::CheckTriggerFileExists} (Entry)

1391 09:43:31.542  [3596] (StorageFileWatch) <4736> EV:L {CWatchFileTimer::CheckTriggerFileExists}|Trigger file E:\Vault Stores\Mail Vault\Ptn1\PartitionSecuredNotification.xml not found so searching for .txt file

1392 09:43:31.542  [3596] (StorageFileWatch) <4736> EV:L {CWatchFileTimer::CheckTriggerFileExists}|Trigger file E:\Vault Stores\Mail Vault\Ptn1\IgnoreArchiveBitTrigger.txt found

1393 09:43:31.542  [3596] (StorageFileWatch) <4736> EV:L {CWatchFileTimer::CheckTriggerFileExists}|PartitionSecuredDate = 2012-10-26 13:42:38 TZ|

1394 09:43:31.542  [3596] (StorageFileWatch) <4736> EV:L {CWatchFileTimer::CheckTriggerFileExists} (Exit)

1395 09:43:31.542  [3596] (StorageFileWatch) <4736> EV:L {CWatchFileTimer::QueuePeriodicScanRequest} (Entry) VaultStoreIdentity = [1] PartitionIdentity = [0]

habibalby's picture

Hello Jesus,

You have configured the partition to look for the Trigger on the Backup tab, correct?

I can't see the Backup Tab in any configuration in EV Console. Could you please elaborate on that?

JesusWept3's picture

Its on the vault store partition properties

GertjanA's picture

Also verify that the date of the triggerfile is the current date/time, and that you do not copy an existing triggerfile. In addition, is your script setting/clearing backupmode on Site or VaultStoreGroup/VaultStore?

If on Site, there is an issue with that. Try to use the VSG/VS, see if that works.

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS

habibalby's picture

Will verify the configuration of the Backup Trigger option if its configured.


I'm configuring it on the site level, I will try on the site, server and VS level and will report the result soon.


habibalby's picture


I found that option from this Tech Article, TECH35610

1. Open the Vault Admin Console (VAC)
2. Expand Vault Stores
3. Expand each Vault Store Group
4. Right-click on the appropriate Vault Store Partition and go to Properties
5. Select the Backup tab and check "Check for a trigger file" and choose the appropriate scan interval time
6. Click OK to save the settings.
7. Restart the EV Storage service so that the update is enabled.
I have enabled the Backup from Archive Bit to a trigger file for every 60 minutes and restarted the Storage Service.
I amended the scripts to include the Del "EvServer\VaultStore$\IgnoreArchiveBitTrigger.old" in the PreScript and echo OFF> "EvServer\VaultStore$\IgnoreArchiveBitTrigger.txt" in the PostScript.
After restarting the Storage Service, the file it converted to .old file and when I start the job from the Task Schduler the file gets deleted, "but I noticed it takes time to start other task which Sets the EV into Backup Mode"... Almost after 4 ~ 5 minutes, it I get the event triggered in the Event Viewer that the Backup Mode sets and the Backup Job on Veeam Server started. 
The issue has solved..
Any additional recommendations?