Storage Foundation 8.0 Quick Recovery Solutions Guide for Microsoft Exchange - Windows
- Introducing Quick Recovery for Microsoft Exchange
- Planning a Quick Recovery snapshot solution for Exchange
- System requirements
- Methods of implementing Quick Recovery snapshots
- Planning your Quick Recovery solution
- Backup types for snapshot sets
- About logs
- Recommendations and best practices
- Configuring Exchange for Quick Recovery snapshots
- Implementing Exchange snapshot sets with the configuration wizard
- About the Quick Recovery Configuration Wizard
- Tasks for implementing snapshot sets with the configuration wizard
- Reviewing the prerequisites
- Scheduling Exchange snapshot sets
- System Selection panel details
- Instance Selection panel details
- Mount Details panel details
- Synchronizing Schedules panel details
- Template Selection panel details
- Number of Snapshot Sets panel details
- Snapshot Volume Assignment panel details
- Snapshot Schedule panel details
- Specifying snapshot schedule details
- Summary panel details
- Template Implementation panel
- Administering or troubleshooting scheduled snapshots
- Scheduling or creating an individual snapshot set for Exchange
- Maintaining or troubleshooting snapshots
- Recovering Exchange mailbox databases
- About recovery using Quick Recovery snapshots
- Tasks for recovery using Quick Recovery snapshots
- Prerequisites for recovery
- Recovery using an Exchange 2010 passive copy snapshot in a Database Availability Group (DAG)
- Recovery for Exchange 2010 using the VSS Restore Wizard
- Recovery for Exchange 2010 using the vxsnap utility
- Post-recovery steps
- Recovering after hardware failure
- About recovery after hardware failure
- Tasks for recovering after hardware failure
- Reviewing the prerequisites
- Reviewing the sample configuration for Exchange 2010
- Scenario I: Database and transaction logs volumes are missing
- Identifying the missing volumes (Scenario I)
- Deleting missing volumes from Storage Foundation
- Replacing hardware and adding disks to the dynamic disk group
- Changing the drive letter or mount points of the snapshot volumes
- Restoring the Exchange 2010 mailbox database to the point in time
- Refreshing the snapshot set (Scenario I)
- Scenario II: Database volumes missing, transaction logs are available
- Identifying the missing volumes (Scenario II)
- Deleting missing volumes from Storage Foundation
- Replacing hardware and adding disks to the dynamic disk group
- Changing the drive letter or mount points of the snapshot volumes
- Restoring the Exchange 2010 mailbox database to the point in time
- Recovering the Exchange 2010 mailbox database to the point of failure
- Refreshing the snapshot set (Scenario II)
- Refreshing the snapshot set
- Refreshing the snapshot set on the current disks
- Moving the production volumes to different disks and refreshing the snapshot set
- Reattaching healthy snapshot volumes
- Clearing the snapshot association for volumes whose drive letters or mount points were reassigned
- Adding mirrors to volumes whose drive letters or mount points were reassigned
- Creating snapshot mirrors of volumes whose drive letters or mount points were reassigned
- Creating the new snapshot set
- Vxsnap utility command line reference for Exchange
Recovering the Exchange 2010 mailbox database to the point of failure
Use the following procedure to recover the mailbox database to the point of failure (POF).
Refer to the Microsoft Exchange Shell cmdlets.
Note:
When restoring after a hardware failure, you must use the command line and make sure to specify the -r option.
Warning:
If you choose to restore the mailbox database to the point of failure, you cannot later restore to the point of time. You can only perform one recovery procedure on a mailbox database.
Warning:
You must verify that you have correctly assigned the drive letter or mount point to each volume and that you have accounted for all the volumes in the mailbox database.
To recover the mailbox database to the point of failure
- Verify that you have correctly assigned the drive letter or mount point to each volume and that you have accounted for all the volumes in the mailbox database.
- If replication is enabled for a cluster setup, then use the Suspend-MailboxDatabaseCopy cmdlet to block replication and replay activities (log copying and replay).
Suspend-MailboxDatabaseCopy -Identity MB1[-Confirm:$False]
Use -Confirm to prevent user intervention.
- Use the Set-MailboxDatabaseCopy cmdlet to configure the properties of a database copy and set the checkbox for "This database can be overwritten by Restore".
set-mailboxdatabase -identity MB1-allowfilerestore:$true
- Use the dismount-Database cmdlet to dismount the database.
dismount-Database -Identity MB1[-Confirm:$False]
Use -Confirm to prevent user intervention.
For a VCS cluster setup, offline the VCS resource for the database manually if automatic offlining of the resource fails.
Specifying the -a option with the vxsnap restore command dismounts the database automatically. In the case of a VCS cluster setup, it offlines the resource automatically.
- Now perform the VSS restore operation using either the VEA wizard or the vxsnap CLI utility with the active writer (Microsoft Exchange Writer) to restore the passive copy snapshot.
vxsnap -x snapdata.xml restore RestoreType=PIT writer="Microsoft Exchange Writer"
For this example, assume that the snapshot of the replica was performed with
vxsnap -x snapdata.xml create writer="Microsoft Exchange writer Replica" component=MB1 backupType=COPY -E -O
- Use the mount-Database cmdlet to mount the database.
mount-Database -Identity MB1
For a VCS cluster setup, online the VCS resource for the database manually if automatic onlining of the resource fails.
Specifying the -a option with the vxsnap restore command utility mounts the database automatically. In the case of a VCS cluster setup, it onlines the resource for the database.
- If you have suspended replication as shown in step 2, then use the Update-MailboxDatabaseCopy cmdlet.
Update-MailboxDatabaseCopy -Identity MB1-SourceServer -DeleteExistingFiles [-Confirm:$False]
Use -Confirm to prevent user intervention.