Technical overview - SQL Virtual Restore

SQL Virtual Restore runs as a Windows service (the HyperBac Control Service). You install the service on the SQL Server (Windows server) that will host your virtually restored databases. The HyperBac Control Service must be licensed to perform SQL Virtual Restore operations.

The HyperBac Control Service intercepts read and write requests from the SQL Server instance as they pass through the Windows file system. The service checks the file path and file extension of these requests, and matches them against data in a configuration file to determine whether they relate to SQL Virtual Restore operations.

A SQL Virtual Restore wizard is available to help you create virtually restored databases. The wizard checks that the HyperBac Control Service is correctly configured, then creates and runs the T-SQL RESTORE commands needed to virtually restore your databases. You can also run T-SQL RESTORE commands directly (for example, to virtually restore databases to a specific point-in-time using transaction log backup files).

Because the HyperBac Control Service runs inside the Windows kernel, it is invisible to the SQL Server instance. This means that you can use a virtually restored database exactly as you would use a normal SQL Server database (for example, by using SQL Server Management Studio), while taking advantage of SQL Virtual Restore's processing to minimize the footprint of the virtually restored database.

About the HyperBac Control Service security context

The HyperBac Control Service runs under the LocalSystem security context. The service uses the calling user, or process security token, for access control to user devices on the local system or remote systems.

Don't change the security context of the HyperBac Control Service, as other configurations are not supported.

Using a standard SQL Server database (without SQL Virtual Restore)

The following diagram shows the "Sales" database, attached to a SQL Server instance. During normal operations, with users running reports or entering data, for example, the SQL Server instance issues read and write requests via the Windows I/O Manager to access individual pages in the data files and records in the transaction log file:

When you back up this database, the backup data is written sequentially into backup files. A full backup (with optional differential backup) contains all the information necessary to restore and recover the database; with the database running in full recovery mode you can also use transaction log backups to recover the database to a specific point in time.

However, the data in the backup files is inaccessible unless you run a restore job to recreate the database files, and attach the database to a SQL Server instance. The restored database files may require a large amount of free disk space, and the restore job could take a long time to complete for a large database.

Using SQL Virtual Restore to run a fully functional database from a backup file

SQL Virtual Restore enables you to mount a backup file as a fully functional database, with substantial savings in disk space required and time needed when compared to running a standard restore job.

The following diagram shows a backup file mounted alongside data files and a transaction log file. The SQL Server instance sees a standard database: "Sales_Virtual"

The data files and transaction log file are created as part of the initial virtual restore process, and use very little disk space (256 KB each, on average). These files are required to maintain database consistency and integrity, but will not grow significantly unless you change substantial amounts of data. The backup file is never written to.

The SQL Server instance remains unaware that a backup file is being used as part of the "Sales_Virtual" database, and operates as normal, reading and writing pages of data and transaction log records.

The HyperBac Control service intercepts these read and write requests, and uses the backup file to supply the SQL Server instance with data as required.

SQL Virtual Restore configuration

To determine whether or not to intercept read and write requests from the SQL Server instance, the HyperBac Control Service checks the file path and file extension associated with each request.

The HyperBac Control Service matches the file path and extension against values stored in a plain-text configuration file (located at \Program Files\Red Gate\HyperBac\bin\hyperbac.conf by default). The configuration file also includes details of the type of processing that the HyperBac Control Service should apply (for example, encryption).

SQL Virtual Restore is pre-configured so that you can start using it immediately for virtual restore operations. It is unlikely that you will need to make any configuration changes. Additionally, the SQL Virtual Restore wizard will check and adjust the configuration when you create virtually restored databases.

However, to view or edit the configuration data yourself, use the HyperBac Configuration Manager application. Changes you make using this application are written to the hyperbac.conf configuration file.

Any changes you make to the configuration data take effect almost immediately; there may be up to a 30-second delay before SQL Virtual Restore starts to use the new configuration.

Never edit the hyperbac.conf file directly (using Notepad, for example); editing hyperbac.conf directly is not supported by Red Gate. Always use the HyperBac Configuration Manager application to edit configuration data.