Specifications

Halted

Operation 2. Back Up Database Files

Operation 3. Transaction logs

Operation 4. Log Files are Truncated

Operation 5. Backup Operation Complete

Restore an Exchange 2007 Database

Restore an Exchange 2003 Database by

Overwriting Existing Database

Restore an Exchange 2003 Database using a

Recovery Storage Group

Exchange Storage Group

The Barracuda Backup Agent for Microsoft Exchange Server provides a full backup of the Exchange storage group.

An Exchange storage group is a logical container for your email database and its associated system and transaction

log files.

Microsoft Exchange uses transaction logging to commit new and changed data to the database, and to ensure that records of the transactions

exist if a store is damaged between backups. The Exchange storage group, and its associated transaction logs, is the most important data to back

up on your Exchange Server to ensure your email database is available in the event it becomes damaged or unrecoverable. If you must rebuild a

server, you can use the latest transaction log files plus the last full backup to recover your database.

The Barracuda Backup Agent for Microsoft Exchange Server backs up and restores the entire storage group; it allows for the storage group to be

restored to a storage group or to an alternate Microsoft Exchange Server.

Backup Process

Several important operations occur at the start of the Exchange storage group backup process. Here is the overview of the backup process:

Operation 1. Cache is Flushed and Checkpoint is Halted

When a full backup operation is initialized, the Exchange Server Extensible Storage Engine (ESE) first flushes its cache to disk and halts

the checkpoint. The checkpoint cannot advance until the backup operation is complete. It is important to note that when a partial backup

such as a differential, incremental, or copy backup runs, ESE allows the checkpoint to advance because the backup operation does not

touch the databases.

Operation 2. Back Up Database Files

The backup application uses backup API calls to pass a list of databases to ESE for back up. ESE sends the backup application chunks of

database pages in sequential order, and performs a checksum on each page. The backup operation is terminated if an error is

encountered.

Operation 3. Transaction logs

ESE stores the transaction logs to the backup set, and halts the checkpoint at the beginning of the backup. To

back up the log files, the backup application uses the appropriate API call to request a list of log files (and patch

files, if applicable) from ESE. When ESE receives this call, it closes the current log file, saves the file as the

next log generation in a sequential list, and opens a new E0 .logn file where n represents the storage group

instance of the log file.

In the case of a full backup, ESE then returns a list of log files to the backup application; this list starts

with the current log generation in which the checkpoint was halted, and ends with the log generation

that ESE just closed (i.e., minus 1). E0 .logn

In the case of an incremental or differential backup, ESE returns a list beginning with the oldest log

generation on disk and ending with the most recently closed log generation. Using this list, the backup

application can open file handles to the log files and copy them to the backup set. During this

operation, ESE ensures that no log generation is missing from the sequence passed to the backup

application.

When a database is backed up using the Exchange streaming backup API, each page in the database is read in turn, and the

checksum integrity of each page is verified. Additionally, transaction log file checksum integrity is confirmed before they are backed up.