Chat now with support
Chat with Support

NetVault Plug-in for Exchange 12.0 - User Guide

Introducing NetVault Backup Plug-in for Exchange Defining an Exchange data protection strategy Planning your Exchange Server deployment Installing and removing the plug-in Configuring the plug-in Backing up data Restoring data Troubleshooting

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

•
Full Backups only: When requirements guarantee backup protection up to the previous day, performing Full Backups nightly should be sufficient under the following conditions:
•
Backup windows are large.
•
After-hours email volume is low.
•
Regular transaction log file truncation is required.
•
Full and Incremental Backups: When requirements guarantee data protection up to the previous day, backup time should be as fast as possible, and regular transaction log file truncation is required, Full Backups coupled with Incremental Backups is the best combination.
For example, Full Backups are performed every Sunday night at 11:00 p.m. while Incremental Backups are performed Monday through Saturday at 11:00 p.m. Each Incremental Backup includes the transaction log files that were generated since the previous night’s backup whether it be the Sunday evening Full Backup or one of the Incremental Backups from a weekday.
Restoring this type of backup sequence is more time-consuming. For example, if recovery is performed on Tuesday, only Sunday’s Full Backup and Monday’s Incremental Backup must be restored; whereas, if recovery is performed on Wednesday, Sunday’s Full Backup followed by Monday’s and Tuesday’s Incremental Backups must be restored. Even though the backups are quicker, the restores can take longer due to the intervention that is required to run multiple restore jobs.
•
Full and Differential Backups: When requirements guarantee data protection up to the previous day, restore and backup time should be reasonably fast, and only occasional transaction log file truncation is required, Full Backups coupled with Differential Backups is the best combination.
For example, Full Backups are performed every Sunday night at 11:00 p.m. while Differential Backups are performed Monday through Saturday at 11:00 p.m. Each Differential Backup includes the transaction log files that were generated since the last Full Backup. This process might require more backup time than an Incremental Backup. Regardless of the point to which recovery is necessary, the same number of restore jobs is required. For example, if recovery is performed on Tuesday, Sunday’s Full Backup and Monday’s Differential Backup must be restored; whereas, if recovery is performed on Thursday, Sunday’s Full Backup followed by Wednesday’s Differential Backup must be restored. Even though subsequent Differential Backups increase not only in size but in duration, restores are quicker because fewer restore jobs must be run.

Understanding snapshot-based backups

If you are using Exchange 2010 or later, 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.

If you are using a standalone Exchange Server deployment, you can use hardware-based, integrated VSS snapshots with the Dell Compellent storage array. (For DAG environments, only VSS backups that use the software-based Microsoft VSS provider are supported.)

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 Snapshot as Persistent, 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: For DAG deployments, hardware snapshots are not currently supported by the plug-in. 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. Also be aware that NetVault Backup-managed persistent snapshots are not supported in DAG deployments.

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

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating