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
SFW cluster considerations
In a SFW cluster environment, observe the following precautions:
The XML metadata file for each snapshot set along with files that store snapshot schedule information are created in a folder on the local drive by default. In a cluster environment, store these files on shared storage so that the files are available from all nodes in the cluster. The snapshot XML files should be stored separately from the volumes that are included in snapshots.
If you use the Quick Recovery Configuration Wizard to create the snapshot set, you can use the wizard to specify the file path to the appropriate volume.
If you use a VSS wizard to create the snapshot set, you can store the XML files in a location of your choice using one of the following methods:
Edit the directory path in the Directory field in the VSS wizard.
Use a text editor to create a text file named
redirect.txt
. This text file should contain a single text line specifying the Universal Naming Convention (UNC) path to the location of the metadata file, for example,\\ServerName\SharedFolderName
. Save theredirect.txt
file in the default VSS XML file directoryC:\Program Files\Veritas\Veritas Volume Manager\VSSXML
on each node of the cluster.
When using vxsnap utility commands that require the filename attribute, specify the full path to the location of the XML metadata file.
If an Exchange 2010 mailbox database is configured under a SFW cluster, you can store the snapshot set metadata file in a file share path by configuring a file share resource. This is to avoid configuring extra shared volumes to store the snapshot set file, which is available once the mailbox database fails over. In the case of a scheduled snapshot. even though schedules are visible on all nodes, the snapshot will happen only on a node where the mailbox database is present. There can be a large number of mailbox databases in Exchange 2010 and each database may have independent schedules. Hence the number of different paths required for storing the snapshot metadata files is higher, which is achieved by configuring a file share resource. You can also specify the file share path in the
redirect.txt
file, for example,\\MySystemName1\share1\QRDir
.In the case of a SFW clustered setup with more than one node, configure the Veritas Scheduler Service with any user account (other than the Local System account) which is valid on all the nodes of the cluster. This user account should have read-write permissions to the file share path.
If a schedule is created on a file share, it is visible on all nodes of the cluster and can be deleted from any node irrespective of where the Exchange mailbox database component is online.
If you plan to use the Quick Recovery or VSS Snapshot Scheduler wizard to specify scripts (commands) to be run before or after a snapshot, store the scripts on shared storage so that they are available to all nodes.
If you need to restore an Exchange 2010 database from a snapshot, running the VSS Restore Wizard brings the SFW resource for the database offline, dismounting the database before beginning the restoration. You can if necessary bring the resource offline in SFW manually to dismount the database. Once the wizard successfully restores the database, the wizard brings the resource back online, mounting the database; if not you can bring the resource online manually. If you are using the CLI, specifying the -a option in the vxsnap restore command offlines and onlines the resource automatically.
If you set up a snapshot schedule with the Quick Recovery wizard and later add a node to the cluster, you can run the wizard again to synchronize schedules on the existing nodes with the new node.
If you set up a snapshot schedule with the VSS Snapshot Scheduler wizard, before adding or removing a node from a SFW cluster setup, delete the schedules and then recreate the schedules on the required node.
Exchange must be installed on all cluster nodes.