This eBook was designed to provide the reader with a wealth of information about how to protect and secure data in the event of a disaster. It's not possible to anticipate every possible disaster your organization may encounter, but you don't have to. The responses to many disasters will be the same; you can make plans based on the expected duration of recovery, the impact of the disaster on your facilities and the surrounding area, and other factors. Even if you don't live in a disaster-prone area, you should still be prepared for things such as structure fires, major traffic accidents, and the like. For example, what if a railroad tanker filled with liquid petroleum exploded near your offices? What would you do? The Boy Scouts say "Be prepared," but the United States Coast Guard's motto may be more appropriate here: "Semper Paratus," which is Latin for "always ready." This eBook will help you make a disaster plan that works for your organization.

Nothing compares with the sinking feeling you experience when you need to restore data from a backup but can't for some reason. Most computer users have this experience eventually; the pain is even more acute and frequent for administrators, who are responsible for large amounts of important business data. Although backup and restore technologies have advanced in the past few years, you probably still use them only as last-ditch safety mechanisms. When all else fails, you try to restore from backup. For this alternative to be viable, you must have a degree of confidence that your data will be available and readable when you need it. However, Exchange administrators make several common mistakes that prevent their backup and recovery operations from running smoothly. Here just a few of them:

  1. Using the Wrong Backup Method

    The two basic methods for backing up Exchange data are online and offline. Online backups use a Microsoft interface (such as Extensible Storage Engine -- ESE, backup APIs, or Microsoft Volume Shadow Copy Service -- VSS) to copy the selected Exchange data while the Exchange services are running and while the target database is mounted and active. The Exchange-provided APIs back up transaction logs and truncate the logs when necessary.

    Offline backups copy the Exchange database and log files while the database isn't mounted. Some solutions purport to copy Exchange data without using Microsoft's APIs but also without dismounting the databases. The Microsoft article "XADM: Hot Split Snapshot Backups of Exchange" (http://support.microsoft.com/?kbid=311898) explains that Microsoft considers these backups to be offline.

    Performing online backups is preferable for typical production operations because online backups capture a consistent copy of the Exchange databases without interrupting user access. However, offline backups are useful in some situations. For example, performing a complete offline backup of your Exchange database and logs is a good idea before installing a Windows or an Exchange service pack or performing a forklift upgrade of the database to another server. Although creating offline backups is more time consuming than generating online backups, many administrators prefer the extra safety of having a periodic offline backup in addition to routine production backups.
     

  2. Not Verifying Backups

    If your backup fails and no one notices, does it make a sound? Maybe not, but your users will surely sound off if you can't recover their mail data. I recently worked with a company whose administrator accidentally corrupted a mailbox database. When the Exchange administrator tried to restore the database, he discovered that backups of the database had been failing for more than four months because the administrator hadn't installed the Exchange version of the company's third-party backup agent software. The installed version of the agent tried to back up the files but couldn't because the Exchange Information Store (IS) had the files open. Even a cursory review of the backup software's reports or the Application event log would have shown that the software wasn't backing up the Exchange data. Unfortunately, no one monitored the backups for success.

    To prevent this problem, regularly check your backup software's logs. You need to verify:

    • that the backup software is backing up what you want it to. Make sure the backup type, time, and contents are correct.
    • that the backup finishes. Verify that the requested data is backed up, and check for errors that might have occurred.
    • that you can restore the data written during the backup. If you're using tape, verify that you can read the tape from another tape drive. Check to see whether you can restore the data to a server and extract Exchange information.
    If one of these three checks fails, you should be able to determine the cause of the backup failure and therefore fix the problem. For example, during an online backup, Exchange computes a checksum for each page and compares it with that page's checksum on disk. If the checksums don't match, you receive a 1018 error and the backup stops. Checking your backups would alert you to the error and give you a chance to fix it before the backup stopped.

    Even if your backups are working now, don't get complacent. Changing your environment, backup software, Windows configuration, or Exchange configuration might make your backups fail in the future. Check your backups regularly for the best protection. The fastest and simplest way to check your backups to be sure they work is to check the Application event log and the report that your backup program generates. Check the Application event log to ensure that Exchange didn't generate any errors during the backup period. Check the backup program report to verify that the backup program didn't skip any files and that no errors occurred.