Storage Foundation 8.0 Administrator's Guide - Windows
- Overview
- Setup and configuration
- Function overview
- About the client console for Storage Foundation
- Recommendations for caching-enabled disks
- Configure basic disks (Optional)
- About creating dynamic disk groups
- About creating dynamic volumes
- Set desired preferences
- Using the GUI to manage your storage
- Working with disks, partitions, and volumes
- Adding storage
- Disk tasks
- Remove a disk from the computer
- Veritas Disk ID (VDID)
- General Partition/Volume tasks
- Mount a volume at an empty folder (Drive path)
- Expand a dynamic volume
- Shrink a dynamic volume
- Basic disk and volume tasks
- Automatic discovery of SSD devices and manual classification as SSD
- Volume Manager space allocation is SSD aware
- Dealing with disk groups
- Disk groups overview
- Delete a dynamic disk group
- Detaching and attaching dynamic disks
- Importing and deporting dynamic disk groups
- Partitioned shared storage with private dynamic disk group protection
- Fast failover in clustered environments
- iSCSI SAN support
- Settings for monitoring objects
- Event monitoring and notification
- Event notification
- Configuring Automatic volume growth
- Standard features for adding fault tolerance
- Performance tuning
- FlashSnap
- FlashSnap components
- FastResync
- Snapshot commands
- Dynamic Disk Group Split and Join
- Dynamic disk group join
- Using Dynamic Disk Group Split and Join with a cluster on shared storage
- Dynamic Disk Group Split and Join troubleshooting tips
- Fast File Resync
- Volume Shadow Copy Service (VSS)
- Using the VSS snapshot wizards with Microsoft Exchange
- Using the VSS snapshot wizards with Enterprise Vault
- Using the VSS snapshot wizards with Microsoft SQL
- Copy on Write (COW)
- Using the VSS COW snapshot wizards with Microsoft Exchange
- Using the VSS COW snapshot wizards with Microsoft SQL
- Configuring data caching with SmartIO
- Typical deployment scenarios
- About cache area
- Configuring SmartIO
- Frequently asked questions about SmartIO
- Dynamic Multi-Pathing
- Configuring Cluster Volume Manager (CVM)
- Configuring a CVM cluster
- Administering CVM
- Access modes for cluster-shared volumes
- Storage disconnectivity and CVM disk detach policy
- Unconfiguring a CVM cluster
- Command shipping
- About I/O Fencing
- Administering site-aware allocation for campus clusters
- SFW for Hyper-V virtual machines
- Introduction to Storage Foundation solutions for Hyper-V environments
- Live migration support for SFW dynamic disk group
- Preparing the host machines
- Configuring the SFW storage
- Administering storage migration for SFW and Hyper-V virtual machine volumes
- Optional Storage Foundation features for Hyper-V environments
- Microsoft Failover Clustering support
- Configuring a quorum in a Microsoft Failover Cluster
- Implementing disaster recovery with Volume Replicator
- Troubleshooting and recovery
- Using disk and volume status information
- Resolving common problem situations
- Commands or procedures used in troubleshooting and recovery
- Rescan command
- Repair volume command for dynamic mirrored volumes
- Additional troubleshooting issues
- Disk issues
- Volume issues
- Disk group issues
- Connection issues
- Issues related to boot or restart
- Cluster issues
- Dynamic Multi-Pathing issues
- vxsnap issues
- Other issues
- CVM issues
- Appendix A. Command line interface
- Overview of the command line interface
- vxclustadm
- vxvol
- vxdg
- vxclus
- vxdisk
- vxassist
- vxassist (Windows-specific)
- vxsd
- vxedit
- vxdmpadm
- vxcbr
- vxsnap
- vxscrub
- sfcache
- Tuning SFW
- Appendix B. VDID details for arrays
Using a snapshot of a replica for mailbox database recovery in Database Active Group (DAG)
A snapshot of a replica can be used to restore an Exchange mailbox database to the point of failure (POF) or to a point in time (PIT). Taking a snapshot of a replica can be done through the VEA GUI by using either the VSS snapshot wizard or with the vxsnap CLI command. Taking a snapshot of a replica automatically takes a snapshot of all the volumes that the replica uses.
When SFW fails to automatically dismount the database during a restore operation, the restore operation fails. The restore operation can be performed again after manually dismounting the databases and manually setting the databases for overwrite by restore.
Although SFW lets you restore the database from a snapshot, restoring just the database log files is not supported.
For an Exchange 2010 database that is configured under VCS cluster, offline the corresponding VCS database resource before the restore operation if automatic offlining of resource database fails. SFW automatically offlines the resource databases. Once the restore operation completes successfully, online the VCS resource database.
In other configurations, SFW dismounts the databases before the restore operation and then mounts the databases after the restore operation automatically.
Using the -a option automatically dismounts and mounts the databases. For a VCS cluster setup, it offlines and onlines the resource databases.
Refer to Microsoft Exchange 2010 Shell Help for details on Exchange cmdlets.
An example of a PIT recovery procedure from a snapshot of a replica copy of an Exchange mailbox database
on an active mailbox database and Replica copy on would be as follows:Take Snapshot of the replica copy of mailbox database on
.Use the Move-ActiveMailboxDatabase cmdlet to perform the active mailbox database switchover from to .
Move-ActiveMailboxDatabase MB1 -ActivateOnServer TestServer2
Now
has the Active mailbox database and has Replica copy.Use the Suspend-MailboxDatabaseCopy cmdlet to block replication and replay activities (log copying and replay)
Suspend-MailboxDatabaseCopy -Identity DB1\TestServer1 [ - Confirm:$False]
Use -Confirm to prevent user intervention
Use the Set-MailboxDatabaseCopy cmdlet to configure the properties of a database copy and set check box for
set-mailboxdatabase -identity MB1\TestServer2 -allowfilerestore:$true
Use the Dismount-Database cmdlet to dismount the database
dismount-Database -Identity MB1\TestServer2 [-Confirm:$False]
Use -Confirm to prevent user intervention
For a VCS cluster setup, offline the Exchange 2010 VCS resource database if automatic offlining fails.
Now perform the VSS restore operation using snapshot of replica.
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=DB1 backupType=COPY -E -O
Use the Mount-Database cmdlet to mount database DB1
mount-Database -Identity DB1\TestServer2
For a VCS cluster setup, online the Exchange 2010 VCS resource database if automatic onlining of resource database fails.
Use the Update-MailboxDatabaseCopy
Update-MailboxDatabaseCopy -Identity MB3\TestServer2 -SourceServer TestServer1 - DeleteExistingFiles [-Confirm:$False]
Use -Confirm to prevent user intervention