Data Centers

How to protect data on Exchange servers

Data types and how they play into backup and recovery efforts

Do you know how to effectively back up and restore data for your Exchange Server? If disaster should strike tonight, would your company be able to get back on its feet? You might be surprised at how many businesses would have a tough time recovering from a tornado, flood, earthquake, or other natural disaster. If you aren't sure how to implement safeguards to protect your data, here are a few suggestions.

Local or server based
In Microsoft Exchange, data is classified as local or server-based. Local data exists on the client machines or the users’ workstations. This data can consist of anything the user and the system creates, such as e-mail or word processing documents. Most companies depend on the user to back that data up. But a better scheme is to convince the user to store important data on a network drive so that it can be included as part of the routine backup. Sounds impossible, but I have worked at companies where this was a reality.

Under Exchange, the server-based data can consist of anything from the registry to transaction log files. You should include these items in your regular backup.

It doesn’t really matter whose data it is or where it is located; it’s still the responsibility of the system administrator or other IT staff to make sure it gets backed up. Even though some system administrators consider certain information off limits to their department, it’s a good idea to back it up if you can.

A few notes about transaction files
In Exchange Server, all transactions are written to either a database file called PRIV.EDB or to PUB.EDB. For performance reasons, the transactions are first written to a sequential log file and then to the database file. The key benefit of transaction logging is that for every transaction written to your database file, a copy is written to the sequential transaction log file. This spells easy backup for you, since there is always a copy in the previous log file.

Keep an eye on log file size
One key thing to remember about the transaction log file is that it is always about 5 MB. If it’s larger than 5 MB, you can be sure it’s corrupt. Each time Exchange copies its contents to a new backup file, it creates a new EDB.LOG file and starts storing information all over again until it reaches 5 MB. The current log file is always called EDB.LOG, and Exchange creates files in sequential order: EDB001.LOG, EDB002.LOG, EDB003.LOG, and so on. Check your EBD.LOG file frequently to make sure it’s not corrupt.

Microsoft Exchange Server 5.5 keeps track of what’s happening with the logs using a checkpoint file that determines which transactions have and have not been committed to the database. This file is called EDB.CHK and resides in the DSADATA directory. The checkpoint file is updated each time you commit a file to the database. (Note that if you run performance optimizer, the EDB.CHK file may be in another directory.)

Another option to be aware of is circular logging. I recommend that you turn it off, since it does not permit incremental and differential backups. In case of a crash, you won’t have these backups available to you. Circular logging is the default in Exchange so you’ll have to turn it off in the admin program. The good side of circular logging is that it prevents buildup of the logging files on your drive and saves you space, so if you’re short on space, you may want to leave it on. Just bear in mind that you won’t have incremental and differential backups in that case. You can also back up the log files on a daily basis if they tend to accumulate too quickly and then delete the oldest ones from your drives. Some backup programs might have that feature, but I am presently unaware of any.

The transaction log and checkpoint files work well in the recovery process because the service knows what files have been committed to the database. It scans the checkpoint file to see which transactions have been committed to the database and which have not. By comparing the two files, the service can identify the files in the transaction log that are not written to the database and write them to it. It does this automatically when you start the service or when an online backup has been executed.

Basic components of any good disaster plan
No matter what type of system you are planning to back up, there are a few general concepts to keep in mind:
  • Always back up your data to some medium you can store on site and off site.
  • Make sure you can access your data within a couple of hours or less.
  • Develop a backup plan that includes specific instructions on what to do in case of a disaster.
  • Figure out how long will it take after disaster strikes to get new computers and other equipment installed and back online if the existing equipment is destroyed or damaged.
  • Store a backup server and a few critical pieces of equipment in a safe place.

If you know what Microsoft Exchange Server can do for you, you have a much better chance of writing, developing, and implementing a disaster recovery plan that will work. You should develop and implement your plan so you’ll be able to recover and restore full services to your business in a minimum amount of time.

Have a comment?
If you'd like to share your opinion, start a discussion below or send the editor an e-mail.


Editor's Picks