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.
#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.
#3: Mismanaging the Transaction Logs
Your ability to restore an Exchange database depends on the state of the transaction logs. If you have the correct set of log files for a database, you have a good chance of restoring the database to the point of failure. Conversely, if the logs are lost or damaged, the odds of a complete recovery drop. When you perform a restore, Exchange attempts to play back the log files, in sequence, from the first log required for the database (also known as the low anchor log) to the last log available (the high anchor log). If a log file between the low and high anchor logs is missing, log playback stops. The restore can't continue until you recover the missing log file.
Online backups automatically include the log files as part of the backup data set. During normal operation, Exchange continues to create new log files as transactions occur. These log files remain on disk until you perform a full or an incremental online backup, at which point the Exchange IS process truncates or removes the files. Don't remove log files yourself. In some circumstances, you might need to copy the log files to a separate directory for safekeeping. In "Offline Backup and Restoration Procedures for Exchange" (http://sup port.microsoft.com/?kbid=296788), Microsoft recommends saving copies of the transaction logs in a separate location before attempting to recover data from an offline backup.
When you use NTBackup to perform a restore, the logs don't play back unless you select the Last restore set check box (or the equivalent check box in another backup program). The database you restore isn't mountable unless you select this option, or unless you use the Eseutil /r command to manually start a log playback.
If your transaction logs are missing or any of your log files are damaged, Microsoft's free Exchange Server Disaster Recovery Analyzer (ExDRA) might be helpful. This tool can analyze a dismounted database, tell you which log files are present and which are missing, and give you options for fixing any problems it finds. ExDRA can be valuable if you experience an unexpected restore failure, although it's no substitute for understanding the disaster-recovery process and consulting Microsoft Customer Service and Support (CSS) or other experts when necessary.
Prev. page
[1]
2
next page 
