White Papers

BP1013 Best Practices for Enhancing Microsoft Exchange Server 2010 Data Protection and Availability 31
Table 6 In-place full restore, time taken
Operation
Task
Duration
Next steps
ASM automated restore
Snapshot restore
25 sec
End-user access
Log replay
548sec
Total (end-to-end restore) = 573 sec
Smart Copy manual restore
Snapshot mount
25 sec
Selective Log replay process
Log replay
<5 sec/log
Total (end-to-end restore) = Variable
The number of transactions executed in the Exchange memory cache but not yet transferred to the
mailbox database file is known as
log checkpoint depth . This number can be significant when a high
load is applied to a mailbox database, as Exchange Server 2010 aggressively keeps more transactions
in the memory cache to save on the I/O to disk. The log checkpoint depth within an Exchange Server
2010 DAG configuration is by default higher than usual, varying from the regular 20MB (logs) to 100MB
(logs), and because of this increases the number of outstanding logs to be replayed during the
recovery operations.
For additional information about Log Checkpoint Depth, refer to Microsoft documentation:
Understanding the Mailbox Database Cache , available at:
http://technet.microsoft.com/en-us/library/ee832793.aspx
7.2.1 Considerations on Smart Copy in-place restore
As illustrated in the previous section, the in-place restore of a Smart Copy snapshot is similar to a
restore from a full backup, because the snapshot contains a point-in-time image of the mailbox
database. Furthermore the additional elements present on the storage volume (logs, content indexes),
and consequentially on the snapshot, would be restored in the original place with the database. As
compared to restoring from a full backup copy that requires data transfer from backup media to
primary storage, restoring from snapshot provides a much faster and easier method for recovering the
following elements:
• Mailbox database (at the level of last checkpoint)
• Transaction logs present on the disk at the moment of the Smart Copy (requiring Log
replay process)
• Content Index (ready to be updated by the Search service without a full rescan from
the scratch)
In reference to the recovery point timelines illustrated above in Section 7.1 in Figure 10 and Figure 11,
the test described in the previous section unmistakably demonstrates how quickly a single Smart Copy
snapshot can bring back online a full database at the ‘T8’ point-in-time while a traditional database
recovery approach would have required nine different backup sets to be restored (T0 to T8) – one full
database backup followed by eight incremental/transactional log backups.