InfoScale™ 9.0 Storage Foundation Quick Recovery Solutions Guide for Microsoft SQL Server - Windows
- Introducing Quick Recovery for SQL Server
- Methods of implementing Quick Recovery snapshots for SQL Server
- About the components used in Quick Recovery
- Preparing to implement Quick Recovery for SQL Server
- Implementing Quick Recovery for SQL Server with the configuration wizard
- About the Quick Recovery Configuration Wizard
- Scheduling SQL Server snapshot sets
- Scheduling or creating an individual snapshot set for SQL Server
- Maintaining or troubleshooting snapshots
- Recovering a SQL Server database
- Recovering missing volumes
- Vxsnap utility command line reference for SQL Server
vxsnap restore
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.
Before using this command verify that the source volumes and the snapshot volumes are not in use.
The vxsnap restore command has the following syntax:
vxsnap -x Filename [-b] [-f] [-r] restore {RestoreType=[RECOVERY|NO_RECOVERY]} [noLogs|logFiles=tlog1,tlog2,...] writer=WriterName
The vxsnap restore command has the following attributes:
-x Filename | The metadata file 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 operation. Make sure the volume is not in use before using this option. |
-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. |
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 SQL 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 an 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 within SQL Server. |
writer=WriterName | The name for the SQL Server VSS Writer; used to located the default directory to search for the XML metadata file. Specify SQLServerWriter. |
Following are examples of the main types of restore operation:
Recovering using snapshots without log replay
vxsnap -x TestDB.xml restore RestoreType=RECOVERY noLogs
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
This command uses the information in the TestDB.xml file to restore all the volumes in the snapshot set. Any missing volume is changed from a read-only volume to a read-write volume. After using the -r option you must explicitly assign the original drive letter/mount path of the missing production volume to the snapshot volume in the VEA. You then bring the database online.
Recovering using snapshots and log replay
vxsnap -x TestDB.xml restore RestoreType=RECOVERY logFiles=c:\backup\tLog1.bak, c:\tLog2.bak
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
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.