Summary of Using Exchange Server 2003 Recovery Storage Groups in Exchange Server 2003

  • Article

 

When you use recovery storage groups, remember these best practices and potential difficulties:

  • Keep sufficient free disk space available so that you can restore a second copy of a database to its original logical drive. This is useful not only for working with a recovery storage group, but for other tasks, such as offline defragmentation, testing backups, and copying a failed database before restoring from backup and overwriting it.

  • Benchmark the actual performance effects caused by using the recovery storage group on a running production server before modifying your recovery procedures to include recovery storage groups. Some server configurations may not have the capacity for recovery storage groups without significantly degrading the client experience. This situation is especially likely to be true if it becomes necessary to repair a database because the Exchange Server Database Utilities (Eseutil.exe) and Information Store Integrity Checker (Isinteg.exe) tools are tuned for speed, not for minimizing impact on other processes.

  • In Messaging Dial Tone scenarios, in which you have created a blank database to quickly restore service to users, swap databases between the recovery storage group and original storage group before merging the recovered data. This not only reduces the amount of data that must be merged, but preserves rules, forms, and offline cache mode (.ost) files.

  • Do not delete, purge, or move mailboxes from the original database if you intend to recover data from them using the recovery storage group.

  • Do not create the same database in multiple recovery storage groups on different servers. Doing so may confuse your backup application, and prevent restore of online backups to any of the recovery storage groups.

  • Remember to give the recovery storage group the same name as the original storage group, except in cases where the storage group name already exists on the server. Failing to do this causes the online backup API to refuse to restore.

  • If you run more than a single restore operation on the recovery storage group, disconnect from previously existing databases in the recovery storage group before restoring additional databases. Also, remove all log files from the recovery storage group before you begin a second restore to minimize the possibility of log file conflicts.

  • Be aware of directory and cache latency issues. If you need to grant additional permissions to recovery administrators, do so early in the recovery process because the permissions need time to replicate and become effective. Several minutes may pass after creation of the recovery storage group before replication and caching allow restore to the new storage group.

  • Remember that databases in the recovery storage group are never mounted automatically. After a cluster failover or restart of the Microsoft Exchange Information Store service, you must mount them manually. When something is not working with the recovery storage group, the first thing to check is that the database is actually mounted.