Restore Databases Instantly with SQL Virtual Restore - Red Gate ...

Restore Databases
Instantly with
SQL Virtual Restore

Background
SQL Virtual Restore allows users to restore
databases without allocating the storage space that
would usually be required, creating a fully-functional
database which uses the backup file or files as the
primary data source. SQL Virtual Restore works
with SQL Server native backups (both compressed
and uncompressed), and with backups created
using Red Gate’s SQL Backup Pro or SQL
HyperBac. SQL Virtual Restore runs through the
HyperBac engine.
You do not need to alter or otherwise configure your
backup operations. This is the case whether you’re
taking native backups or making backups with Red
Gate’s tools.
A distinct advantage of SQL Virtual Restore is that
it can be used for backup verification, as well as
1
object level recovery and disaster recovery. Backup
verification with SQL Virtual Restore involves a
comprehensive test of a backup file, by creating a
virtual restore in the background and performing a
full integrity and consistency check on the resultant
virtualized database using DBCC CHECKDB. This
process checks the physical integrity of the pages
in the backup file and the logical integrity of each
object in the database; a RESTORE VERIFYONLY of
the backup set alone checks only that all pages are
contained in the backup file.
There are a number of advantages to backup
verification with SQL Virtual Restore:
• It takes much less time than an equivalent full
restore and DBCC CHECKDB, fitting comfortably in
most maintenance windows.
• It requires a near-zero data footprint.
• It’s fully scriptable using native T-SQL commands,
making it an easy addition to any backup/
maintenance program.
• The entire verification process can be offloaded
to a second server, removing any maintenance
overhead from the production server.
Backup verification is only one of many uses for
SQL Virtual Restore, but it’s a particularly important
one for early detection of production integrity issues
and to ensure successful disaster recovery.
Moreover, performing best practice backup
verification prepares your backup files so that you
can restore them as fully-functional, fully-available,
completely-recovered databases instantly, at any
point in the future.
Restore Databases Instantly
A backup verification operation using SQL Virtual
Restore involves the same set of steps needed to
make a backup file instantly available in the future.
When performing a virtual restore, the native SQL
Server RESTORE DATABASE sequence is
completed. This includes the recovery phase, where
changes made during the backup process are
applied to the virtual database, so that it includes
an exact representation of the data as it existed at
the end of the backup. SQL Virtual Restore creates
several files during this process:
• ‘Virtual’ data and log files (.vmdf, .vdnf, .vldf)
These files are used by SQL Server during recovery
and for any write activity to the virtual restore.
• Virtual restore index files
The backup file is indexed during the virtual restore
process, so that data can be quickly accessed from
the backup when the virtually restored database is
online.
These files have a minimal data footprint, in many
cases just a few MB. Along with the backup file
itself (or backup files, if you are striping backups),
these files provide you with all the necessary
components to restore your database instantly, with
1 Object level recovery is the process of extracting data (rows or entire tables or views), discrete objects, or object definitions from backup archives
without performing a full RESTORE operation.
2

no background recovery or population methods
necessary.
An Example
This example assumes SQL Virtual Restore is
installed with the default configuration.
Start by performing a backup. In this example, we
are using SQL Server 2008’s native compressed
backup format:
BACKUP DATABASE AdventureWorks
TO DISK = ‘C:\MSSQL\Backup\AdventureWorks_Native_Compressed_Backup.
bak’
WITH COMPRESSION
Optionally, you can perform a RESTORE
VERIFYONLY at this stage, but we will skip this for
the purpose of this example.
Now perform a virtual restore:
RESTORE DATABASE [AdventureWork_Virtual]
FROM
DISK = ‘C:\MSSQL\Backup\Adventure-
Works_Native_Compressed_Backup.bak’
WITH MOVE ‘AdventureWork_Data’ TO
‘C:\MSSQL\Backup\AdventureWork_AdventureWorks_Virtual.vmdf’
MOVE ‘AdventureWork_Log’ TO
‘C:\MSSQL\Backup\AdventureWork_1_AdventureWorks_Virtual.vldf’
NORECOVERY, STATS=1
GO
RESTORE DATABASE [AdventureWork_Virtual]
WITH RECOVERY, RESTRICTED_USER
GO
Note that this is a native T-SQL RESTORE
statement. The only directives for the underlying
virtual restore product are the .vmdf and .vldf file
extensions for the data and log file. In this case,
our virtual files were created in the backup
directory, but they can be stored in any location.
The virtualized database is brought online in
RESTRICTED_USER mode to prevent any other
access during the verification process.
The name of the virtualized database is arbitrary as
long as it does not conflict with the source
database name. If you use your own scripts and
assign a uniquely identifiable name for your
backups (such as a name which includes a
timestamp), consider using this name for the
virtualized database and datafiles (e.g. Adventure-
Works_Full_1212112100_Virtual). This makes the
files and database easily recognizable to any other
user and makes the process of association easier.
A virtualized database viewed from SQL Server
Management Studio
Virtual data and log files
3

The relevant HyperBac index files can be picked out
by the timestamp which coincides with the time the
virtual restore was initiated. These files are located
in the HyperBac\indexes directory. All files with this
timestamp are associated with the virtually restored
database:
These files will also need to be moved, if you
transfer a virtual restore to a remote server.
You can now perform the DBCC CHECKDB
operation against the virtually restored database to
fully validate the backup file. This step is not
technically necessary for an instant restore:
DBCC CHECKDB ([AdventureWorks_Virtual])
Now, rather than dropping the virtualized database,
detach it:
EXEC master.dbo.sp_detach_db @dbname =
N‘AdventureWorks_Virtual’
All of the necessary components are now in place
to instantly access the backup file at any point in
the future in a fully-recovered, operational state.
The additional files we have created so we can do
this require only a few MB of storage, so the
overheads are negligible. As an example, we’ll bring
the database online with its original name:
USE [master]
GO
CREATE DATABASE [AdventureWorks] ON
(FILENAME = N‘C:\MSSQL\Backup\AdventureWorks_AdventureWorks_Virtual.
vmdf’),
(FILENAME = N‘C:\MSSQL\Backup\AdventureWorks_1__AdventureWorks_Virtual.
vldf’)
FOR ATTACH
GO
The database is available instantly, in a fullyrecovered
state:
sp_helpdb ‘AdventureWorks’ produces the
output below:
4

Conclusion
SQL Virtual Restore can easily be embedded into
any environment, providing comprehensive backup
verification and allowing you to instantly restore
databases for object level recovery or disaster
recovery. These operations can be performed on
local or remote (UNC-based) backups, and the
process can be offloaded to a different server, to
eliminate the performance overheads of the
RESTORE and DBCC CHECKDB processes or
work around short maintenance windows.
This is also possible for instant restore operations;
simply move the files associated with a virtual
restore to a remote server and perform the attach
operation there.
To try it out, download a free trial of SQL Virtual
Restore today.
5