6 Common Backup and Restore Mistakes

#4: Not Allowing Enough Time
Backups take time. Each backup configuration has a throughput number that reflects how much data you can back up and restore in a given time period. A common mistake is to underestimate the amount of time a restore will take. When a restore takes longer than anticipated, you sometimes must break service level agreements (SLAs), and users are often disgruntled.

Microsoft's recommendation is to measure the length of time necessary to back up a volume of data, then allocate twice that time for a restore. You might wonder why a restore takes twice as long as a backup. Suppose you need to back up a 60GB database, using a backup system that can write 12GB per hour. Five hours seems reasonable for a backup. However, when you get ready to restore the data, remember that merely reading the data takes five hours. The restore process requires that you also do the following:

• Locate the appropriate backup media (if you're using removable media such as tape) or find the appropriate disk volume (if you're using VSS or SAN-based backups).
• Transfer the backup data to the server from which you'll perform the restore.
• Create a recovery server or Recovery Storage Group (RSG), if necessary.
• Read the data back from the backup media and correct any errors or problems.
• Replay the transaction logs.
• Move data from the recovery server or RSG to production mailboxes.
• Mount the database successfully.
• Deal with any ancillary problems that arise.

This list isn't trivial; if a problem occurs at any stage in the process, your recovery operation won't proceed through the successive steps. The more restores you perform, the more smoothly they'll go. You'll be able to accurately estimate how long a restore will take, and you'll become familiar with and learn how to solve the types of problems that are common in your environment.

#5: Forgetting the Small Stuff
Exchange backup discussions often focus only on backing up and restoring Exchange data, ignoring the numerous other objects and data items that you must also back up and restore. For example, if your Exchange server has a catastrophic hardware failure that requires you to replace it, you need to install Windows and Exchange on the new server before you can use your Exchange database backups and transaction logs. Maintaining a system-state backup of your Exchange server lets you easily restore the server and Exchange data, putting you back in business much more quickly than if you need to hunt for product installation CD-ROMs, product keys, and so on. If your Exchange environment includes antivirus software, spam filters, X.509 Certificate Authorities (CAs), fax connectors, or other auxiliary services, you need to back up and restore their configuration data as well as the necessary data (e.g., private keys, filter lists) to restore these services to their original operating quality.

When you use NTBackup to perform a system-state backup, NTBackup captures all the system data on the local machine, including the registry, Active Directory (AD) Directory Information Tree (DIT) files on a domain controller (DC), Windows Certificate Services data, DHCP and DNS server databases, and other data that's crucial for recovery. Most third-party backup utilities also have this capability, but you don't need to use third-party tools; you can use NTBackup to schedule a system-state backup to an on-disk file, then include the file with every Exchange backup. This method guarantees that you always have an up-to-date system state to restore. Don't forget to periodically update the Automated System Recovery (ASR) disk. You can often use the ASR disk to repair damaged Windows installations without completely reinstalling the OS. Many third-party backup programs have a similar capability.

#6: Not Practicing
The best time to learn how to recover data in your environment is before you have a problem. Remember that practice makes perfect. Even if you have only one database on one server, you can still practice recovery. Buy a copy of Microsoft Virtual PC 2004 or VMware Workstation, build a test server, and practice restoring data to it. If you're using Exchange Server 2003, you must be thoroughly familiar with RSGs and how to use them. You need to know how to use your preferred backup program to restore data to the original server and to a different server. Keep your product installation CD-ROMs and product keys in a safe location (not in a text file on a server that you might need to recover). Regularly practice recovering items that you might need to recover during an actual outage; depending on your environment, these items might include individual mailboxes, individual messages, databases, storage groups (SGs), or entire servers. Practicing beforehand will be time well spent when a failure occurs.

Spend Time, Not Money
Many companies spend a lot of money on disaster-recovery and high-availability solutions but discover too late that just buying the best hardware and software isn't sufficient. You can use the free NTBackup utility and an inexpensive tape-or disk-based backup system to build a completely adequate disaster-recovery solution. Learn as much as you can about backup and recovery, avoid the common mistakes I've discussed, practice backup and recovery in your environment, and continually monitor your processes. Then, when you experience a failure, you'll be ready to put your skills to work.