vxsnap restore

Last published : Aug 04, 2026
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.
Syntax
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
Attributes
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 .
Examples
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.
Related information