White Papers

BP1013 Best Practices for Enhancing Microsoft Exchange Server 2010 Data Protection and Availability 42
Table 9 shows a summary of the activity executed in each scenario.
Table 9 Seeding supported by SAN summary
Reseeding from a
Smart Copy snapshot
Seeding from a cloned
Smart Copy snapshot
Duration of each step
Define mailbox copy
5 seconds with PowerShell commands
Snapshot selection Administrator intervention
Smart Copy soft recovery
Average <1 minute
Checksum verification
Proportional with DB size
N/A
Create a clone
5 seconds with the Group Manager GUI
N/A
Reassign cloned volume
5 seconds with the Group Manager GUI
N/A Clone move
Proportional with the amount of GB to
transfer and with the network bandwidth
available on the iSCSI network
N/A
Mount the volume
Around 25 seconds
Mount Smart Copy
N/A
Around 25 seconds
Resume replication
5 seconds with the Exchange Management
Transaction log replay
Proportional with the number of logs
The outcomes of these two sets of tests proved that having a Smart Copy snapshots recovery strategy
in place helped in off-loading the application hosts from the burden of the seeding activities. All the
steps undertaken to recover the volume, and then the mailbox database copy, had no effect
whatsoever on the hosts as they were performed on the EqualLogic SAN and on the iSCSI network
directly (except for the transaction log replay), leaving all the host resources available to perform the
regular Exchange Server tasks.
7.4.3 Seeding operations details
Seeding a mailbox database copy is possible even without starting the data transfer immediately at the
time of the copy definition. Some options are not supported within the Exchange Management
console, so the PowerShell CLI was used to issue the commands for this specific case.
The command for the initial mailbox database seeding (including Content Index) by creating the
database copy object without replicating the data:
[PS]>Add-MailboxDatabaseCopy -Identity DBn -MailboxServer MBXn
-ActivationPreference 2 -SeedingPostponed:$TRUE
In the test case where a previous mailbox database was present, but a full update was required (for
example, a corrupted database), we initially eliminated the passive copy as shown in the command
below and deleted the remaining files from the volume:
[PS]>Remove-MailboxDatabaseCopy -Identity DBn\ MBXn