NetVault Plug-in for Exchange 12.0 - User Guide

Protecting Exchange Server databases

A database is the finest granularity of storage organization within the Exchange Server schema. Mailboxes are assigned to specific databases, which allows segregation of data by mailbox for security or scalability purposes. Occasionally, critical or high-volume mailboxes are segregated to a separate database to improve performance or to perform more frequent backups.

Databases are used to contain mailboxes, messages, folder stores, and various other data objects supported by the Exchange Server. While they can contain a large variety of data objects, databases are typically one of two types: mail stores and public folder stores. In Exchange Server terminology, a store is the same as a database.

Microsoft also differentiates editions of the Exchange Server product by increasing support for concurrent databases. The Enterprise Edition is defined as supporting more concurrent databases than the Standard Edition.

Protecting the Exchange Server transaction log

All changes made to the Exchange Server database are first committed to transaction log files. Any time a user modifies data stored in a mailbox or data is added to the mailbox, that change is written to a transaction log file before it is written to the Exchange Server database.

Reviewing the available backup methods

Plug‑in for Exchange supports the following backup methods:

For Exchange 2007, the plug-in supports implementing an ESE or a pure VSS-backup strategy; that is, your backup strategy should include either ESE backups or VSS backups, not a combination of the two. For Exchange 2010 and later, VSS is the only option supported by Exchange.

Microsoft supports performing online backups of Exchange Server databases by using the ESE for Exchange 2007 and earlier. ESE, which is provided by Microsoft as a standard Exchange Server component, provides the highest levels of compatibility with Exchange.

IMPORTANT: Windows Server 2008 supports Exchange Server 2007 SP1 or later; previous versions of Exchange 2007 are not supported. In a standard Exchange Server 2007 SP1 installation, there is an ESE client library (esebcli2.dll) in the Exchange Server Bin folder. The file version of esebcli2.dll is 8.1.240.5 for Exchange Server 2007 SP1. However, if this library is not replicated from the Exchange Bin folder to the Windows Bin folder, an older version of the .dll file might be present in the Windows Bin folder. Plug‑in for Exchange uses the ESE client library that is available in the Windows Bin folder. If the older version of the library is contained in the Windows Bin folder, a backup or restore job might fail. If a failure occurs, save a copy of the ESE client library from the Windows Bin folder to a safe location, copy the ESE client library from the Exchange Server Bin folder to the Windows Bin folder, and run the backup or restore job again.

Microsoft supports the ability to create snapshots of Exchange data using VSS. Microsoft provides Exchange-specific VSS writers that coordinate with the Exchange Services, operating on behalf of the Plug‑in for Exchange, to prepare the Storage Group/Mailbox Database files for backups and freeze the input/output (I/O) activity due to Exchange transactions before backing it up, and then to unfreeze and truncate logs after the backup is complete.

VSS is the recommended backup method for Exchange 2007 LCR and CCR environments. When using the VSS-backup method in a CCR environment, administrators can choose whether the active or passive node is backed up.

For Exchange 2010 and later, VSS is the only option supported by Exchange.

Using VSS, you can:

NOTE: The Backup Files to Storage option is supported with any disk-based storage. To use the Retain Snapshot as Persistent and Discard After options, the data that you back up must reside on a NetVault Backup-supported disk array. Also, for persistent snapshots, only the metadata is copied to the target.

When determining the backup method for your Exchange-backup strategy, consider the following differences:

NOTE: ESE and VSS are not supported on all versions of Exchange. The version of Exchange that you are using dictates which backup methods are available.

Managing transaction log files

When defining an Exchange Server backup strategy, transaction log file management is a primary consideration.

IMPORTANT: Important: Because all changes made to the Exchange Server database are first committed to transaction log files, Quest strongly recommends that you perform periodic Full or Incremental Backups to prevent excessive accumulation of transaction log files. Failure to perform regular backups, which reduces the number of transaction log files, might eventually cause backup jobs to fail. Also, accumulating thousands of transaction log files negatively impacts the time required to process a backup job and generate the index. If your environment involves frequent changes to the Exchange Server, Quest also recommends increasing the frequency of backups to reduce the accumulation of transaction log files.

Transaction log file truncation is used to “clean” the Exchange Server Storage Group/Mailbox Database, thus improving performance, and reducing the disk space requirements and the time required to restore a database.

Quest recommends that backups that perform transaction log file truncation be performed regularly. Often, a weekly or semimonthly backup that performs transaction log file truncation is recommended. The optimum frequency might vary considerably, depending on the use and configuration of each Exchange Server.

If you use a Backup Type that supports transaction log file truncation, such as the Full and Incremental Backup types, the truncation of transaction log files is performed by the Exchange Server after the plug-in informs it that the backup completed successfully. Also, when the truncation occurs depends on Exchange Server and whether it still needs the logs for more purposes, such as replication; therefore, truncation might not occur immediately after a successful backup is completed.

In a DAG environment, transaction log file truncation is also determined by the replay lag time and truncation lag time properties of the database. The properties are configurable. Replay lag time defines, in minutes, the amount of time to delay log replay for a database copy. Truncation lag time defines, in minutes, the amount of time to delay log deletion for the database copy, after the log file has been replayed into the database copy.

For Exchange Server to truncate a transaction log file, the following criteria must be met:

In a DAG environment, each database copy keeps transaction log files until all the database copies have confirmed that the transaction log file has been replayed. If one or more passive copies of the database is suspended or offline, log truncation does not occur, resulting in transaction log file buildup and the consumption of disk space.

NOTE: If your environment experiences transaction log file buildup and your disk space is diminished, check the online status of the passive database copies. If you must keep one or more database copies suspended or offline for a long period of time, such as for maintenance reasons, consider removing the affected passive database copy instead of suspending it or setting it offline. When maintenance is completed, the passive database copy can be added back.

To reduce the effects of transaction log file buildup due to suspended or offline database copies, Exchange Server 2013 Service Pack 1 introduced loose truncation. With loose truncation, each database copy tracks its own available disk space and applies loose truncation when disk space gets significantly low. With loose truncation applied, each passive database copy independently truncates its own transaction log files. For the active database copy, truncation ignores the passive database copy that is farthest behind replaying logs.

Loose truncation is disabled by default. To enable loose truncation, you must edit the Windows registry on each Exchange Server DAG node. Before enabling loose truncation, make sure that it would benefit your data protection goals. For more information about enabling loose truncation, see your Exchange Server documentation.

Full Backups back up all files for a database, regardless of the type of file. Transaction Logs-Only Backups back up only the transaction log files for a database.

Full Backups allow all database files to be backed up, providing standalone restore capabilities. Depending on the size of the database, Full Backups can be demanding in terms of storage requirements, and time required to complete the backup. For large databases, storage and time requirements might be a significant consideration.

Transaction Logs-Only Backups are lighter-weight backups that are intended to capture new activity since the last Full Backup was performed. This type of backup can radically reduce the backup time and storage requirements for large databases, but it also introduces dependencies on one or more prior backups to perform a complete restore.

IMPORTANT: VSS-based backups for non-Continuous Replication environments truncate the transaction logs at the completion of Full or Transaction Logs-Only Backups. In LCR and CCR environments, log truncation is delayed by the Microsoft Exchange Replication Service until all necessary log files are replayed into the replica copy. Microsoft Exchange Replication Service deletes the backed-up log files both from the active and the passive copy log file paths after it verifies that the to-be-deleted log files have been successfully applied to the passive copy database and both the active and passive copy database check points have passed the log files in question.