Microsoft Exchange Server 2003 - Backup Planning

Introduction to Exchange Server 2003 Backup Planning

The key to mastering Exchange 2003's backup is to appreciate how the database files interact with their logs.  If you are already familiar with how SQL's transaction logs, checkpoint files and databases work together, then the principles are the same for Microsoft Exchange's email stores.

Topics for Exchange 2003 Backup Planning

• Plan your Exchange Backup Strategy
• Exchange 2003 Database Files
• Transaction Logs
• Checkpoint Files
• Summary Exchange Backup

 ♠

Plan your Exchange Backup Strategy

All disaster recovery experts stress, that you should always think ahead to how you would restore the data.  It is no good focusing on the backup operation in isolation, you must plan ahead and visualise all the steps on the road to recovering an Exchange server.

Take an incremental backup as an example, it sounds like a great idea, it's quick and it purges the logs, but when comes to a restore you need the full sequence of incremental backups all the way to the last full backup.  On the other hand, if you had taken differential instead of incremental backups, then all that you ever need is one differential and one full backup set.  So, as you choose your backup strategy, keep in mind how you would restore the data if disaster strikes.

Guy Recommends: SolarWinds Engineer's Toolset v10

The Engineer's Toolset v10 provides a comprehensive console of utilities for troubleshooting computer problems.  Guy says it helps me monitor what's occurring on the network, and the tools teaches me more about how the system literally operates.

There are so many good gadgets, it's like having free rein of a sweetshop. Thankfully the utilities are displayed logically: monitoring, discovery, diagnostic, and Cisco tools.  Download your copy of the Engineer's Toolset v 10

Exchange Server 2003 Database Files

Let us get to know the key Exchange Server 2003 files.  Priv1.edb is a MAPI database file which corresponds to the first Mailstore on the Exchange server.  Typically, Priv1.edb is located in this folder: Exchsrvr\MDBDATA\.  Suppose you have a second mailstore called Mangers.  What will the corresponding database be called?  Priv2.edb?  Unlikely.  The default would be manager.edb.  To double check the file name and location, open the Exchange System Manager, right click the Mailstore, properties and examine the Database tab.

If you have OWA or POP3 clients, then they retrieve email from the corresponding streaming file, for example Priv1.stm.  There is nothing to configure with .stm files, in a nutshell, Exchange 2003 automatically makes an 'on demand conversion' from .stm to .edb.

Exchange Backup - Transaction Logs

The secret of a recovering an Exchange Server 2003 mailstore is understanding the log files.  The procedure is to restore the backup tapes, then let the logs replay transactions to bring the database up to the present.  Best practice dictates that transaction logs are kept on a separate disk from the mailstore databases.  This achieves the twin goals of better performance and fault tolerance.  If you lose the disk with the .edb files, restore from backup and rerun the logs.

This is what you need to know about the details of Exchange 2003's transaction logs.  The Exxxxxxx.log files hold all the Exchange transactions, consequently on a busy server the logs often consume large amounts of disk space.  Fortunately, a full backup purges all transactions, which have been committed to that particular backup set.  Whereas each store has its own .edb file, members of each Storage GROUP share the same transaction log files.  Interestingly, the size of these log files is always 5,120 k (5,242,880 bytes).  The current log is usually E00.  When the E00 log is full, Exchange just saves that old log as: E0000001, E0000002 etc and creates a new current log.

Transaction logs don't contain recognisable email messages, however they tell the ESE where in the Priv1.edb database to write data.  What transaction logs do hold is header information about the location of the .edb files to which they correspond.  My point is that the logs know where the database files should be, but the database files have no idea where their logs are kept.  For more information see Eseutil /mh.

Remember that if you have multiple stores then the transaction logs need to track which records refer to which store. So, as a matter of tactics, consider backing up at the Storage Group level.  One advantage is that the backup will then truncate (delete) transaction logs which have been written into the database that is being backed up.

Checkpoint Files

In addition to an E00.log file there is an E0x.chk, this checkpoint file is a record of which transactions have been written to the .edb store.  I think of the checkpoint file as the progress file.  E0x.chk tells Exchange how far have it has got with writing transactions into the database store.  Another way of looking at the checkpoint files is as a record of committed transactions.  If there was no checkpoint file, then a normal restart would force the ESE to read all the transaction logs.  In fact, this is exactly what happens after restoring a database from backup.  (The so-called hard recovery.)

Guy Recommends: The SolarWinds Exchange Monitor

Here is a free tool to monitor your Exchange Server.  Download and install the utility, then inspect your mail queues, monitor the Exchange server's memory, confirm there is enough disk space and check the CPU utilization. This is the real deal - there is no catch.  SolarWinds provides this fully-functioning product for free, as part of their commitment to supporting the network management community.

Free Download of SolarWinds Exchange Monitor

Summary of Exchange Backup - A Challenge

Find, and write down the names of all your Exchange 2003's .edb, .stm, .log and .chk files then make sure they are in your backup path.  One client backed up the c: \Exchsrvr\MDBDATA\, but unfortunately, the mailstore had been moved to the d: \Exchange\Mailstore\, so the tapes were empty and no recovery was possible.

As a separate exercise, investigate which Windows Server 2003 files to backup, for example, System State, IIS Metabase and the Quorum log file if you have a cluster.

 .