NetVault Plug-in for Exchange 12.3 - User Guide

Differential Backups

Differential Backups back up the transaction log files that capture the changes made since the most recent Full or Incremental Backup. Differential Backups do not perform transaction log truncation, and therefore do not maintain the operating health of the Exchange Server.

Subsequent Differential Backups increase in size and in duration because each Differential Backup includes the transaction log files that were also included in the previous Differential Backup, and the transaction log files that have been generated since the previous Differential Backup. For example, if a Full Backup was taken on Sunday with Differential Backups scheduled for Monday through Saturday, Monday’s Differential includes the transaction log files generated since the Full Backup on Sunday, while Tuesday’s Differential includes the transaction log files generated on Monday and those files generated on Tuesday. Wednesday’s Differential includes the transaction log files for Monday, Tuesday, and Wednesday, and so on.

As with a Transaction Logs-Only Backup, a Differential Backup must always have a base backup, which is often a Full Backup. Performing a Differential Backup without first performing a Full Backup might lead to backup failures and prevent you from being able to restore and recover your Exchange Server properly.

When used with Full Backups, Differential Backups provide acceptable trade-offs with good backup performance, good restore performance, and reasonable overall database maintenance through the Full Backup.

Incremental vs. Differential Backups

Because Exchange Server truncates transaction log files after they are backed up in Incremental Backups, subsequent Incremental Backups are quicker. They are quicker because only the transaction log files that have been created since the last Incremental Backup are backed up. However, restore sequences that use Incremental Backups require that every Incremental taken between the Full Backup and the point of failure must be restored in succession. This process can result in longer restores due to the increased human intervention required to initiate the multiple restore jobs.

Differential Backups do not truncate the transaction log files after they are backed up. Subsequent Differential Backups take increasing longer because all the transaction log files since the last Full Backup are included in the backup. Nevertheless, restore sequences that use Differential Backups require that only one Differential Backup be restored after the Full Backup is restored. This process results in quicker restores because less human intervention is required during the restore process.

An extra consideration when deciding between Incremental and Differential Backups is the desired frequency of transaction log file truncation. When implementing Incremental Backups, the transaction log files are truncated by the Exchange Server at the same frequency as the Incremental Backups. For example, if Incremental Backups are performed daily, the transaction log files are truncated daily. However, with Differential Backups, the transaction log files are truncated only when a Full Backup is performed. Therefore, if the Full Backup is only performed weekly, the transaction log files are only truncated weekly.

Implementing a Differential Backup strategy leads to faster restores but also requires more frequent Full Backups to maintain the operating health of the Exchange Server.

Examples of backup sequences

Understanding snapshot-based backups and restores

The plug-in can use a hardware or software VSS provider to create persistent or non-persistent VSS-based snapshots. The plug-in uses a VSS provider to create snapshots on the client, and then copies the selected data from the snapshot, or snapshots, to a storage device.

You can use hardware-based, integrated VSS snapshots with the Dell Compellent storage array. Be aware that if you include a mixture of databases, Compellent and non-Compellent, in the same backup job, the plug-in backs up all included databases to the same storage device.

To create and use persistent snapshots, the data that you want to back up must reside on NetVault Backup-supported disk arrays. If you attempt to create persistent snapshots with data residing on an unsupported disk array, or with data residing in local drives (for which snapshots are taken using the Microsoft Software VSS Provider), taking the required hardware snapshots fails, and the plug-in defaults to using software snapshots. When taking software snapshots the data is only backed up to storage (even if the option Backup Files to Storage is not selected), and non-persistent snapshots are created.

The same issue occurs if your backup includes data that resides in different storage that mixes NetVault Backup-supported disk arrays and unsupported disk arrays or local drives. For example, if your backup includes five Exchange Mailbox Databases, for which three of the Mailbox Databases reside in different volumes in a NetVault Backup-supported disk array, and the other two Mailbox Databases reside in two different local drives on the Exchange Server, and you select Retain Array-based Persistent Snapshot, taking hardware snapshots fails because all the Mailbox Databases do not reside on NetVault Backup-supported disk arrays. After failing to take the required hardware snapshots, the plug-in attempts to take software snapshots; if successful, the data is saved to NetVault Backup-managed storage, even if the option Backup Files to Storage was not selected.

IMPORTANT: If you are running a DAG environment, ensure that the software-based Microsoft VSS provider is in place on all Exchange Servers included in the DAG and ensure that the software-based provider has preference over any vendor’s hardware-based VSS provider.

If your backup target is non-NetVault Backup media, such as a disk array, and you need to complete a restore, be aware of the following: If you restore an Exchange database to a DAG and do not specify a Target Client, the plug-in restores the database to the node that hosts the active copy. If you restore the database from a persistent snapshot, the plug-in maps the volume in the client that took the snapshot during the backup process. Because of these conditions, restoring from a persistent snapshot to a DAG, that is, where the Target Client is a NetVault Backup Virtual Client, requires that the active copy of the database is hosted on the node that takes the snapshots during the backup process.

Example: If node1 takes a snapshot while DB1 is being backed up, restoring DB1 from the snapshot requires that node1 is the host of the active copy of DB1. Otherwise, the restore fails. For example, if node2 is currently hosting the active copy of DB1, you must move the active role from node2 back to node1.

To change the active-role assignment, use the following PowerShell command:

If the damage to the database causes validation failures, use the -SkipClientExperienceChecks switch to force activation of the database:

For more information about NetVault Backup-supported OS versions and disk arrays, see the Quest NetVault Backup Compatibility Guide.