White Papers

BP1013 Best Practices for Enhancing Microsoft Exchange Server 2010 Data Protection and Availability 29
Figure 11 Smart Copy snapshots recovery point timeline
Simplification of the restore operations when using Smart Copy snapshots appears evident. During a
database recovery scenario that requires restoring a full backup, an in-place restore of a snapshot will
be much more time efficient because there is no data copy from the backup media. Additionally, the
number of transactional logs backups to be restored can be considerably reduced in proportion with
the frequency of Smart Copy snapshots taken and maintained on the EqualLogic SAN.
Overall, restoring data using Smart Copy snapshots can help considerably improve the achievable RTO
of the Exchange environment.
7.2 Testing in-place full restore
Exchange storage administrators are faced with scenarios where damage (corruption, deletion,
integrity violation) of the data contained in a mailbox database has occurred and has been transferred
to the passive copy of the database in the other node of the DAG before an administrative corrective
action has been taken. In such a scenario, using the Smart Copy snapshot, the Exchange database can
be restored back to a known good state. Multiple point-in-time copy snapshots can be created and
retained without additional increase in management complexity. Further, EqualLogic ASM provides
fully automated functionality to restore the database to a point-in-time and replay logs that were not
replayed at the time the snapshot was created.
To simulate the recovery task for the scenario outlined above, we tested and recorded the time
required to bring back online a Smart Copy snapshot of one of the mailbox databases. Microsoft
Exchange Replication Service VSS writer does not support restore operations, so we could operate a
restore of a database in a DAG scenario to the active copy only.
First we evaluated the duration of the entire automated process provided out-of-the-box by ASM/ME.
This includes restoring the database and applying the outstanding logs. We then simulated the minimal
steps required to restore the database from the snapshot and then let the administrator manually apply
logs to control the point-in-time state of the database.