InfoScale™ 9.0 Storage Foundation 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 Enterprise Vault
- Using the VSS snapshot wizards with Microsoft SQL
- Copy on Write (COW)
- 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
- Volume encryption
- Secure file system (SecureFS) for protection against ransomware
- 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
- vxschadm
- sfcache
- Tuning SFW
- Appendix B. VDID details for arrays
- Appendix C. Executive Order logging
vxsnap restore
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.
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.
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.