Handling log files is another concern. You must either identify the log files that need to be replayed into the databases or remove the checkpoint file so that all transaction logs are replayed. I prefer the latter method, which is more foolproof and which replays committed log files at as fast a rate as 4 seconds per file (the rate I achieve on my servers by using a hardware RAID controller with a mirrored pair of log disks). Of course, your mileage might vary—I've seen some servers run up to 1 minute per log file when dealing with many files—but as long as you don't let outstanding transaction log files grow to some ridiculous number, you're looking at an outage of minutes instead of hours. The key is to purge your log files with an online APIbased backup before you perform your nightly clone split. You'll then know that you have a BCV for recovery and that the log files have been purged.
If you want to reduce log-replay time by finding only the exact log sequence numbers to replay, you must run
eseutil /mh <database name>
to find the Log Signature value in the database header, then match this value to the log sequence. Doing so will ensure that you're specifying the correct log files (e.g., E00xxxxx.log) for that database. This method is more difficult, though, because you must dump the signature, match it to the log files, and remove the log files that don't need to be replayed. These processes can introduce error, when instead you can remove the checkpoint and let Exchange blast through the log files.
On a final note, if you upgrade your servers from Exchange 2000 Service Pack 1 (SP1) to SP2 or later, be sure you have a valid backup of the Stores after the upgrade. You can't restore an SP1 backup to SP2 or later because the backup and restore processes have changed so that no patch (.pat) file is created during backup. The Microsoft article "XADM: A Patch File Is Not Created During Backup" (Q316796, http://support.microsoft.com) acknowledges the change.
Ready to Recover?
When you're faced with disaster recovery, your level of success boils down to two factors: having what you need and knowing what to do. Putting the information in this article (and in the resources in "Related Reading") into practice can substantially improve your odds of success. Be sure your recovery team understands your plan, and practice in a test environment so that your team can recover quickly and correctly.