Where WORM storage is not a requirement and HP StoreAll Storage devices are deployed, then the archive data is still subject to the normal requirements for backup. Enterprise Vault requires that archived data be verified as backed up before shortcutting can occur. The archive data must, therefore, be backed up once a day or replicated to a secondary HP StoreAll Storage device (requires custom scripting).
It is obviously not practical to back up the entire archive every day, so Enterprise Vault allows you to setup “partition rollover.” This ensures that only the active partition requires daily backup, closed partitions can then be backed up less frequently.
The recommendation is to do partition rollover on a monthly basis. Once a partition is closed, very little changes. The main changes are periodic deletions. Because very little changes and no new data are added, it is quite safe to backup closed partitions on a reduced schedule such as once a month. The exact details of the backup schedule must be tailored to the needs of the individual customer. The active partition must be backed up daily. A full backup of the active partition should be done once a week and incremental backups done at least once a day.
When running an Enterprise Vault backup, a script must be run to put the indexes and archives in a “read-only” state.
A sample script is provided in the implementation guide and Enterprise Vault provides a CScript tool to automatically generate a backup script for your environment.
It is essential that the backup script is used prior to and after a backup. The act of putting the archives back into read or write mode is what initiates the shortcutting process.
Technology specifications
To ensure a backup of Enterprise Vault, administrators must backup the original deployment install directories and file sets, as well as other critical components, such as MSMQ, IIS, SQL Server, and Exchange.
To backup and restore Enterprise Vault server and data, any backup tool (for example, HP Data Protector) that has the possibility to backup open files can be used. It is set up with multiple jobs in a cyclical schedule to back up parts of the server and data.
Microsoft SQL Server 2008 R2 comes with the built-in ability to do an SQL Server online backup of its databases and save a copy of them as flat files to disk (for more information, see msdn.microsoft.com/en-us/library/ms175477(v=SQL.105).aspx).
A backup solution backs up the copy. A special online database backup utility or module is only required if there is not enough free disk space to use the SQL Server copy option. In this release of M&C Archiving, only the built-in SQL Server backup technology is in scope.
Requirements and assumptions
The following requirements are needed for the backup and recovery solution:
• The daily incremental backups for Enterprise Vault (index) data must fit within a maximum of 4-hour backup window to ensure that there is enough time for the archiving process.
• The daily incremental backups of the active archive partition (in HP StoreAll Storage deployments) must fit within the
• In a customer site deployed solution, the customer is responsible for providing hardware or software backup similar to that provided by HP Backup and Restore Services.
• Backups are estimated using maximum size and network availability. If a customer exceeds maximum size or network experiences latency, required times cannot be met. This is not expected to occur in normal use.
The HP M&C Archiving backup and recovery solution assumes the following:
• A Gigabit Ethernet NIC cards are included on all Enterprise Vault servers. It is attached to a dedicated backup network.
• There is no other traffic on the Gigabit Ethernet backup network other than the backup traffic during the Enterprise Server backup.
• The backup strategies and technology may change to allow faster backups in the future.
Required actions for backing up Enterprise Vault application
If NetBackup is the backup solution in use, then its agent for Enterprise Vault should be used. NetBackup agent for Enterprise Vault interfaces with EV and automates the read-only state.
Due to the inability of the Enterprise Vault index’s structure to remain in their normal production (read or write) state during backup operations, it is required that a pre-backup script is run to place all the EV indexes and archive data in a read-only state.
If end users have manual archive functionality, and when they run it while the EV Services are in read only mode, the item is placed onto an MSMQ queue and are processed once the EV services are placed back into “normal” mode.
After successful backup, the EV indexes and storage can be placed back into read or write state. To perform these steps, use the appropriate scripts.
We recommend using the provided Symantec PowerShell script to generate the backup script. Details of the script and how to use it are found here symantec.com/business/support/index?page=content&id=TECH66742.
For more details on Enterprise Vault backup, you can also refer the Enterprise Vault 10.0.2 Administrator's Guide at symantec.com/business/support/index?page=content&id=DOC5980.
Additional index backup
In situations where the index data is critical (for example, journal indexes where frequent discovery searches are taking place), it is recommended to maintain a copy of the indexes on local “cheap” SATA disks. Using the four available drive bays and 1 TB SATA disks, it is possible to provide up to 3 TB for index copy if using RAID 5. The copy must be made with Robocopy and a schedule task. This basic copy of the indexes is in addition to the normal tape backup and provides a simple means of doing a fast restore of a corrupted index.
Data type backup usage and retention rules Warning!
1. The vault indexes backup retention period must either be equal or be older than backups of the related EV SQL Server databases.
2. It is critical to have the most up-to-date backup of SQL Server databases. Or, permanent data loss can occur.
3. SQL Server database backups can only be used if they contain all the archive data storage location entries.
4. Using a backup source that does not contain all these entries results in a permanent irretrievable loss of data within the archive. All data that was stored in the archive after the SQL Server database backup was generated is the data that is permanently lost.
Restoring aged backups results in permanent archive data loss. To ensure that this does not occur, use only backups that result in restoring all archive storage location entries.
Maximum backup retention period
Due to above defined functional restrictions on index and SQL Server database backup usability, retention of these backup can be for a maximum of one backup cycle. In this case, a backup cycle is the time between creation of full (complete) backups. When a full backup is made, continuous incremental or complete differential backups must be retained until a new full backup is created. As soon as the new full backup is created, all previous backup sets are no longer useable, since if they were selected for a restore effort, key SQL Server metadata databases entries are not included; these missing entries result in permanent loss of a portion of previously archived data.
SQL Server database backup
As with any SQL Server database, it is important to have a daily backup plan in place and to monitor the amount of space allocated to the databases. Backups should be done in full recovery mode, with incremental log backups.
Enterprise Vault SQL Server databases to be backed up:
• Enterprise Vault Directory database
• Enterprise Vault Store databases
• Enterprise Vault Fingerprint database
• Monitoring database
• Auditing database (when used)
• Discovery accelerator configuration database (when used)
• Discovery accelerator Custodian Manager database (when used)
• Discovery accelerator customer databases (when used)
The following backup schedules are recommended for SQL Server databases and transaction logs:
• Back up the Directory database nightly. Additionally, back up the directory database after any configuration changes, to ensure that all services function correctly after recovery. In particular, back up after a new Enterprise Vault service or task is added.
• Perform a full backup of all vault store databases daily after the main run of the Exchange Mailbox task using a SQL Server maintenance plan.
• The daily full backup of SQL Server must be coordinated to occur during the time period when the EV services are in read only mode.
• Backup monitoring database nightly.
• Backup the transaction logs from journal archiving vault store databases at least every hour to ensure that the SQL Server database backups contain all the archive data storage location entries (For more information, see Data type backup usage and retention rules section).
• Backup all system databases, especially Master and MSDB daily.
Truncate the transaction logs after all the backups.
Enterprise Vault SQL Server databases must participate in regular maintenance plans, including re-indexing.
For more information on best practices for SQL Server backup, check:
• HP white paper at download.microsoft.com/download/7/b/1/7b17fc16-444f-4ccd-af90-edb378da8831/hp_whitepaper_sqlL.pdf
• Microsoft guide at msdn.microsoft.com/en-us/library/ms191455(v=SQL.105).aspx Data protection—backup
To safeguard the operational viability of the email archive services, minimally the following solution elements require redundancy or backup. Backup is accomplished employing standard HP data protection services:
• Operating system on archiving and SQL Servers
• Perform a full system and file backup, including system state and registry
• Archiving application software on archiving server
• SQL Server application software on the SQL Server (For more information on SQL Server databases and transaction logs backup, see SQL Server Database Backup section)
• Index service file locations
The following backup schedules are recommended:
• Backup operating system on Archiving and SQL Servers, archiving application software on archiving server, and SQL Server application software on the SQL Server at least weekly.
• Backup index service and shopping service file locations daily incremental after the main run of the Exchange Mailbox task and run a full backup on every weekend.
• All backups must be so timed as to minimize customer impact even though the backup activities can be run without interrupting users’ access to archived data (read-only access is still possible).
Operating systems
Standard centralized backup utilities such as HP Backup and Recovery (HP BuR), which is already deployed is used to protect the archive and SQL Server operating systems.
Archiving application software
Standard centralized backup utilities such as HP BuR, which is already deployed is used to protect the archive server Enterprise Vault application software.
SQL Server application software
Standard centralized backup utilities, such as HP BuR, which is already deployed is used to protect the MS SQL Server 2008 R2 Standard application software.
SQL Server databases
Data protection for the Microsoft SQL Server 2008 R2 databases are managed by the HP SQL Server Database Support Group. Their recommended methodology and processes, including the rules from data type backup usage and retention rules section are followed.
Indexing and indices
Indices are created and maintained to support the search capability within Enterprise Vault. Although these index files can be recreated, it is time consuming, so backups are recommended. It is important to understand that the archive SQL Server databases and the search indices work together and require point-in-time synchronization in the case of backups or restoration.
HP StoreAll archived data
Standard centralized backup utilities such as HP BuR, which is already deployed is used to protect the archive server and Enterprise Vault application software.