Storage Foundation 7.4.1 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
vxsnap restore
For Exchange operations:
vxsnap -x <Filename> [-f] [-b] [-r] [-a] restore restoreType=<PIT|POF> writer=WriterName [subComponent=<subComponentName>]
Uses the snapshot volumes in a snapshot set created by the vxsnap create command to restore data, for example, after an original volume has become corrupted. You can restore the data either to the point in time that the snapshot set was last refreshed or to the point of failure of a single database.
(COW snapshots can be used with this command.)
Note:
For Exchange 2010, Restore to Recovery Database is not supported in SFW.
Note:
After completing a point of failure (POF) recovery of a single database, Veritas recommends using the vxsnap reattach command to reattach and resynchronize the other databases in the Exchange DAG and to use the vxsnap create command to create a new snapshot set.
Implementing the point of failure recovery requires that the writer=WriterName and the component=<ComponentName> parameters were specified when the snapshot set was created.
The following attributes apply:
-x <Filename> | The file that is created by the vxsnap create command. Each snapshot set must have a unique name for the metadata file. When the full path for the <Filename> is not specified, the writer=<WriterName> attribute is required. |
-f | Forces the snapback. Make sure that the volume is not in use by another application before using this command. Use this option with care. |
-b | Resynchronizes the volume in the background. A new snapshot cannot be made until the resynchronization is complete. |
-r | Recover one or more of the original missing volumes. The following example shows additional required steps. This option cannot be specified to recover using a COW snapshot. |
-a | Dismount the databases before the restore operation and then mount the database after the restore operation. |
restoreType=<PIT|POF> | PIT specifies a restore to the point in time that the snapshot set was created or last refreshed. POF specifies a roll-forward recovery to the point of failure. |
writer=WriterName | The name for the Exchange Server VSS Writer; used to locate the default directory to search for the XML metadata file. |
subComponent=<subComponentName> | Name of the subcomponent to be restored. In Exchange, a subcomponent is a mailbox store (database). Use this attribute only in a point of failure recovery. Note: The subcomponent attribute is not supported for Exchange 2010. |
Note:
Before using this command, make sure that the source volumes and the snapshot volumes are not in use. Use the [-a] attribute to dismount and mount the databases automatically or use the Exchange System Manager to dismount all the databases in the DAG and then mount them after the command is completed.
Examples
vxsnap -x snapdata.xml restore writer="Microsoft Exchange Writer"
This command uses the information in the snapdata.xml file to restore all the volumes in the snapshot set identified in that file to the point in time the snapshot set was created or last refreshed.
Point-in-time recovery
vxsnap -x snapdata.xml restore restoreType=PIT writer="Microsoft Exchange Writer"
This command uses the information in the snapdata.xml file to restore all the volumes in the snapshot set identified in that file to the point in time the snapshot set was created or last refreshed.
Roll-Forward Recovery to the Point of Failure
vxsnap -x snapdata.xml restore restoreType=POF writer="Microsoft Exchange Writer"
This command uses the information about the storage group that is specified in the snapdata.xml file to snapback the database volumes and then use current transaction logs to roll forward to the point of failure.
Roll-Forward Recovery to the Point of Failure of a Single Database
vxsnap -x snapdata.xml restore restoreType=POF writer="Microsoft Exchange Writer" subcomponent=DB1
This command restores the specified database (subcomponent) DB1 and then uses current transaction logs to roll forward only that database to the point of failure.
Recovery After Hardware Failure
You can use the -r switch to perform a VSS-integrated recovery after a hardware failure. The following recovery scenarios are possible if the complete snapshot set including the XML metadata file is available.
Note:
For more information about the -r switch, see the Snapshot Solutions section in the Storage Foundation and High Availability Solutions HA and Disaster Recovery Solutions Guide for Microsoft Exchange, which is included with the software.
Complete the following tasks to perform a VSS-integrated recovery:
Identify the snapshot volume that is associated with each missing production volume. Note the drive letter or mount point of each volume.
Use Exchange System Manager to dismount all remaining databases in the storage group.
Delete the missing volumes from Storage Foundation for Windows.
Replace the failed hardware and add the new disks to the dynamic disk group.
Reassign the drive letters or mount points of the snapshot volumes so that they are the same as the missing production volumes.
Perform a VSS-integrated recovery by including the -r switch in the vxsnap restore command. For example, type:
vxsnap -x snapdata.xml -r restore restoreType=PIT writer="Microsoft Exchange Writer"
This command uses the information the snapdata.xml file to restore all the volumes in the snapshot set identified in that file to the point in time the snapshot set was created or last refreshed.
Warning:
Before using the vxsnap restore command, verify that you have correctly assigned the drive or mount point to each volume and that you have accounted for all the volumes in the storage group (component).
For Enterprise Vault operations
vxsnap -x <Filename> [-b] [-f] [-r] [-a] restore writer=WriterName [site=<siteName>[/VSG=<VSGName>[/VS=<VSName>]]] [[/]component=<ComponentName>] {RestoreType=[RECOVERY|NO_RECOVERY]}
Uses the snapshot volumes in a snapshot set created by the vxsnap create command to recover a corrupted or missing Enterprise Vault component.
Exclusive access to the Enterprise Vault component is required for this operation.
Before using this command verify that the source volumes and the snapshot volumes are not in use.
The following attributes apply:
-x <Filename> | The file that is created by the vxsnap create command. Each snapshot set must have a unique name for the metadata file. |
-b | Resynchronizes the volume in the background. A new snapshot cannot be made until the resynchronization is complete. |
-f | Forces the snapback. Use this option with care. |
-r | Recover even if original volume is not present. If this option is selected and the original volume is not present, the snapshot volume of the missing volume is changed from a read-only volume to a read-write volume. |
-a | Dismount the databases before the restore operation and then mount the database after the restore operation. |
writer=<WriterName> | Unique ID of the VSS writer, for example, EnterpriseVault or the GUID for the writer. |
site=<SiteName> | Name of the Enterprise Vault site. |
VSG=<VSGName> | Name of the Enterprise Vault Store Group. |
VS=<VSName> | Name of the Enterprise Vault Store. |
component=<ComponentName> | Name of the Enterprise vault component. For example, Vault Store database, Fingerprint database, or Volume component, such as index, partitions, etc. |
restoreType= [RECOVERY|NO_RECOVERY] | Specifies the type of database recovery, either recovery, or no recovery: With RECOVERY database and transaction log files are restored from the snapshot set. No transaction backup logs are applied. The database is left in an operational state. To back up logs so that you can restore the database using log replay, at least one Full backup must have been created earlier. NO_RECOVERY restores from the specified snapshot set to the time of the snapshot. No logs are applied and the database is left in a loading state so that you can manually replay backup logs to a specific point in time. |
Note:
Upon completion of the operation, the status (success or failure) of the selected components is recorded in a log, %VMPATH%\logs\EVStatus.log. The log contains information about the success or failure of the operation for the components. In the event that the restore of a volume for a component fails, the operation continues to restore the remaining volumes of the component and any other requested components. The components that successfully complete the operation are removed from the snapshot set. If the operation succeeds for all the volumes of a component, then the status of the component is logged as a success. If the operation fails for any one of the volumes of the component, then the status of the component is logged as a failure along with the cause of failure.
The following is an example of the command.
vxsnap -x snapdata.xml -a restore RestoreType=RECOVERY writer=EnterpriseVault site=site1/vsg=vsg1/vs=vs1 component="Directory DB"
This command restores the vault store vs1 and component Directory DB using the metadata from snapdata.xml.
For SQL operations:
vxsnap -x <Filename> [-f] [-b] [-r] restore [restoreType=[RECOVERY|NO_RECOVERY]] [noLogs|logFiles=<tlog1,tlog2,...>] writer=WriterName
Uses the snapshot volumes in a snapshot set created by the vxsnap create command to recover a corrupted or missing SQL Server database. Exclusive access to the SQL Server database is required for this operation.
(COW snapshots can be used with this command.)
Before using this command verify that the source volumes and the snapshot volumes are not in use.
The following attributes apply:
-x <Filename> | The file that is created by the vxsnap create command. Each snapshot set must have a unique name for the metadata file. When the full path for the <Filename> is not specified, the writer=<WriterName> attribute is required. |
-f | Forces the snapback. Make sure that the volume is not in use by another application before using this command. Use this option with care. |
-b | Resynchronizes the volume in the background. A new snapshot cannot be made until the resynchronization is complete. |
-r | Recover even if original volume is not present. If this option is selected and the original volume is not present, the snapshot volume of the missing volume is changed from a read-only volume to a read-write volume. Use this option only with Recovery noLogs. After using this option you must explicitly assign the original drive letter/mount path of the missing volume to the snapshot volume in the VEA and then bring the database online. This option cannot be specified to recover using a COW snapshot. |
restoreType= [RECOVERY|NO_RECOVERY] | Specifies the type of database recovery, either recovery, or no recovery: RECOVERY can be used with either the noLogs or logFiles=tlog1,tlog2,.... attributes. RECOVERY leaves the database in an online state. To back up logs so that you can restore the database using log replay, at least one Full backup must have been created earlier. NO_RECOVERY restores from the specified snapshot set to the time of the snapshot. No logs are applied and the database is left in a loading state so that you can manually replay backup logs to a specific point in time. |
noLogs | Database and transaction log files are restored from the snapshot set. No transaction backup logs are applied. The database is left in an operational state. |
logFiles=tlog1,tlog2,... | Transaction log backup files to be applied with the RECOVERY option to achieve a point of failure recovery and leave the database in an online state. Each transaction log must have a unique name and be created using the "overwrite existing media" option. |
writer=WriterName | The name for the SQL Server VSS Writer; used to locate the default directory to search for the XML metadata file. Specify SQLServerWriter. |
The following are examples of the command:
Recovering using snapshots without log replay
vxsnap -x TestDB.xml restore RestoreType=RECOVERY noLogs writer=SQLServerWriter
This command uses the information in the TestDB.xml file to restore all the volumes in the snapshot set and brings the database online. The database is restored to the time the snapshot set was created or last refreshed.
You can use the -r option with the RECOVERY noLogs restore type if a production volume is missing due to hardware failure:
vxsnap -x TestDB.xml -r restore RestoreType=RECOVERY noLogs writer=SQLServerWriter
Recovering using snapshots and log replay
vxsnap -x TestDB.xml restore RestoreType=RECOVERY logFiles=c:\backup\tLog1.bak, c:\tLog2.bak writer=SQLServerWriter
This command uses the information in the TestDB.xml file to restore all the volumes in the snapshot set and then applies the specified transaction log backups (c:\backup\tLog1.bak and c:\tLog2.bak) and brings the database online.
Restoring snapshots and manually applying logs
vxsnap -x TestDB.xml restore RestoreType=NO_RECOVERY writer=SQLServerWriter
This command uses the information in the TestDB.xml file to restore all the volumes in the snapshot set and leaves the database in a loading state so that backup logs can be manually restored to a specific point in time.
Note:
For more information about the -r switch, see the Storage Foundation and High Availability Solutions Quick Recovery and Microsoft Clustering Solutions Guide for Microsoft SQL.
For volume operations:
vxsnap -x <Filename> [-f] [-b] [-r] restore RestoreType=PIT [<Volumename|Driveletter|DrivePath> ...]
Uses the snapshots in a snapshot set created by the vxsnap create command to restore data, for example, after an original volume has become corrupted.
(COW snapshots can be used with this command.)
The following attributes apply:
-x <Filename> | The file that is created by the vxsnap create command. Each snapshot set must have a unique name for the metadata file. |
-f | Forces the snapback. Make sure that the volume is not in use by another application before using this command. Use this option with care. |
-b | Resynchronizes the volume in the background. A new snapshot cannot be made until the resynchronization is complete. |
-r | Recover one or more of the original volumes are missing. This option cannot be specified to recover using a COW snapshot. |
RestoreType=<PIT> | PIT specifies a restore to the point in time that the snapshot set was created or last refreshed. |
VolumeName | Name of volume. For example, \Device\HarddiskDmVolumes\DynamicGroup\Volume1. |
DriveLetter | Drive letter of the volume. |
DrivePath | Drive path of the volume. |
Examples
vxsnap -x snapdata.xml restore RestoreType=PIT
This command uses the information in the snapdata.xml file to restore all the volumes in the snapshot set to the point in time the snapshot set was created or last refreshed.