White Papers

BP1013 Best Practices for Enhancing Microsoft Exchange Server 2010 Data Protection and Availability 28
differential backup is now translated into the transaction logs backup that requires only the copy of
the logs generated since the last full backup, and does not include a copy of the entire database file,
even if modified.
This technology then requires, at the time of recovery, a process named ‘transaction log replay’ to
integrate all the changes tracked in the transaction logs into a previously restored full backup of a
database.
Figure 10 illustrates a simple backup scenario and the operational effort required in order to restore
from a transactional logs backup. The components required to recover up to the nearest time to the
database failure are a total of 10 backup sets (marked in blue), and must include the most recent full
backup (at time T0), each transactional log backup occurred between the full backup and the failure
(T1 to T9), and the transaction log replay for all the logs generated after the last transactional logs
backup (if the logs are available).
Figure 10 Transactional Logs Backup recovery point timeline
Figure 11 illustrates the operational difference when the Smart Copy snapshot technology is taken into
account to protect Exchange mailbox databases. The components required to recover up to the
nearest time to the database failure are 2 backup sets (again marked in blue), and should include the
most recent Smart Copy snapshot (at time T8), each transactional log backup occurred between the
Smart Copy and the failure (T9), and the transaction log replay for all the logs generated after the last
incremental backup (if the logs are available).