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
- Recommendations and best practices
- Configuring Exchange for Quick Recovery snapshots
- Implementing Exchange snapshot sets with the configuration wizard
- About the Quick Recovery Configuration Wizard
- Scheduling Exchange snapshot sets
- Scheduling or creating an individual snapshot set for Exchange
- Maintaining or troubleshooting snapshots
- Recovering Exchange mailbox databases
- Recovering after hardware failure
- About recovery after hardware failure
- Scenario I: Database and transaction logs volumes are missing
- Scenario II: Database volumes missing, transaction logs are available
- Refreshing the snapshot set on the current disks
- Moving the production volumes to different disks and refreshing the snapshot set
- Vxsnap utility command line reference for Exchange
Recommendations for maintenance and backups
The following are recommendations for maintenance and backups:
Locate the snapshot volumes for each database on separate disks from snapshots of other databases. This is recommended so that the process of creating the snapshot of one database doesn't interfere with any operations on another database.
Each snapshot set is associated with a metadata XML file that is needed for Quick Recovery restoration. Create a unique name for the metadata XML file of each snapshot set you create and maintain. The snapshot XML files should be stored separately from the volumes that are included in snapshots. Snapshot schedules have additional XML files associated with them. By default, the snapshot XML files are created in the following path.
C:\ProgramData\Veritas\VSSXML\application name
For Quick Recovery solutions, Veritas recommends that you create or refresh a snapshot set immediately after a Full Backup just after the database has been checked for corruption and the transaction logs have been truncated. Thus, you are assured an image of a clean database. Additionally, you may wish to create another snapshot set after an Incremental Backup. Create this snapshot set on a separate set of disks rather than refreshing the snapshot set taken after the Full Backup. This practice ensures you are not overwriting a snapshot set of a clean database with an image of a potentially corrupted database.