Exchange backup requirements and considerations

Recommendation	Description
Disable circular logging	This enables you to run differential or incremental backups of Exchange. If you do not disable circular logging, only full backups are supported. See Circular logging setting for more information.
Do not allow the physical or virtual machine hosting the Exchange server to be a domain controller	This enables much simpler and faster Exchange restores since you will not first have to restore Active Directory on the same server.
Make sure that the physical or virtual machine hosting the Exchange server is a member of a domain that has at least two domain controllers	This enables faster recovery. Active Directory information is replicated if there is more than one domain controller, which means that if one domain controller fails the other can be used to recover missing transactions after the failed domain controller is restored.
Separate transaction log files from the Exchange server database	Exchange performs much more efficiently if the Exchange database and transaction logs are placed on different physical storage devices. In addition, by separating these two important components, recovery of failed storage is eased.
Disable the write cache on any hard drive or RAID adapters being used in the system that is hosting the Exchange server	This prevents data corruption by ensuring that any Exchange write operation is committed to secondary storage (i.e., disk) correctly.

Automatic exclusion of application data during file-level backups

When you run file-level backups of the Windows server hosting Exchange, certain Exchange-related files are automatically excluded. For example, all transaction log files (i.e., .LOG files), the Exchange database (i.e., .EDB files), and streaming content files (i.e., .STM files) are excluded.

Using incremental backups

Exchange versions 2007 or higher can use incremental backups. Exchange incrementals offer the following benefits:

•

Incrementals can run more quickly and frequently than differentials since they include only the changes since the last successful full or incremental backup. This enables you to meet more aggressive RPOs than with differentials, which contain all changes since the last full backup.

•

Upon completion of a successful incremental, unneeded transaction log files are automatically truncated, freeing space on the Exchange server. Automatic log truncation does not occur with Exchange differentials.

When creating an Exchange job that includes incremental backups:

•

The same schedule cannot contain differentials and incrementals.

•

The schedule must contain a full backup. The Exchange job does not support the incremental forever strategy.

Circular logging setting

Circular logging is an Exchange feature that enables overwriting transaction log files. Unitrends recommends disabling circular logging. You must disable circular logging to run differentials or incrementals. If you enable circular logging, you can only run full backups. If you disable circular logging, the transaction logs are used to create differential or incremental backups.

•

With differentials, these transaction logs accumulate until a successful full backup runs.

•

With incrementals, unneeded logs are removed after each successful backup.

The removal of unneeded truncation logs is typically termed transaction log truncation. Transaction log truncation removes unneeded logs but does not reclaim space. Reclaiming space is a separate operation that must be performed periodically by the Exchange system administrator.

Microsoft snapshots

Unitrends leverages the Microsoft snapshot feature to protect Exchange. Our protection of Exchange with these snapshots is not supported for the following:

•

Any type of NAS configuration (SAN configurations are supported).

•

The Exchange 2003 Recovery Storage Group feature.

Protecting databases and storage groups

Unitrends protects databases and storage groups as follows:

•

Databases - For Exchange 2016, 2013, and 2010, you can back up multiple databases or a single database. Backups protect locally deployed databases only. Remote databases, such as Office 365 or Hybrid deployments, cannot be protected by Unitrends backups.

•

Storage groups- For Exchange 2007 and 2003, you can back up multiple storage groups or an individual storage group. You cannot back up individual databases within a storage group. The reason for this is the transaction logs for the entire storage group are backed up for each database selected. Thus a full backup must be run on every database in a storage group in order for the transaction logs to be properly handled for full/differential backups.

Protecting clustered Exchange environments

Unitrends supports protection of Exchange 2007 clusters in either CCR or SCR configurations and Exchange 2016, 2013, and 2010 in the DAG configuration.

Note: The Microsoft Exchange Replication Service must be running in order to protect the above cluster configurations.

Unitrends recommends adherence to the following best practices when protecting clustered Exchange environments:

•

Add each Exchange server node you wish to protect to the Unitrends appliance using its native server IP address. Do not use the cluster hostname/IP address used to access the active Exchange server.

•

Do not add the cluster hostname/IP as a separate asset.

•

Do not backup multiple copies of the same database simultaneously. Each full backup of an active or passive database results in database log truncation. The truncation of logs is replicated to the other members of the cluster where that database exists. If the same database is undergoing a full backup on two nodes, the log truncation of each could interfere with the other. To avoid this, schedule backup of replicated databases at staggered times across the cluster.

•

Backup only passive copies to reduce workload on the active server(s).