Backup and Restore Differences from Previous Versions of Exchange


Topic Last Modified: 2005-05-23

One of the design goals of the recovery storage group feature was to avoid modifying or upgrading existing online backup programs or agents. The Exchange online backup API is implemented in the Backup tool (after installing Exchange System Manager or Exchange Server on a computer) and in many third-party backup programs. The primary advantage of using a backup program that implements this API is that you can back up Exchange databases without interrupting service to users. Database backups occur while users are connected to and modifying the databases. Transaction logs generated during the backup are stored with the backup and are used to reconstruct all changes.

Another advantage of the online backup API is that it simplifies selecting databases for backup or restore operations. Rather than having to know which Exchange files require backup for a particular database, the administrator selects the appropriate server and databases to be backed up, and Exchange automatically collects and backs up the appropriate files.

When you use Backup or another Exchange-aware backup program to restore databases in Exchange Server 2003, Exchange first determines whether a recovery storage group exists on the designated Exchange server and whether the database selected for restoration is present in the recovery storage group. If it is, Exchange redirects the restored files to the recovery storage group. The backup program remains unaware that restoration has been redirected to the recovery storage group on that server.

If the database to be restored is not in the recovery storage group, restoration ends immediately, even if the database exists in another storage group on the server. As long as the recovery storage group exists, Exchange treats it as if it were the only storage group on the server for restore purposes. If the recovery storage group is not present or has been deleted, Exchange reverts to ordinary restore behavior, and the service does not need to be restarted.

If you want to have normal restoration behavior on a server without having to delete the recovery storage group, you may use Regedit.exe to set a Windows registry value that instructs the Microsoft Exchange Information Store service to ignore the recovery storage group during the restore operation.

Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.
It is strongly recommended that you use this key only in a test environment.

To do this, navigate to this path in the Windows registry on the Exchange server:


Create a DWORD value called Recovery SG Override, and set its data value to 1.

You can delete this key, or set its value to 0 when you want to restore again to the recovery storage group. As in deleting the recovery storage group, the Microsoft Exchange Information Store service notices changes to this key immediately, and you do not need to restart any Exchange services.

Do not forget to remove this key when you are done with it. Leaving this key in the registry after you are finished with the restore operation may lead to unexpected results to the affected server during future operations. If you do not know that the key is present, you may restore a database to an unintended location. In a worst-case scenario, you may overwrite a production database with a copy that you meant to restore to a recovery storage group. If the original database is mounted when you try to restore a backup, restoration fails with an error informing you that the database must first be dismounted. But if the original database is dismounted when you begin restoration, then it may be overwritten by the restoration.