Chat now with support
Chat mit Support

NetVault Plug-in for Exchange 11.3 - 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

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:

•
Extensible Storage Engine (ESE)
•
Volume Shadow Copy Service (VSS)

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.

Extensible Storage Engine (ESE) backup method
•
Supported Exchange Versions: Exchange 2007
•
Supported Exchange Deployments: Standalone, SCCs/Failover Clusters, LCR (Active Copy only), CCR (Active Copy only)

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.
Volume Shadow Copy Service (VSS) backup method
•
Supported Exchange Versions: 2007, 2010, 2013, and 2016
•
Supported Exchange Deployments: All

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.

Comparing the ESE and VSS backup methods

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.
•
For Exchange 2007 and earlier, VSS-based backups are performed only at the Storage Group level; that is, individual databases cannot be backed up, while ESE-based backups allow you to back up individual databases.
•
Restoring an individual database from a VSS-based backup is supported; however, the entire Storage Group must be offline.
•
Multiple VSS-based backups can run simultaneously, and each backup job can simultaneously back up multiple Storage Groups, which can reduce backup windows. ESE also allows multiple backup jobs for different Storage Groups to run concurrently; however, each job backs up Mailbox Databases in a serial fashion.
•
In LCR and CCR environments, VSS allow backups of either the active copy or the passive copy, while ESE-based backups are only allowed on the active copy. Backing up the passive copy lets you take advantage of the extra resources available at the second copy location. Backing up the passive copy also provides a longer backup window because it is not competing for the same resources against the actual client activity during normal work hours.
•
VSS-based backups can be restored to alternate Exchange Servers in the same domain, while ESE-based backups can only be restored to alternate Exchange Servers in a different domain.

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

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.

Full vs. Transaction Logs-Only Backups

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.
Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen