Best practices for Backup Exec 12.5 Agent for Microsoft Exchange Server

Best practices include tips and recommendations to help you use the Exchange Agent effectively. For more information about the Exchange Agent, see the Backup Exec for Windows Servers Administrator’s Guide.

For best practices on preparing the Exchange Server for backup, do the following on the Exchange Server:

• Circular logging must be disabled if you want to do the following:

  • Run incremental and differential backups.

  • Recover data up to the point of failure.

  • Run continuous backups of Information Store transaction logs.

• Put transaction log files on a separate physical disk from the database. If the disk that contains the database is damaged, the transaction logs are available as a recovery resource.

• Set the retention period for deleted items and mailboxes to a length of time that is appropriate for the available disk space. The longer the retention period, the more disk space is required. However, some retention period can prevent you from having to restore a mailbox or database. If possible, configure the Exchange server so that items are not deleted until a full backup is performed.

• Make Write Cache unavailable on the SCSI controller. Data corruption can occur if the computer fails before the operation is written to disk.

• Monitor the Application, Security, and System logs for any relevant events that may affect Exchange Server functionality.

• Allow sufficient disk space for maintenance and recovery procedures. Refer to your Microsoft documentation for details.

• Document the Exchange server configuration in detail.

• Avoid making the Exchange server a domain controller. You can more easily restore Exchange if you don't have to restore the Active Directory first.

• Install the Exchange Server into a domain that has at least two domain controllers. With two domain controllers in a domain, databases on a failed domain controller can be updated with replication.

• For Exchange Server 2000/2003, ensure that the latest version of the Esebcli2.dll file is installed. If the Esebcli2.dll file is installed in more than one location, ensure that all locations contain the latest version.

The following best practices are for backing up Exchange Information Store data:

• When you run full backups, enable the option for Granular Recovery Technology (GRT). The GRT option lets you restore individual mail messages and folders from a database backup without the need for a separate mailbox backup.

  Note:
  For information on best practices for Backup Exec Granular Recovery Technology (GRT) with an Exchange Information Store backup, refer to the Granular Recovery Technology Best Practices.

• Ensure that the scheduled maintenance for the Information Store does not run at the same time as the database backup. If you run these operations at the same time, it can cause issues with the Exchange Server databases.

• Run Exchange backup jobs separately from other backup jobs.

• Back up the Active Directory on a regular basis.

• Run a regular backup for System State and Shadow Copy Components, if applicable. These selections back up the Internet Information Service (IIS) metabase and the Windows registry.

• Run a backup after you make any changes to system settings or application settings.

• When you run offline backups, back up all of the files that make up the storage group, including any .Edb and .Stm files, and all transaction log files.

The following best practices are for using the Backup Exec continuous protection feature as part of your backup strategy:

• Back up only one Exchange server for each continuous backup job.

• Create a separate selection list for each Exchange server resource.

• To copy backup sets to tape for off-site storage, create a job to duplicate backup data. You can schedule the job to copy the backup data to tape before or after each occurrence of the full backup job. The duplicate backup data job copies all of the transaction logs and the full backup sets to tape.

• If you duplicate Information Store backup data to tape and then back to disk, specify the same volume for the full and the incremental backups. The backup data must be on the same volume if you want to restore individual items from the incremental backup.

• Create a custom filter to limit the number of recovery points that appear in the Job History view.

• After you create and run a CPS Exchange backup job, do not change which backup-to-disk folder that it was run to. If you must specify a different backup-to-disk folder, create a new CPS Exchange backup job with a new backup-to-disk folder as the destination device. Delete the previous job.

The following best practices are for backing up individual mailboxes and public folders if you cannot use Granular Recovery Technology (GRT):

• Use the Exchange System Manager utility to adjust the deletion settings in the properties for each Information Store. Retain deleted items for a period of time so that you can recover the items rather than restore them. Refer to your Microsoft Exchange Server documentation for details.

• Perform all individual mailbox and public folder backup operations as separate jobs to isolate potential problems and recover data more quickly.

• Enable single-instance backup for message attachments.

• For Exchange 2000/2003, ensure that the most current versions of the Cdo.dll and Mapi32.dll files are in the Exchange directory \bin or \System32.. For Exchange 2007, when you install the Messaging Application Programming Interface (MAPI) and the Collaboration Data Object package, these files are installed in the \SysWOW64 directory.

• Run full backups of mailboxes or public folders on a regular basis. Supplement the full backups with incremental or differential backups to keep backup run time to a minimum.

• Do not substitute mailbox backups for backups of the entire Information Store. Continue to back up the Information Store. You cannot perform a complete restore of the Exchange server from a mailbox backup.

• Exclude unwanted or unnecessary folders and subfolders such as Deleted Items or Sent Items from the backup. When you create the backup job, use the Include/Exclude option to exclude these files.

• Do not back up the special system mailboxes that the Exchange server creates.

• Select public folders for backup from only one Exchange server to avoid backing up the same data multiple times. Most public folder data is replicated among multiple Exchange servers.

The following best practices are for recovering data for all versions of Exchange Information Store:

• Be aware of the effect of the Restore all transaction logs; do not delete existing transaction logs option. After an operation runs with this option enabled, transactions in existing transaction logs are applied when you start or mount the Information Store database. If those transactions include any deletions that occurred after the backup ran, those deletions are also applied. As a result, the very data that you intend to recover may be deleted. In this situation, enable the Purge existing data and restore only the databases and transaction logs from the backup sets option. This option discards the Exchange data that was generated after the backup. Alternatively, you can use a second recovery server, or the Recovery Storage Group feature of Exchange 2003 to perform the restore.

• If you must use the Microsoft Eseutil utility to repair the database, ensure that the recovery server has sufficient disk space. You may need as much as 125% of the actual size of the Information Store database. You can also specify another disk or volume as a temporary location on which to run the Eseutil utility. Refer to your Microsoft documentation for details.

The following best practices are for restoring data for Exchange Server 2000/2003:

• Ensure that you specify a valid temporary location on the Exchange server for log and patch files. The temporary location must have enough space to accommodate the transaction logs that you want to recover.

• Read the Restore.env file if issues occur when you mount a database after a restore operation. Information in this file can help you troubleshoot issues. To read the file, run the Eseutil utility with the /cm switch. Refer to your Microsoft documentation for details.

• Select the Commit after restore completes option when you configure a restore job so that the database can be mounted. Run the Eseutil utility with the /cc switch to perform a manual hard recovery. Refer to your Microsoft documentation for details.

• Ensure the following if you restore to an Exchange server other than the source server:

  • The recovery server is in a different Active Directory forest than the source server.

  • The recovery server has the same Organization and Administrative Group names as the source server.

  • The storage groups and databases already exist on the recovery server, and have the same names as the original storage groups or databases.

The following best practices are for restoring individual mailboxes and public folders:

• If you redirect the restore of individual mailbox or public folder items to an alternate location, ensure that the mailbox or public folder already exists.

• If there are problems with a restore operation, select specific mail messages for restore.

• If errors about permissions occur, try to restore to the mailbox that is associated with the Backup Exec logon account that you used for the restore. An example of a permissions error is Access denied.

• After a successful restore of public folders, you may need to rehome some or all of the folders. Refer to your Microsoft documentation for more information.

• If the error Unable to attach occurs, on the Exchange server, run Fixmapi.exe. Then, retry the operation.

• If you cannot attach to the mailboxes node when Outlook is installed on the Exchange server, then stop the Exchange and Remote Agent services. Run Fixmapi.exe, and then on the Microsoft Web site, look up any return codes. If there are no return codes, restart the services and retry the operation.

• If you redirect a mailbox restore to an Active Directory in a different forest than the Exchange server, you must associate an external account with the mailbox. Refer to your Microsoft documentation for details.

• If you redirect public folder data, ensure that the Backup Exec user account has the Owner role on both the source and destination public folders. Refer to your Microsoft documentation for details.

The following are best practices to plan for disaster recovery of an Exchange Server:

• Perform tests periodically to ensure that disaster recovery and data recovery scenarios produce the expected results.

• Become familiar with the Microsoft documentation for Exchange database management, disaster plans, and recovery.

• Document the Exchange Server configuration in detail. Document any subsequent changes. Note all hotfixes and service packs that are applied.