Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Mail vaulted to partition on CIFS not committed

Created: 26 Nov 2013 | 15 comments

I recently moved my Exchange mailbox and Public Folder vault store partitions to CIFS shares.  Mail is getting vaulted but it's showing as not backed up yet, so it's still in that "in between" state in Outlook.  And I have a status alert in the VAC that

41261 It is more than 2 days since backup or replication was detected for one or more open partitions.
 

I'm getting the alert above for both my open partitions (Mail and Public Folder).

My CIFS shares are on a NetApp filer and I'm using SnapVault to backup my CIFS shares on a nightly basis.  I've verified that the snapvault snapshots are taking place and are successful, but EV doesn't seem to understand.  I'm running EV 9.0.4 R1 on a single Windows Server 2003 server.  My NetApp filers are ONTAP 8.0.x. 

I just found the "Backup" option for the partition.  It looks like I'm supposed to use the "Trigger" option.  There doesn't seem to be any configuration to do other than interval to check.  If I'm only backing up once per day, do I really need to check every hour?  Are there any back door config changes I need to make so EV will work better with our NetApp filers?

Any advice is greatly appreciated!

Operating Systems:

Comments 15 CommentsJump to latest comment

EV_Ajay's picture

1. Navigate to the Vault Store Partition root location (found on the General tab of the properties for the Vault Store Partition)

2. Check that the file "IgnoreArchiveBitTrigger.txt" has been created and has a recently modified date

If the file doesn't exist or has not been recently updated it would be advantageous to check that your backup solution is set to update the "IgnoreArchiveBitTrigger.txt" file.

Further IgnoreArchiveBitTrigger.txt creation information can be found at http://www.symantec.com/docs/HOWTO28116

Thanks,

Ajay

RhoSysAdmin's picture

I appreciate the quick response but the link you provided does not work for me. 

And the IgnoreArchiveBitTrigger.txt file has not been created (yet). 

Pradeep_Papnai's picture

Please refer Tech note http://www.symantec.com/docs/TECH35610, You need to create text file name with 'IgnoreArchiveBitTrigger.txt' in partition root, just put Vault store in backup mode & clear, It should then decrease the no of awaiting backup count.

MichelZ's picture

Hi there

EV does not integrate with NetApp / SnapVault.
You would need to manually create a script / program which checks your SnapVault Backups, and which create the Trigger file.

There is no out-of-the-box functionality.

GabeV's picture

Hi,

If you are using NetApp snapshots to backup the partition that means the backups are almost instantaneous. In the SnapVault post backup script, you need to add a line where (1) a new IgnoreArchiveBitTrigger.txt is created in the root of the partition and (2) the IgnoreArchiveBitTrigger.old file is deleted. Under the partition properties, select the second option 'Check for trigger file' and restart the Storage Service.

The 60 minutes scan verifies if a new IgnoreArchiveBitTrigger.txt file has been created. If it does, then StorageFileWatch scans the partition looking for new secured items. If you are running backups once a day, then 720 minutes would be fine (twice a day). However, if you are using powershell scripts (and you should) to set/clear backup mode every time you take a backup, then you don't need to enabled 'Set partition every: xxx minutes' since the partitions are checked when backup mode is cleared from the vault store.

I hope this helps.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

RhoSysAdmin's picture

We do use powershell scripts before and after our backups of the server.  However, I got the commands from a doc that Tech Support directed me to.  I've not done any powershell scripting before.  Anyone happen to have a sample I can work from?

GabeV's picture

For the PS scripts, you can follow this TN:

http://www.symantec.com/docs/HOWTO57222

The PS scripting is just a call to the EV powershell scripts:

%SystemRoot%\SysWow64\WindowsPowerShell\v1.0\powershell -psconsolefile "C:\Program Files (x86)\Enterprise Vault\EVShell.psc1" -command "& {set-vaultstorebackupmode -name 'Express Vault Store Group' -evservername EVserver -evobjecttype vaultstoregroup}"

and

%SystemRoot%\SysWow64\WindowsPowerShell\v1.0\powershell -psconsolefile "C:\Program Files (x86)\Enterprise Vault\EVShell.psc1" -command "& {clear-vaultstorebackupmode -name 'Express Vault Store Group' -evservername EVserver -evobjecttype vaultstoregroup}"

These are just two examples from the technote above. Also, you need to add something like this in your pre script:

del "E:\Enterprise Vault Stores\FSAArchiving Ptn2\ignorearchivebittrigger.old"

and this to the post script:

ECHO OFF > "E:\Enterprise Vault Stores\FSAArchiving Ptn2\ignorearchivebittrigger.txt"

You need to change the partition's path, Vault Store names, etc.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

RhoSysAdmin's picture

Thanks!  That's a big help.  One more question.  Do I need to do this trigger file for all partitions (open and closed) or just the open partitions?

I'm not snapshotting the closed partitions.  I've created one-time tape backups of them instead.  So is it ok to leave the closed partitions set to look at the archive bit and the open partitions to be trigger file based?

GabeV's picture

It depends. The trigger file mechanism is configured at the partition level. So, you can have some partitions with the trigger file and others with the archive bit. Of course, per best practices is better to have only one mechanism. If you choose the trigger file, then you need to create the txt file on each partition, including those that are closed.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

RhoSysAdmin's picture

Now I realize I have a new problem.  My backup software will not allow me to target two different servers in one job.  I backup the EV server (still w/ indexes and EV software,...) in one job and now a new backup via the NetApp filer using SnapVault.

How do I run pre and post batch files against my EV server based on the SnapVault schedule unless I just hard code a time to pre and post?  Is that acceptable?  I can just pick a wide window of time. 

<update>

Found this discussion https://www-secure.symantec.com/connect/forums/how-clear-awaiting-backup-item-count and now I'm reading http://www.netapp.com/us/library/technical-reports/tr-3635.html to see if this is a road I need to go down.

GabeV's picture

In the NetApp filer, you setup a schedule for snapvault transfers, thus you know at what time the snapshot will be created in the filer. NetApp snapshots are really fast and I don't remember seeing a 'snap create' command taking long time to complete, unless you don't have enough space in the aggregate. In that case, the backup might fail.

If you hard code the time to run the pre and post script, I don't think you would be an issue. However, you might need to create a script where you get a snap list from the filer and confirm if the snapshot was created successfully before creating the trigger file in the partition.

**update**

Looking at the Doc from NetApp, since you are running EV 9.0.4, you don't need to setup registry values or stop the services to set/clear backup mode. Instead, use the PS scripts. Also, you can run RSH commands in the same batch file to create the snapshot and force a snapvault update, but you might need to talk to your storage guys or NetApp people to confirm the syntax.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

RhoSysAdmin's picture

So I don't want to go too far down the NetApp road here, but I want to make sure I'm understanding you correctly.  The way I'm backing up the CIFS shared EV partitions is to take a snapshot of the hosting NetApp volume at 8:00pm.  This snapshot is nearly instant.

At 11:00pm, I use snapvault on a 2nd filer to transfer the "daily" snapshot on the source filer to itself (aka the 2nd filer), where I have a longer retention period for those snapshots.  This is obviously not instant, but it doesn't take that long (after the initial snapshot is taken). 

Is it the case that I can schedule my pre and post scripts around that 8:00pm nearly-instant snapshot on the source filer, or do I need to wait for the snapvault transfer to complete?

GabeV's picture

If at 11:00 PM you are transferring the daily snapshot that was taken at 8:00 PM, then yes: schedule the pre and post scripts around 8:00 PM since that would be the backup time, not 11 PM.

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill

RhoSysAdmin's picture

And now for the bonus question.  Before I moved my vault permissions to CIFS shares, in addition to my daily/weekly backup to tape, I was doing a monthly tape backup which was just a copy of the last weekly backup of the month.

Now that my vault store partitions are separated from the EV server, I need to create a monthly backup to tape of these CIFS shares.  The thing is I don't know how to tell my backup software (NetVault) how to run a pre and post script against a Windows Server (aka the EV server) that is not the NetApp filer I'm backing up.

You see, part of the motivation to move to CIFS was to decrease my dependency on tape backup.  The catch is that I'm not totally free of tape, although it's debatable what I gain from these monthly backups of the vault store partitions.  But I digress....

GabeV's picture

I guess that would a question for the NetVault support team. If this backup software can backup directly from the CIFS share, what if you use the ~snapshot directory and then the last daily snapshot? Just a  thought ...

“Success is not final, failure is not fatal: it is the courage to continue that counts.”–Winston Churchill