SQL Virtual Restore 2.3

Walkthrough

This walkthrough of SQL Virtual Restore will show you:

• How to turn your backup into a live database, without a physical restore, to save time and space.

Contents:

Step 1: Selecting the SQL Server instance

Step 2: Selecting the backup files

Step 3: Specifying the destination and recovery state

Step 4: Viewing the restore summary

Step 5: Restoring the database virtually

Step 1: Selecting the SQL Server instance

For this walkthrough, we will use the SQL Virtual Restore wizard to mount a backup of AdventureWorks as a live database. Alternatively, we could use SQL Virtual Restore via T-SQL's native RESTORE DATABASE and RESTORE LOG commands.

The backup we are going to work with is a SQL HyperBac .hbc file, but we could also mount SQL Backup Pro or native SQL Server backups.

To begin the restore operation, we open the SQL Virtual Restore Wizard from the Start Menu.

Our first step in the wizard is to select the SQL Server instance that we want our database mounted on. In this case we're using the local instance, so we just click Next.

Step 2: Selecting the backup files

We now have to select the backup we want to mount, so we click the Add Files button and select the AdventureWorks backup file. Before we proceed, we can double-check that we have selected the correct backup file by name and date. We click Next to mount the backup file as a live database.

Step 3: Specifying the destination and recovery state

We now have to specify the destination database. We can create a new database or overwrite an existing database. For the purpose of this demo, we will create a new database called AdventureWorks_Virtual and select the default SQL Server data files directory.

We have three options for the recovery state of the virtual database: operational, non-operational and read-only.

• Operational: incomplete transactions are rolled back and our mounted database is fully operational. Additional transaction logs or differential backups cannot be restored. This is equivalent to a SQL Server RESTORE WITH RECOVERY operation.
• Non-operational: incomplete transactions are kept, and the database is not fully operational. Additional transaction logs or differential backups can be restored. This is equivalent to a SQL Server RESTORE WITH NORECOVERY operation.
• Read only: incomplete transactions are rolled back, with the undo actions saved in a log file. The database is fully operational, but the effects of the recovery can be reverted. Additional transaction logs or differential backups can be restored. This is equivalent to a SQL Server RESTORE WITH STANDBY operation.

Here, we can also specify that our backup should be verified with DBCC CHECKDB as part of the restore process. If we were only using our virtual restore for verification purposes, we could also specify that the database should be dropped automatically after this was complete.

For backup verification or object level recovery, operational recovery is recommended. In this case, we select Operational and click Next to proceed.

 

Step 4: Viewing the restore summary

We now need to confirm our choices. In the Summary pane, we can review the settings we have selected. We can also view the scripts that will be executed by clicking the View Scripts button.

SQL Virtual Restore is powered by HyperBac technology, and to start the restore operation, the HyperBac Service must be told to recognize our backup file extension type. Our backup was created with SQL HyperBac, so it is automatically recognized.

If you are working with SQL Backup Pro (version 6) or native SQL Server backups, the HyperBac Service is auto-configured to allow this restore. Once the backup is mounted, the HyperBac Service will revert to its original settings, so this will have no effect on future backups.

We click Restore to start the restore operation.

Step 5: Restoring the database virtually

SQL Virtual Restore has now mounted our backup as a live, fully functional database. We also get a report on our space saving. To close the wizard, we click OK. We can now go in to SQL Server Management Studio and work directly on the virtually restored AdventureWorks database. We might, for example, wish to recover a particular database object, or verify the backup with DBCC CHECKDB. Our data is transactionally consistent, and all objects are visible and available.

And that's it! If you would like to see how SQL Virtual Restore can help you, try it now with a free, fully functional and supported 14-day evaluation.