Recovering SQL Server Databases with Veeam: A Step-by-Step Guide for vSphere Environments

First: Which Backup Type Are You Working With?

Answer this before you touch anything else. The two paths split hard at restore time, and mixing up cmdlets or workflows between them is one of the most reliable ways to make a SQL restore fail in a way that does not give you a useful error message.

Application-aware image backup is the VM snapshot path. VBR takes a VSS-consistent snapshot of the VM, and with application-aware processing enabled, it ships transaction logs to the repository on a schedule you set. At restore time, Veeam Explorer mounts the backup to C:\VeeamFLR on the target, deploys a short-lived Veeam SQL Restore Service, copies the database files and log backups from that mount to the native filesystem, starts the database, then cleans up the mount and removes the service. The staging server only comes into play if you need to restore to a specific transaction.

Veeam Plug-in for Microsoft SQL Server is a native SQL Server backup -- no VM snapshots involved. It integrates directly with SQL Server's backup APIs and ships data straight to the Veeam repository. At restore time, the plug-in creates a VDI device on the target -- a virtual device that presents itself as backup storage to SQL Server -- and Veeam Data Movers stream the data from the repository directly into that device. No file copy to C:\VeeamFLR, no mount, no staging. The restore component on the target drives everything. It is a fundamentally different operation.

Here is the quick reference for what each path supports:

Prerequisites

This is your primary break-fix path. The database goes back to the same SQL instance it came from. Veeam takes it offline, restores the data files and applies the transaction logs, then brings it back online. The rest of the SQL instance stays up -- only the database being restored is affected.

1. In the VBR console, go to Home > Backups, find the job covering the SQL VM, right-click the restore point, and select Restore application items > Microsoft SQL Server databases. Veeam Explorer for Microsoft SQL Server opens.
2. Expand the SQL instance in the left pane to see the available databases. Give it a moment to populate -- the tree pulls metadata from the mounted backup.
3. Right-click the target database and select Restore database > To the original location.
4. On the Restore point page, choose your recovery target: restore point only (no log replay), point in time (log replay to a specific moment), or a specific transaction (requires staging server). For point-in-time, use the date and time picker to set your target.
5. If prompted for credentials, provide an account with sysadmin rights on the target SQL instance.
6. Review the summary and click Restore. Watch the task log at the bottom of Explorer for progress. You will see the database go offline, files restore, logs apply, and the database come back online.

Restore to original location -- point-in-time selection with log replay options visible in the restore wizard.

The plug-in restore path launches the same Veeam Explorer interface but reaches it differently -- via the plug-in backups node rather than the VM backup jobs.

1. In the VBR console, go to Home > Backups > Applications (or Plug-in backups depending on your VBR version). Locate the plug-in backup for the SQL host.
2. Right-click the backup and select Restore application items > Microsoft SQL Server databases. Veeam Explorer opens with the plug-in backup loaded.
3. Right-click the database and select Restore database > To the original location.
4. Select the restore point. Note that with plug-in backups you can restore to the latest state or to a point in time, but not to a specific transaction -- that option is only available from image-based backups.
5. Click Restore and monitor the task log.

Import-Module Veeam.Backup.PowerShell

# Get the VM backup and its most recent restore point
$backup       = Get-VBRBackup -Name "SQL-VM-Backup"
$restorePoint = Get-VBRRestorePoint -Backup $backup -Name "sql-vm-hostname" |
                Sort-Object CreationTime -Descending | Select-Object -First 1

# Start a VESQL restore session against that restore point
$session = Start-VESQLRestoreSession -RestorePoint $restorePoint

# Enumerate databases in the session and pick the one you want
$db = Get-VESQLDatabase -Session $session -Name "YourDatabase"

# Restore to original location -- latest state
Restore-VESQLDatabase -Database $db -RestoreToOriginalLocation

# To restore to a specific point in time instead:
# Restore-VESQLDatabase -Database $db -RestoreToOriginalLocation `
#     -RestoreToPointInTime (Get-Date "2024-11-01 03:45:00")

# Close the session when done
Stop-VESQLRestoreSession -Session $session

Import-Module Veeam.Backup.PowerShell

# Get the plug-in backup for the SQL host
$pluginBackup = Get-VESQLPluginBackup -Name "sql-host.example.com"

# Start a plug-in restore session
$session = Start-VESQLPluginRestoreSession -Backup $pluginBackup

# Enumerate available databases
$db = Get-VESQLPluginDatabase -Session $session -Name "YourDatabase"

# Check the available restore interval for this database
Get-VESQLPluginLogInterval -Database $db

# Kick off the restore -- this is async, poll for status
$restore = Start-VESQLPluginDatabaseRestore -Database $db -RestoreToOriginalLocation

# Poll until complete
do {
    Start-Sleep -Seconds 10
    $status = Get-VESQLPluginDatabaseRestore -Restore $restore
    Write-Host "Status: $($status.State)"
} while ($status.State -notin @("Success","Failed"))

Stop-VESQLPluginRestoreSession -Session $session

Use this when you need the database somewhere other than where it came from -- a different SQL instance, a different server, or under a different database name. This is your dev/test refresh path, your pre-production validation path, and your cross-environment migration path all in one.

1. Launch Veeam Explorer as in Path 1, steps 1 and 2.
2. Right-click the target database and select Restore database > To a different location.
3. On the Target server page, click Add and enter the destination SQL Server hostname or IP. Veeam will test connectivity and verify the SQL instance is reachable.
4. Set the Target database name. If you are restoring to the same instance under a new name, this prevents a collision with the existing database. If restoring to a completely different server, you can keep the original name.
5. Set the Target database files path -- this is where the MDF and LDF files will land on the destination server. The path must already exist on the target.
6. Select your recovery scope (restore point, point-in-time, or specific transaction) and provide sysadmin credentials for the destination instance.
7. Review the summary and click Restore.

Custom location restore -- setting the destination SQL instance, new database name, and target file path.

Import-Module Veeam.Backup.PowerShell

$backup       = Get-VBRBackup -Name "SQL-VM-Backup"
$restorePoint = Get-VBRRestorePoint -Backup $backup -Name "sql-vm-hostname" |
                Sort-Object CreationTime -Descending | Select-Object -First 1

$session = Start-VESQLRestoreSession -RestorePoint $restorePoint
$db      = Get-VESQLDatabase -Session $session -Name "YourDatabase"

# Restore to a different SQL instance under a new name
# -ServerName         : destination SQL Server host
# -InstanceName       : SQL instance name (use MSSQLSERVER for default instance)
# -DatabaseName       : new name for the restored database
# -DatabaseLocation   : path on the target server where data files will land
Restore-VESQLDatabase `
    -Database $db `
    -ServerName "sql-dest.example.com" `
    -InstanceName "MSSQLSERVER" `
    -DatabaseName "YourDatabase_Restore" `
    -DatabaseLocation "D:\SQLData\YourDatabase_Restore" `
    -RestoreToPointInTime (Get-Date "2024-11-01 03:45:00")

Stop-VESQLRestoreSession -Session $session

Import-Module Veeam.Backup.PowerShell

$pluginBackup = Get-VESQLPluginBackup -Name "sql-host.example.com"
$session      = Start-VESQLPluginRestoreSession -Backup $pluginBackup
$db           = Get-VESQLPluginDatabase -Session $session -Name "YourDatabase"

$restore = Start-VESQLPluginDatabaseRestore `
    -Database $db `
    -ServerName "sql-dest.example.com" `
    -InstanceName "MSSQLSERVER" `
    -DatabaseName "YourDatabase_Restore" `
    -DatabaseLocation "D:\SQLData\YourDatabase_Restore"

do {
    Start-Sleep -Seconds 10
    $status = Get-VESQLPluginDatabaseRestore -Restore $restore
    Write-Host "Status: $($status.State)"
} while ($status.State -notin @("Success","Failed"))

Stop-VESQLPluginRestoreSession -Session $session

This one is image-based only -- there is no equivalent in the plug-in path. It is also the most nuanced of the four paths, because it requires a staging SQL Server and has more moving parts than a straight database restore. That said, it is genuinely useful when someone drops or corrupts a table and you need just that object back without overwriting the whole production database.

What Veeam does here: it mounts the backup, restores the entire database to the staging server (including log replay to your target transaction if needed), lets you browse and select the tables or schema objects you want, then copies just those objects back to the production server -- either overwriting what is there or restoring them under a different name so you can compare. The staging server handles all the log replay work in isolation so production is never exposed to a partial restore state.

1. Launch Veeam Explorer from the VBR console using an image-based restore point as in Path 1, steps 1 and 2.
2. Right-click the target database and select Restore database schema and data.
3. On the Restore point page, set your recovery target -- restore point, point in time, or specific transaction. For specific transaction, Veeam will replay logs on the staging server and show you each transaction in a browsable list.
4. On the Target server page, specify the destination SQL instance where you want the recovered objects to land. This can be the original production instance.
5. On the Database objects page, expand the database tree and select the specific tables or schema objects to restore. You can select individual tables, entire schemas, or the full database object tree.
6. On the Names for restored objects page, choose whether to restore objects with their original names (which will overwrite existing objects) or add a prefix or suffix so the restored objects land alongside the originals for comparison.
7. Complete the wizard and click Restore. Veeam will restore the full database to the staging server, extract the selected objects, and transfer them to the target instance.

Staged table restore -- browsing the database schema and selecting individual tables for recovery to the production instance.

Export gives you a copy of the database as native SQL Server backup files (.bak) that you can take anywhere -- another environment, an isolated network, a different team. No live SQL instance required at the destination. This path is image-based only.

1. Launch Veeam Explorer from an image-based restore point as in Path 1, steps 1 and 2.
2. Right-click the target database and select Export database.
3. Specify the destination folder. This can be a local path on the machine running VBR or Explorer, or a UNC path to a network share. Make sure there is enough space for the full database backup plus transaction logs.
4. Set the recovery scope: restore point, point in time, or specific transaction.
5. Click Export. Veeam will restore the database to the export path as a standard SQL Server backup set (.bak files). These files can be restored using native SQL Server RESTORE DATABASE commands or SSMS on any compatible SQL Server instance.

Import-Module Veeam.Backup.PowerShell

$backup       = Get-VBRBackup -Name "SQL-VM-Backup"
$restorePoint = Get-VBRRestorePoint -Backup $backup -Name "sql-vm-hostname" |
                Sort-Object CreationTime -Descending | Select-Object -First 1

$session = Start-VESQLRestoreSession -RestorePoint $restorePoint
$db      = Get-VESQLDatabase -Session $session -Name "YourDatabase"

# Export as a native SQL Server .bak file set
# The destination folder will be created if it does not exist
Export-VESQLDatabase `
    -Database $db `
    -Path "D:\SQLExports\YourDatabase_20241101" `
    -RestoreToPointInTime (Get-Date "2024-11-01 03:45:00")

# To export to latest state, omit -RestoreToPointInTime entirely

Stop-VESQLRestoreSession -Session $session

Instant Recovery (Publish Database from Backup)

Instant Recovery for SQL is different from all four paths above. Instead of copying data to a target server and starting the database there, Veeam mounts the backup via iSCSI and attaches the database directly to a SQL instance -- the database is available within seconds, running live from the repository. This is your fastest path to RTO: the application is back up immediately while a full data migration runs in the background, or you can use it purely as a validation tool to confirm what is actually in a backup before committing to a production restore.

The tradeoff is real: performance is constrained by repository connection speed, and any writes go to a cache on the mount server while the background copy catches up. It is not a permanent solution. Treat it as a bridge -- get the application online, then finish the switchover to local storage or unpublish and move on. Do not leave databases running from the repository for extended periods.

1. Launch Veeam Explorer from an image-based restore point.
2. Right-click the target database and select Publish database.
3. Specify the target SQL Server instance where the database will be attached. This can be the production instance or a separate validation host.
4. Set a target database name for the published copy -- something distinct from the production database name if you are attaching to the same instance.
5. Select the recovery scope and click Publish. The database will be attached and available within seconds -- no data copy required.
6. When ready to switch over to production storage, right-click the published database in Explorer and select Switch to production. Veeam will migrate the files in the background and detach from the repository when done. To discard without switching over, select Unpublish.

Import-Module Veeam.Backup.PowerShell

$backup       = Get-VBRBackup -Name "SQL-VM-Backup"
$restorePoint = Get-VBRRestorePoint -Backup $backup -Name "sql-vm-hostname" |
                Sort-Object CreationTime -Descending | Select-Object -First 1

$session = Start-VESQLRestoreSession -RestorePoint $restorePoint
$db      = Get-VESQLDatabase -Session $session -Name "YourDatabase"

# Publish the database -- attaches it to the target SQL instance directly from backup
Publish-VESQLDatabase `
    -Database $db `
    -ServerName "sql-prod.example.com" `
    -InstanceName "MSSQLSERVER" `
    -DatabaseName "YourDatabase_Published"

# Check published database state
$published = Get-VESQLPublishedDatabase -Session $session
Write-Host "Published DB state: $($published.State)"

# --- When ready to migrate to production storage ---
# Build switchover options and switch over
$switchOptions = New-VESQLIRSwitchOverOptions `
    -DatabaseLocation "D:\SQLData\YourDatabase"

Switch-VESQLIRDatabase `
    -Database (Get-VESQLIRDatabase -Session $session -Name "YourDatabase_Published") `
    -SwitchOverOptions $switchOptions

# --- OR, to discard without switching ---
Unpublish-VESQLDatabase -Database $published

Stop-VESQLRestoreSession -Session $session

Post-Recovery Verification

Run these checks after any restore path before handing the database back to application teams. A restore that completes without errors is a good start -- it is not the same as a database that is actually healthy.

Confirm the Database is Online

-- Check database state and recovery model
SELECT
    name,
    state_desc,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE name = 'YourDatabase';

-- You want:
-- state_desc        = ONLINE
-- recovery_model_desc = FULL (if it was FULL before restore)
-- If state_desc shows RESTORING, the restore did not complete correctly

Verify the Recovery Point

-- Confirm the last restore time and the recovery stop point
SELECT
    restore_date,
    destination_database_name,
    user_name,
    backup_finish_date,
    restore_type
FROM msdb.dbo.restorehistory
WHERE destination_database_name = 'YourDatabase'
ORDER BY restore_date DESC;

Check the SQL Server Error Log

-- Scan the current error log for anything that looks wrong post-restore
EXEC sp_readerrorlog 0, 1, 'YourDatabase';

-- A clean restore ends with a line similar to:
-- "Recovery completed for database YourDatabase"
-- No errors referencing the database after that line is what you want

Run DBCC CHECKDB

-- Run a full integrity check -- worth the time before going back into production
-- On large databases, run with NO_INFOMSGS and PHYSICAL_ONLY first for speed
DBCC CHECKDB ('YourDatabase') WITH NO_INFOMSGS;

-- Zero errors reported = you are good
-- If CHECKDB returns errors, do not put the database into production service
-- until you understand and resolve what it found