Cliff’s notes on Exchange backups
Here are a few notes, based on my experience with Exchange backups. Remember,
only a portion of the backup process is Backup To The Web – much of it is Microsoft,
and it can have its quirks. Exchange backups are the most difficult and tricky of the
database backups, and it takes some experience to get it running well, whether the
method is Backup To The Web or a tape backup that goes in your glovebox.
Restores
A quick note on Exchange restores: sometimes exchangerestore.exe doesn’t work.
Don’t blame me – Microsoft thought all this up! Exchangerestore is a simple tool that
copies the restored files to the corresponding locations and then calls Exchange’s API
to reapply log files and mount the database.
In some situations, exchangerestore has problems in mounting the restore files through
Exchange standard APIs. These same restored files can be repaired by using eseutil –
r, and then they will mount. The restored files should be identical to those being spooled
by Exchange initially (otherwise, we would get corrupted files). What we suspect is that
in certain cases, files spooled by Exchange might not be in a stable state, and require
the use of eseutil to repair them.
I’ve also seen problems restoring with exchangerestore.exe that were related to the
backup’s location. If the backup is stored in a deep folder (d:\xxx\xxx\xxx\), I’ve found
that moving it to a simpler location (d:\xxx) will result in a good restore. Again, don’t ask
me why – it’s one of the wonders of the Microsoft Exchange Restore.
Backups
Exchange works by storing the inbound email in log files. They are then committed to
the database files.
So, how to back up? Well, you could ignore the log files and just back up the database
files in their entirety. Since these files can become huge (gigabytes of data), this seems
impractical – to make a daily backup of the databases could totally swamp a backup
system. Microsoft’s answer is to save the .log files.
If you make a full database backup, then save the subsequent log files, you can restore
the database from backup, then “play” the saved log files back to the database, bringing
it current. This is all well and good, providing you aren’t missing any log files and the
Microsoft software cooperates. So, you do a full database backup, then save the log
files every day until the next full backup, and hope we didn’t lose one in the process,
invalidating everything.
Let’s go back and discuss the original possibility – ignoring the log files and just doing a
full backup every day. Aside from the huge amount of data transferred and the
excessive time involved, it’s a good, simple idea, right? But – Backup To The Web has
a secret weapon – the In-File Delta. If you back up a file, subsequent backups of the
same file save only the differences! So, a 5GB Exchange store requires a 5GB backup
the first day, then perhaps only 50MB the second day. When you restore, Backup To
The Web combines these backups and sends you a full store automatically. No logs, no
missing files, no hassles. No kidding.
So, how would we implement this “logless” solution? Backup To The Web has two
Exchange backups – “Database” and “Log”. We’ll completely ignore “Log” and set up a
complete “Database” solution. Let’s begin.
Follow the instructions in the user’s guide “How to backup Microsoft Exchange Server”.
We’re going to remove one step and add one step, however. First, ignore the
instructions to set up a schedule for a log backup, and second, we’ll expand our options
on the database backup schedule.
Changes to the database backup method
On the backup schedule, set your daily backup to start as soon as most of your users
are off the system.
After you have built your Database backup, go to the In-File Delta section, like this:
Your default In-File Delta setting is “incremental”, the smallest possible backup.
Press the “advanced” button, to give you this:
This is where the magic happens! Set your advanced settings to give you a differential
backup on Saturday, then complete (non-delta) backups on the first of each month.
Instead of the monthly backup shown here (happening on the first day of each month),
you should pick a weekend day, say, First Saturday.. Why? Because it’s going to be a
full backup, taking possibly all day (or two), depending on how large your data store is.
The weekly Saturday differential is important – it does an In-File Delta back to the last
full backup, superceding all the incrementals for the month. That will make it faster for
you to restore – Backup To The Web only needs to apply the differentials to the last full
backup, not all the incrementals. It also reduces your number of deltas. But, all of that
happens behind the scenes.
Make sure you read thoroughly the In-File Delta section of the professional user’s
manual. Note particularly that once a delta gets to a certain percentage of the entire file,
or a certain number of deltas are reached, a full backup happens without warning. The
backup approach we’ve set here should have plenty of leeway, though, and a full
backup shouldn’t be inadvertently triggered.
Cliff Peterson
Backup To The Web
www.backuptotheweb.com