White Papers

BP1013 Best Practices for Enhancing Microsoft Exchange Server 2010 Data Protection and Availability 30
Test Details for in-place restore of one database:
Details Restore of one active database, where the second copy of the database has
been suspended.
Key indicators Time taken for restore
An outline of the operations that are automated by ASM/ME when performing a restore from a Smart
Copy set is summarized in the following list:
1. Dismount of the current mailbox database (unless it is already down)
2. As a safety measure, a SAN snapshot of the current volume is taken
3. Integration with the Exchange VSS writer is prepared for the restore
4. Turn offline and disconnection of the original volume
5. Turn online and present to the host of the Smart Copy snapshot. The SAN snapshot assumes
the volume role and replace the original volume
6. Transaction log replay and post restore operations performed by Exchange VSS writer
7. Mount of the recovered mailbox database
The outcomes of these operations are tracked in the Application Event Log of the mailbox database
server. The
MSExchangeIS Mailbox Store source tracks the mailbox database status changes (stop,
start, and related information), and the
MSExchangeIS source tracks the output received from the
Exchange VSS writer (restore operations), and finally the
ESE engine source tracks database level
operations (integrity check and log replay).
The impact on the host local resources during the restore was imperceptible and limited to a relatively
small disk write activity on the volume recovered, due to the transaction log replay. During the
transaction log replay the database was offline, and so there was no other disk activity in contention
with the recovery process.
The second test case simulates an automated mount of the snapshot and then the manual
intervention of the administrator to recover the selected transaction logs. Since the total time taken to
replay the logs depends on the number of them to be replayed and also since human intervention is
required, the total time can vary for each environment. The amount of transaction logs present inside
the snapshot and needed to be replayed to the mailbox database was significantly high, and as such
required a consistent amount of time.
The time taken to execute the restore is reported in Table 6. In both test cases the duration of
restoring (or mounting) the snapshot from the SAN was the same. The duration of the entire log replay
process was variable and related to the number of logs that will be automatically replayed by ASM or
manually by the administrator. While the automated ASM task provided a ready-to-access database,
the administratively managed recovery was underlying the selection of the required logs.