In my previous tip, I wrote about troubleshooting Microsoft Exchange data backups and restorations. In this next tip, I will present some of the most common causes of Exchange Server backup and restore failures.
You can't perform an incremental or a differential backup
Normally, Exchange Server allows you to perform four different types of online backups: normal (otherwise known as full), copy, incremental and differential. However, there are several perfectly normal circumstances that cause incremental and differential backups to be disabled.
The first such case is that incremental and differential backups are disabled if you have just performed an offline defragmentation. After an offline defragmentation, you can only perform a normal or a copy backup. The same goes for configurations is which circular logging is enabled. If circular logging is enabled, then normal and copy backups are your only online backup options.
Incremental and differential backups don't back up the expected information
If you are performing an incremental or a differential backup, and you aren't getting the results that you expected, then check to see if you have recently performed a copy backup. A copy backup is just like a normal (full) backup, but with one very important distinction. A copy backup does not perform any kind of marking that tells the database which information has been backed up. Therefore, if you perform an incremental or a differential backup before a copy backup, and then again after a copy backup, both of the incremental or differential backups will be identical to each other.
Restored database is inconsistent
One often unexpected situation that occurs is that an administrator restores an Exchange Server backup, only to discover that the database won't mount because it is in an inconsistent state. There are two primary causes for this.
One common cause of this problem is that the administrator is restoring an offline backup. Normally, restoring an offline backup doesn't present a problem. However, if a database failure has occurred prior to the backup being made, then the database will usually be left in an inconsistent state. If the database is inconsistent at the time that the backup is made, then simply restoring the backup alone won't fix the consistency problem.
The other common cause of this problem involves using third-party backup software to make a file-level backup while Exchange Server is running. The very nature of these types of backups causes inconsistent data to be backed up. Most of the time the backup software is smart enough to know about these inconsistencies, and corrects the inconsistencies as a part of the restoration process. However, I have heard stories of databases left in an inconsistent state after a restore.
Brick-level backups
There are a lot of third-party products on the market that are designed to back up individual mailboxes and public folders rather than backing up the database as a whole. Depending on how the backup is made, these types of backups can be problematic.
I use one such product, but it simply provides a GUI interface to ExMerge. Furthermore, the brick-level backup is designed to augment my normal online backup, rather than replace it. Therefore, this type of backup solution works well, and is fully supported by Microsoft.
I have seen other brick-level backup software that takes a much more proprietary approach to backing up Exchange. I have worked with a couple of these types of products over the years, and have found that although they work well for backing up and restoring individual mailboxes, it is sometimes tricky to restore an entire information store. Besides that though, brick-level backups have been known to lose free/busy data during the restore process.
The operation didn't complete successfully
One last issue that I want to mention involves a generic error message stating that the backup did not complete successfully. Perhaps the most common cause of this error is that the Exchange database is located on the same volume as the Windows operating system. This in and of itself won't cause the problem (although it is bad practice).
The problem occurs when you attempt to backup Exchange Server and the system state from within the same backup. When you do, the Exchange storage group is frozen during the system state backup. This prevents the Exchange streaming backup from starting.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful backup tip, timesaver or workaround? Email the editors to talk about writing for SearchDataBackup.com.
