When I first started working with Microsoft Exchange Server about a decade ago, the organization I worked for used a tape-based backup solution for its servers. Exchange Server has changed a lot since that time, but what hasn't changed much is the way most organizations perform backups. Tape-based backups have been around for decades, and they've always gotten the job done, but they are quickly becoming impractical because of the rising amounts of data that must be backed up and the need to be able to restore that data quickly. Fortunately, Exchange Server 2007's replication capabilities are pointing the way to more practical backup methods.
The Problem with Tape Backups: Performance
Although many administrators consider traditional tape backup techniques to be tried and true, these methods actually have several major logistical problems. Probably the biggest problem with traditional backups is that there is a huge potential for data loss. No, I'm not talking about bad tapes or hungry tape drives that eat tapes—although those things can happen. I'm talking about the fact that most companies run a backup only once a day.
Imagine for instance that your company runs a full backup every night at 11:00 P.M. Now suppose that a catastrophic disk failure occurs at 10:30 P.M. The daily backup hasn't yet run, so any data written to the disk since last night's backup is lost. Consider what such a situation might mean for an Exchange server: You could lose a full day's worth of email messages.
Safeguards are in place to keep such a catastrophic failure from occurring—Microsoft separates the database from the transaction logs for this very reason. But that doesn't mean this type of failure can't happen. In fact, it has happened to me.
Last June, I flew to Orlando for TechEd. I called my wife to tell her I had arrived safely and learned a big storm had hit shortly after my flight left. My home was struck by lightning. Because I work from my home, I've built the entire second floor into an enterprise-class data center. Although I had surge protection and battery backups in place, the lightning destroyed several servers, including an Exchange server. It didn't matter that my transaction logs were separated from the databases because the entire server was destroyed. So even though Microsoft has designed Exchange to minimize the chances of data loss, the protection Exchange provides isn't foolproof.
Traditional backups affect an Exchange server's performance. The performance hit isn't a big deal if an organization maintains a 9-to-5 schedule and the backups take place late at night. However, many organizations operate 24 hours a day, so decreased performance can be a problem.
Exchange Server doesn't cease functioning during a backup; new messages are written to the transaction logs just as they always are. When the backup is complete, the transaction logs that have been backed up are committed to the database. Any messages that arrive during or after the backup stay in the transaction logs until the next backup occurs. The backup process slows down Exchange because it requires the use of disk, CPU, and memory resources, but Exchange remains available.
It's unrealistic to expect a modernized backup solution to remove all the inefficiencies from your Exchange servers. Exchange spends several hours each night performing a set of automated maintenance tasks, which explains why it can slow to a crawl late at night. Switching to a more modern backup technique can keep the backup process from being so resource-intensive, but it won't do anything to alleviate the drain on resources caused by the nightly maintenance schedule. (See "10 Tips to Keep Your Microsoft Exchange Server Humming" for more information about Exchange's automated maintenance tasks and the steps you can take to make sure your servers run efficiently.)
Yet another problem with traditional backups is that they don't always account for the rate at which data accumulates. The Exchange Information Store tends to grow exponentially. The volume of email flowing through an organization constantly increases; email attachments have grown much more common and increased in size as the availability of broadband Internet connectivity has become more widespread.
Therefore, the data being backed up each night is growing exponentially, requiring both more time and storage. Even so, most network administrators are allocated a finite amount of time to use as a backup window. Regardless of what upper management might think, it's unrealistic to expect to indefinitely backup an ever-growing data set within a static, or even shrinking, backup window.
In some organizations, the Store can grow to exceed the capacity of a backup tape. Sure, you can invest in an automatic tape loader to buy yourself time, but unless you implement strict mailbox quotas, the Exchange Store will continue to grow indefinitely. Mailbox quotas can be tricky for some organizations because either business needs or regulations require long-term retention of data, although going without mailbox quotas isn’t practical for most organizations. Many organizations have turned to message archiving solutions as a supplement to their backups. Message archiving lets you archive older messages and remove them from Inboxes and the server so that they don’t affect your regularly scheduled backups.
The Problem with Tape Backups: Recovery
Another aspect of traditional backups that I've always found frustrating is that they don't offer true point-in-time restore capabilities. For example, suppose that you create a backup at 11:00 P.M. and the server crashes at 2:00 P.M. the next afternoon. In such a situation, you have two options: restore the backup and let Exchange process the transaction logs that have accumulated since the last backup was made, bringing the Store back to a current state; or blow away the transaction logs and restore the backup, bringing Exchange back to its state at the time the backup was made.
Now suppose the reason the server crashed was because a virus unleashed havoc on the server an hour before the crash. In this situation, it would be great if you could restore the server to its state just before the infection. Unfortunately, traditional backups don't offer this capability.
Finally, managing backup tapes can be difficult for Exchange organizations. Typically, when a backup is made, the tape is taken offsite so that it can be stored away from the facility. That way, if the office were wiped out by fire, hurricane, or some other catastrophe, the data is still safe because it's at another location.
Although storing backup tapes offsite is a good idea, it has its downside: Not having backup tapes immediately available can greatly increase the amount of time it takes to recover from a disaster. After all, you can't restore a backup if you don't have the tape in your possession. Furthermore, most tape-management services charge a hefty fee for emergency tape retrievals. Because of this variety of limitations, traditional tape backups simply aren't sufficient for most organizations these days.
Previous
Register
