EnterpriseVaultPartitionRoot.xml

[shampoo]

I'm having slight problems with my triggerfile enabled backup. We're using a dummyfile IgnoreArchiveBitTrigger. It's not always renamed after our vault gets out of backupmode. Before investigating that problem I was wondering what these EnterpriseVaultPartitionRoot.xml files are doing in all of my partition directories. So if anyone can tell?

I thought it's related to partitionsecurednotification.xml. But its contents are only this:

<EnterpriseVault PartitionEntryId="2B4ADD80172BD5E5C8330FC54E0F1AEDF7310000VaultServer02" VaultStoreEntryId="1E9ADCA9AEC2E8330EB2A4AD39B0414D8F210000VaultServer02"/>

Besides that we're using that dummyfile IgnoreArchiveBitTrigger.

EV902 (backup Check for triggerfile enabled)
Dataprotector 6.2
 

[JesusWept3 · Accepted solution]

Those files were introduced in Enterprise Vault 9 and literally just notify the Storage Service which Vault Store and Partition that location belongs to.

There was an issue some time ago where you were able to put two partitions to the same location, and that could cause potential dataloss at worst, so this is just another attempt to bullet proof it so that you can't manually go in the database and make a mistake causing major issues

For example, say you have two vault stores and two  partitions

Mail Store -> Mail Store Ptn1 -> \\myFileServer\myShare\MailStorePtn1
Journal Store -> Journal Store Ptn1 -> \\myFileServer\myShare\MailStorePtn1

In this scenario both Partitions are going to the exact same location so in some cirumstances you may find that the Journal storage process  would go ahead and "clean up" its partition, but instead it would also be deleting items from the Mail Store incorrectly.

This was fixed in later service packs of 2007 by shutting the storage service down if it detected conflicting paths, it would also change the Vault Admin Console as not to be able to use the same path

This file is just ta further bullet proofing

What i would suggest if the file is not being renamed, just try getting a dtrace of storageFileWatch and see if its still scanning, try leaving the dtrace for a while, because if you go to the properties of the partition and click the Backup tab, it should have the "Scan partition Every" 60 minutes or something so you should be able to catch when its attempting to scan the partition and why its skipping the file

[GertjanA]

Is that in the manual/releasenotes/readme?

I had the same question, but thought it had to do with NBU.

There also is an issue of the IgnoreArchiveBitTrigger.txt not being renamed, but my guess is that that happens because one file is written to a closed partition, and the other to a ready one.

[JesusWept3]

its not in the release notes or readme or anything that i'm aware of, its insignificant really, i mean, the same way that DVS/DVSSP/DVSCC files aren't really referenced in the readme files either.

Get a dtrace of when the Partition starts to become scanned and you'll see what the SFW process is doing when it attempts to scan and read the file and such