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.
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.
Exchange Server 2007 is a complex topic, do you need practical hands on training? As an MCT trainer, I can thoroughly recommend
TrainSignal. In particular, I like the way
that TrainSignal cover all learning methods, instructor lead, video and of course text
material. You can either take one module, for example Exchange 2007 or go for a combination of modules.
Learn more about Microsoft Exchange Server 2007 here
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 Manger, 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.
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.
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.)
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.
The
extra features you get in your eBook include: 'How to...' sections
with screen shots. Checklists to prepare your migration plan.
