Manage Learn to apply best practices and optimize your operations.

Exchange Server 2003 backup and recovery best practices Q&A

From performing system state and database backups to dealing with brick-levels and transaction logs, learn best practices that improve Exchange backup and recovery operations.

Backing up Exchange Server 2003 requires more than just a good backup application. When disaster strikes, it is imperative to have an Exchange backup and recovery process in place to troubleshoot any restore issues that may arise.

Microsoft MVP Mark Arnold outlines Exchange 2003 backup and recovery best practices in his webcast. He explains exactly what you need to back up in your Exchange Server organization, and how you need to do it to ensure a pain-free restore process.

Here, Mark Arnold answers your questions on his Exchange 2003 backup and recovery presentation.

More on Exchange Server backup and recovery:
If you don't have time to watch the webcast, you can listen to Microsoft MVP Mark Arnold's Exchange Server 2003 backup and recovery best practices podcast instead.

Get help restoring corrupted databases and much more with The Exchange Server Backup and Recovery Toolbox.

Learn the fundamentals of Exchange disaster recovery in our quick "10 tips in 10 minutes" tutorial.

Didn't find what you were looking for? Check out the Exchange Server Backup and Recovery Reference Center.

Question: You stated that the system state and database backups should be separate jobs. We run a backup job of multiple systems from a backup server. It is the same ARCserve job, but a different part of the backup. Therefore, they are not running at the same time. Is this good?

Answer: These should be different jobs. You can back up all the system states from around the network in a single job if you want, but the job should end before you commence a new job to run the Exchange backups.

Question: What software do you recommend to back up the Exchange server? I currently use BrightStor ARCserve Backup, but with brick-level backup.

Answer: Brick-level backups have always been a source of dismay for users. There are two choices:

  1. Pick a backup solution that takes a single, database-level backup of the information store but which also gives you the option to recover a single item or mailbox from that backup. Many people are going away from the two-backup-job approach because of the time it takes to perform two full passes over the information store. One is considerably slower than the other.
  2. Use ntbackup.exe to perform the backup with no fuss or fanfare, and procure a recovery product such as Quest Recovery Manager or PowerControls (many others exist) to perform single item or mailbox restores.

I favor option two as the recovery utilities give you many more features outside of the standard backup and restore process.

Question: Do I need to include the 'exchsrv' folder in the backup when I store my mail and public folder database in a different location? Also, when I restore the Exchange server, do I need to restore the database into the 'exchsrv' folder?

Answer: The files can be located wherever you want them. When you do a database-level backup you are not backing up the files as you see them. The system, being "Exchange-aware," is designed to know (via the registry) where the files actually are and takes care of them.

Restores are performed in the same way. The Exchange-aware backup application will look in the registry to see where the files are supposed to be and restores them to the correct place.

The physical file location of the backed up and restored files need not be the same. You can back up from d:exchsvrmdbdata and restore to e:store1 so long as the registry paths are so pointed.

Question: When performing full and incremental backups with Veritas, how should I be doing them? Should I back up the information store on its own and then back up the OS and logs on its own backup -- or should the logs stay by themselves as well?

I have been doing full backups of the entire Exchange server every Friday night, then doing incremental backups of the entire Exchange server Monday through Thursday.

Answer: Many people have a misunderstanding about this. The simplest answer is to back up the Exchange server at the file-level first, excluding the information store directories. This will capture all the files, including the transaction logs. Then start another job to capture the system states. Finally, the Exchange-aware backup is run which will purge the logs.

One thing that you must remember to do is to always perform an incremental backup before your weekly full backup. If you use the same marked set of tapes, you could easily find yourself in a situation where your full backup fails which would leave you without a backup at all. Doing a successful incremental backup before the full backup means you can recover a full week of data incrementally.

Question: How can I recover redolog files?

Answer: The process of replaying transaction logs is taken care of by the restore process. Take the following example:

You have a system that you have recovered from scratch on a Thursday morning. You have a full backup from the previous Friday night and incremental backups from each night (Saturday through Wednesday).

  • First, you restore the full backup, but ensure that you have told the restore application that this is not the final backup set.
  • You will then do a restore of each incremental backup which will place the transaction logs from each night into the appropriate directory. When you restore the Wednesday night tape, you will tick the box to say that this IS the final backup in the set and then tick the box to mount the store. When the store mounts it will mount the store from last week and then spend a few minutes rolling the logs forward for you, automatically.
  • You cannot skip a day. So if you don't have an incremental backup for (say) Monday you will have serious problems recovering beyond that day. You cannot insert transaction logs taken before the previous full backups either; you can only use transaction logs between full backups.
  • If during the week you choose to move the transaction logs or databases using Exchange System Manager (ESM), it is essential that you conduct a full backup immediately following the move and discard any full and incremental backups that you have in your rotation.

Question: We want to take down the live Exchange server for maintenance. Which services should we stop before shutting down the system? What about the Exchange database -- do we need to dismount it also?

Answer: If you want to take an Exchange server down for maintenance, you should stop all Exchange, antivirus, systems management and any other services that have a hook into the operating system.

Question: We use Veritas Backup Exec 9.1. I understand that this system backs up the information store in addition to the mailboxes (as a replication). However we do not understand why the mailboxes (after running ESEUTIL) occupy 16 GB, but the mailbox backup alone (without the information store) is taking 30+ GB. Do you have any ideas?

Answer: When that version of Backup Exec does its "brick-level" backup it does so without single-instance storage (SIS) so that it can restore an entire mailbox independently if necessary. So, if someone has sent a 2 MB email to 10 people the store will only increase by 2 MB (plus a little bit more), but the brick-level backup will consume over 20 MB of space.

Mark Arnold
Mark Arnold
Mark Arnold, MCSE+M
Mark Arnold, MCSE+M, Microsoft MVP, is a technical architect for Posetiv, a UK based storage integrator. He is responsible for the design of Microsoft Exchange and other Microsoft Server solutions for Posetiv's client base in terms of the SAN and NAS storage on which those technologies reside. Mark has been a Microsoft MVP in the Exchange discipline since 2001, contributes to the Microsoft U.K. "Industry Insiders" TechNet program and can be found in the Exchange newsgroups and other Microsoft Exchange forums.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.