Enterprise Vault Backup

[ph1llies05]

Hi all,

I was wondering if anyone out there has had any success configuring Commvault to backup EV vault store partitions and flip the archive bits in the archived data.  I'm a newbie to EV administration and have had little training and trying to configure our backups to flip the archive bits after we archive.  I'm not sure if this is something that is configured within Commvault or if I need to use the triggerfile in order for the archive bits to be flip.  Any info would be great, thanks

[JesusWept3]

The triggerfile is used when the backups cant remove the archive bits or if you are storing to a device that doesn't support archive bits (CIFS etc)....

So for instance if you are storing to a NetApp through a network share, when your backup runs, it will backup them up but it can't remove the Archive bit due to it not being supported, so the method would be to create an IgnoreArchiveBitTrigger.txt file in the root of the partition at the END of the backup, and then EV will assume all of the items have been backed up succesfully.

However on devices and NTFS drives that DO support the archive bits, its all dependent on the Backup software that you use, for instance Backup Exec and NetBackup will remove the Archive bit in certain backup modes (i.e Incremental vs Full backup etc)

[JesusWept3]

http://documentation.commvault.com/commvault/release_7_0_0/books_online_1/english_us/features/backup... the Archive Bit Attribute

[ph1llies05]

Hi JesusWept2,

Once again thanks for the reply, I was just reading the same exact document.  I'm about to check with my backup admin to see if he has this configured correctly for my Evault backups. 

I have one other question, I ran a Vault Store Usage Summary report and the report shows that I have several thousand messages awaiting backup.  My backup guys tells me that a incremential is being performed nightly and Diff on friday.  Is there anywhere in Evault where I can check if a vault store was properly backed-up?

[JesusWept3 · Accepted solution]

Well the way Enterprise Vault works is the following:

1. An item is archived in to Enterprise Vault
2. The DVS Files (which are basically copies of the messages) are created in the vault store partition
3. An entry is created in the JournalArchive table with a column called "BackupComplete" set to 0
4. Another entry is also created in a table called "WatchFile" which is the absolute path to that DVS file
5. When storage starts or every several hours the StorageFileWatch process scans each file in the WatchFile tabl to check if the item has been backed up, it does this by checking if the Archive Bit exists or not.
6. If the ArchiveBit does not exist then it deletes the WatchFile entry for that file and then sets BackupComplete to 1 in the JournalArchive table

If you are doing Exchange Mailbox Archiving for instance and you have your Safety Copies set to "After Backup" then an item will remain in the users mailbox as a "pending" item, which is the full message which archive details being stamped on it.

Once the item has been backed up, and Enterprise Vault scans it, removing the watch file entry and setting Backup Complete to 1, EV will then go and change the message from being Pending to a full shortcut, removing attachments, adding headers such as "This item has been archived by enterprise vault" etc.

In a scenario where you use the IgnoreArchiveBitTrigger.txt file, when StorageFileWatch scans the partition, it will find that TXT file and then go ahead and assume anything on or before the CREATED date of that file has been backed up. so each file it scans it will remove the WatchFile entry and set BackupComplete to 1

It is important to stress though that the Archive Bit Trigger file has to be created newly each time and cannot simply be copied.

So for instance if i create a file called IgnoreArchiveBitTrigger.txt on 03/25/2011, any items stored on that date time and before will be considered backed up by EV. After the process has finished it will rename it to IgnoreArchiveBitTrigger.old..... If then in a weeks time i rename it back to .txt from .old and then restarted storage, even though Enterprise Vault has detected it, any new items will not be considered backed up.

The reasoning being that its looking at the created date of March 25th and not for the items past that.
For this most people would use an ECHO command in a command prompt or batch file to create a new file.

Not intending to make this more complex, but Backups already rely on each part of a message being backed up before its considered "Secure"

Example:
You have two vault stores
Mail Store - Ptn1 -> E:\Vault Stores\Mail Store\Ptn1\
Jrnl Store - Ptn2 -> E:\Vault Stores\Jrnl Store\Ptn2\

You send an email out on 01/01/2011 with an attachment such as Sales.PDF thats 1MB in size
It gets Journaled in the Journal Archive to \Jrnl Store\Ptn2

Because its a large attachment it also gets an additional DVSSP (SIS Part) created, which is the attachment, so that anytime the PDF file is sent round, EV will find it already exists, and rather than store it in EV again, it will simply just link in the database to the existing DVSSP file.

Now lets say you have a 30 day archiving policy., so we then come to 1st February 2011.
The item in the users Sent Items gets archived to \Mail Store\Ptn1\, because the PDF file already exists as a DVSSP file in \Jrnl Store\Ptn2\ it doesn't create a saveset for that particular file.

So instead you have a small DVS file for the email the user sent, but the problem is even though you're backing up \Mail Store\Ptn1, the item remains pending in the users mailbox, the reason being that because \Jrnl Store\Ptn2\ isn't being backed up, the item isn't considered secure.

So you have to make sure that each vault store partition you share out with is getting backed up properly. In this instance because the message relies on that shared DVS File in another vault store, it cannot consider the full message backed up until that other vautl store has it backed up as well