Backup Exec 20.1 Best Practices
- Backup Exec Best Practices
- Best practices for Backup Exec software encryption
- Best practices for Backup Exec installation
- Best practices for Backup Exec tape management
- Best practices for Backup Exec disk-based storage
- Best practices for Backup Exec data lifecycle management (DLM)
- Best practices for Backup Exec catalogs
- Best practices for Backup Exec backups
- Best practices for Backup Exec backing up critical system components
- Best practices for Backup Exec Agent for Microsoft Exchange Server
- Best practices for Backup Exec Agent for Microsoft SQL Server
- Best practices for Backup Exec Agent for Linux
- Best practices for Backup Exec Agent for Microsoft SharePoint
- Best practices for Backup Exec Central Admin Server Option
- Best practices for Backup Exec Agent for Oracle on Windows and Linux Servers
- Best practices for Backup Exec NDMP Option
- Best practices for Backup Exec reports
- Best practices for Backup Exec and Veritas Update
- Best practices for Backup Exec Simplified Disaster Recovery
- Best practices for Backup Exec Agent for Enterprise Vault and the Backup Exec Migrator
- Best practices for Backup Exec Granular Recovery Technology
- Best practices for Backup Exec Remote Media Agent for Linux
- Best practices for Backup Exec Agent for Microsoft Hyper-V
- Best practices for Backup Exec Agent for VMware
- Best practices for using Backup Exec with server clusters
- Best practices for Backup Exec Deduplication Option
- Best practices for using Backup Exec Deduplication Option with the Central Admin Server Option
- Best practices for using hot-pluggable devices such as USB devices in a drive rotation strategy
- Best practices for Backup Exec database encryption keys
- Best Practices for Using the Veritas Backup Exec Cloud Connector
Best practices for Backup Exec 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 Administrator's Guide.
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.
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 restore Exchange more easily if you don't have to restore the Active Directory first. Also, it may add rights to the Exchange Trusted Subsystem account.
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.
You must have local administrator rights on each node of a database availability group (DAG) and on the Microsoft Exchange mailbox server to back up and restore Microsoft Exchange database files.
For Exchange 2010/2013, use a Database Availability Group (DAG) with at least one passive database copy for each database to protect against data loss. If you can make more than one passive copy, the second passive copy should use a log replay delay of 24 hours.
Divide user mailboxes between two or more exchange databases according to the Microsoft Exchange Capacity Planning Guide.
Keep moderate-sized Exchange databases; if databases are large, backup times may increase.
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. Exchange 2007 and later does not support individual mailbox backup.
Veritas recommends that you do not send an incremental GRT-enabled Exchange backup to a deduplication disk storage device. The transaction logs contain primarily unique data that does not deduplicate well. For best results, create a backup definition that runs a full backup of Exchange to a deduplication disk storage device, and then runs an incremental backup to a disk storage device.
Change your default staging location if you run GRT-enabled backup jobs. The default location is used for recovery as well as staging GRT-enabled restore jobs. You should change the location to a volume that is not your system volume for faster performance.
You should have less than 75,000 transaction log files for GRT-enabled backups. If you have more than 75,000 transaction log files, it may increase the amount of time that it takes to complete the backup job.
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.
For Exchange 2010/2013 DAGs that have three or more copies of the database, the consistency check can be disabled.
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. You can also use the Recovery Storage Group feature in Exchange 2007 or Exchange 2010 or later recovery database 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.
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:
Ensure that the recovery server is in the same Exchange forest as the original server.
Ensure that the Exchange server uses the same version of Exchange with the same service pack level or higher as the original server.
If you redirect the database to another database name, you must use a database name that is different from the name of the source database for Exchange 2010 or later. Also, an empty database must already exist on the target server with the option to allow overwrites enabled.
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.