Consider the following information before you perform specific recovery procedures within your Exchange 2000 organisation:

• Perform Exchange 2000 database backups at the storage group level so database backups run more efficiently. If you perform a Normal backup of a single database in a storage group, log files that contain previously recorded transactions are not deleted until the other databases are backed up as well.

  Furthermore, if you perform a Normal backup of all databases in a single storage group, log files that are older than the checkpoints are deleted from the hard disk at the end of a successful backup. Incremental backups of a storage group also delete transaction logs for that storage group; Differential backups cause the log files to remain on your hard disk.

  You can restore a mailbox or public folder store without affecting other databases within the same storage group. To manage this process, Exchange 2000 uses a reserved instance of ESE. This reserved instance of ESE allows the restore process to create the restored database in a temporary storage group until the database is moved to the correct storage group.

• A restore-in-progress key is no longer used during the restore process as it was in Exchange 5.5. In Exchange 2000, individual data structures are created for each database being restored. The information about the restore process that was previously written to the restore-in-progress key is now written to a file called Restore.env.
• Solve corruption problems before you recover a server running Exchange 2000. For example, you cannot play the wrong transaction log files into a database or force a database into starting when the necessary components are not present on disk.
• Transaction log files and patch files have checksums that are validated during the backup process. Therefore, it is unnecessary to use the Verify data after backup option of Backup ù it simply increases the time it takes to perform a backup.
• You can configure storage limits for the mailbox and public folder stores to constrain databases to a maximum size limit. After you determine the speed that your backup hardware performs in megabytes per hour, you can estimate the maximum time it takes to perform a backup or restore of those databases. This allows you to accommodate the service level agreement that you established.
• To use ESE to back up a database, the database must be online. If a database is offline, you can still back up the database manually, but the transaction log sequence is not truncated. As a result, the databases and log checksums cannot detect errors. For more information about offline backups, see Offline Backups.
• You can back up and restore databases within a storage group individually or simultaneously. As long as you do not exceed the data bandwidth capacity of your hard drives, controllers, and backup hardware, you can save time by running multiple instances of Backup to simultaneously back up or restore databases. For more information about how to back up and restore multiple databases, see ôMultiple Database Recovery Considerations later in Part 1 of this document.

The information in this article applies to:

• Microsoft Exchange Server 2003 Enterprise Edition
• Microsoft Exchange Server 2003 Standard Edition
• Microsoft Windows Small Business Server 2003, Premium Edition
• Microsoft Windows Small Business Server 2003, Standard Edition
• Microsoft Exchange 2000 Server