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
Recommendations for Exchange storage configuration
To use the Quick Recovery snapshot functionality with Exchange databases, you must place the databases on Storage Foundation (SFW) dynamic volumes. The following recommendations enable you to take advantage of SFW storage configuration functionality as you manage your Exchange storage:
Databases and transaction logs must be stored on disks contained within a single dynamic disk group.
Each database should be in a separate volume, but the volumes may share the same dynamic disks.
Mailbox stores and public stores must be stored on separate volumes in order to be able to recover each independently.
Database stores and transaction logs must be in separate volumes in order to perform a roll-forward recovery to the point of failure.
Database stores and transaction logs should be on separate disks so that disk failure does not affect both the database stores and transaction logs.
Transaction logs should always be configured in a redundant layout. The preferred software layout is RAID 0+1 (mirrored striped) volumes as this provides better read and write performance than RAID 1 (mirrored) alone. The transaction log will generate the most I/O and thus should use the highest performance disks available.
The preferred layout for the database stores is hardware RAID 5, software RAID 1 (mirrored with logging enabled) or software RAID 0+1 (mirrored striped).
Note:
FlashSnap is not supported for software RAID 5 volumes.
When configuring volumes on a replication node of an Exchange 2010 DAG, use the same drive letters as the volumes on the active node.
By default, during installation, a database is created in the install location, which is the boot drive. Snapshots cannot be created on the boot drive. In order to use VSS snapshots on the database, you must move the database components from the boot drive to an SFW dynamic volume on another drive.