Veeam Explorer for SQL Server: Granular Database Recovery in v13

Veeam Explorer for SQL Server: Granular Database Recovery in v13

Veeam v13 Series | Component: Veeam Explorer for Microsoft SQL Server | Audience: DBAs, Infrastructure Engineers, Backup Administrators

1. What Veeam Explorer for SQL Server Actually Does

Veeam Explorer for Microsoft SQL Server is a recovery tool that operates against VBR backup restore points. It mounts the backup, locates the SQL Server data and log files inside the image, and presents the full instance and database hierarchy in a browsable interface. From there you can restore entire databases, recover to a specific point in time using transaction log replay, roll back to the state before a specific transaction, instantly publish a database from backup, or export individual schema objects and table data.

It works against backups from VM-level jobs (vSphere, Hyper-V, AHV), agent-based backups (Veeam Agent for Windows), and backups created by the Veeam Plug-in for Microsoft SQL Server. The data source does not change the recovery workflow. If VBR has a restore point and that restore point contains a SQL Server instance, Explorer can work with it.

Explorer launches from the VBR console under the Restore menu or directly from the Windows Start menu. It can also be driven entirely through PowerShell using the Veeam.SQL.PowerShell module for automated recovery workflows.

2. Prerequisites: Transaction Log Backup Configuration

Point-in-time restore only works if you are backing up transaction logs. Without log backups, you can only restore to the exact time each backup restore point was created. That is the single most important thing to understand about SQL granular recovery in Veeam.

Transaction log backup is configured inside the VBR backup job, not inside SQL Server. In the job's Guest Processing settings, enable application-aware processing, then click through to the SQL tab for the target VM.

Configuring Transaction Log Backup

1. 1Edit the backup job. Go to the Guest Processing step.
2. 2Enable Application-aware processing.
3. 3In the VSS Settings section, select Process transaction logs with this job.
4. 4Switch to the SQL tab. Select Backup logs periodically.
5. 5Set the log backup interval. 15 minutes is common for production databases. This defines your RPO for SQL data between image-level restore points.
6. 6Set retention for log backups. This determines how far back you can perform point-in-time recovery between restore points.

VBR stores transaction log backups as .vlb files alongside the image-level backup chain. These are proprietary format files. You cannot extract native .trn files from them directly through the VBR interface. The logs are consumed by Veeam Explorer during point-in-time recovery.

3. Recovery Models and Why They Matter

SQL Server controls whether transaction logs are maintained through its recovery model setting. This is a per-database property, not a server-level setting.

Check the recovery model for your databases before assuming point-in-time restore will work:

If you see Simple and you need point-in-time recovery, change the model. The change takes effect immediately. No restart required.

4. Restore Scenarios

Veeam Explorer for SQL Server supports five distinct recovery operations. Each serves a different purpose and has different prerequisites.

All operations can target the original SQL Server instance or an alternate server and instance. Restoring to an alternate instance is the standard approach for validation and testing without impacting production.

5. Point-in-Time Restore with Transaction Log Replay

This is the most valuable recovery scenario for production SQL environments. When a DBA calls you at 2 AM because someone ran a bad UPDATE statement at 1:47 AM, this is how you get the database back to 1:46 AM.

How It Works Under the Hood

VBR mounts the backup image and locates the SQL data files (.mdf, .ndf) and the Veeam transaction log backups (.vlb files). Explorer identifies the restore point closest to (but before) your target timestamp, then replays the transaction logs forward from that restore point until it reaches the timestamp you specified. The log replay happens on the target SQL Server. Explorer copies the transaction log files from the backup repository to the Windows machine hosting the target server, then the SQL Server engine applies them.

Performing the Restore

1. 1Open Veeam Explorer for SQL Server from the VBR console: Backups > right-click the restore point > Restore application items > Microsoft SQL Server databases.
2. 2The Explorer opens and mounts the backup. Browse the instance tree in the left pane to find your database.
3. 3Right-click the database and select Restore database > Restore point-in-time state.
4. 4In the Point in Time dialog, select the target timestamp. The available time range is shown based on the restore points and transaction log backups VBR has for this database.
5. 5Choose the restore target: original location or another server/instance. If restoring to the original location, the existing database is overwritten.
6. 6Specify credentials for the target SQL Server and Windows guest OS access. Explorer needs both to deploy its runtime component and perform the restore.
7. 7Review the summary and start the restore. Monitor progress in the Explorer session log.

6. Restore to a Specific Transaction

This scenario is for when you know exactly which transaction caused the damage and you want to roll the database back to the state immediately before that transaction executed. It requires a staging SQL Server in addition to the target server.

The staging server is used to replay the logs and present a list of transactions. You browse the list, identify the bad transaction (an errant DELETE, a schema change, a bulk UPDATE that corrupted data), select it, and Explorer restores the database to the state just before that transaction was committed.

This is more precise than point-in-time restore because you are targeting a specific operation rather than a timestamp. It is also slower because the staging server has to replay and index every transaction in the log chain.

7. Instant Database Recovery

Instant recovery publishes a database directly from the backup via iSCSI without waiting for a full data copy. The database comes online in minutes regardless of size. A 3 TB database takes the same amount of time to publish as a 3 GB database because no data is being copied at publish time.

How It Works

Explorer sends an instant recovery command to the Veeam Mount Service on the mount server associated with the backup repository. The mount service starts two parallel iSCSI sessions. The first session mounts the database files from backup to the C:\VeeamFLR directory on the target server and attaches the database to the target SQL instance. This is the published database. It is live, accepting reads and writes immediately.

The second session copies the database files from backup to the target server's native storage in the background. All writes to the published database during this copy are captured in a write cache on the mount server (default location: C:\ProgramData\Veeam\Backup\IRCache\). When the background copy finishes, you perform a switchover. During switchover, the published database stops briefly, the write cache is synchronized to the recovered copy, the published database is dropped, and the recovered database starts.

The instant recovery session is resilient to network disruption and mount server crashes. If the connection is lost, the session retries automatically 10 times at 5-minute intervals before giving up.

You can close Veeam Explorer after starting an instant recovery session. The session is managed by the Veeam Explorers Recovery Service on the mount server, not by the Explorer console. Reopen Explorer later to monitor progress or perform the switchover.

8. Database Publishing

Publishing is similar to instant recovery but without the background data copy and switchover. It temporarily attaches a database from backup to the target SQL Server as a read-write mount. The database stays live as long as the Explorer session is open. When you close Explorer (or explicitly unpublish), the database is detached and the mount point is cleaned up.

Publishing is useful for data verification, extracting specific records, or running queries against a backup without committing to a full restore. If someone asks "can you check if the customer record existed in last night's backup?" you publish the database, run a SELECT, and close it. No restore needed.

9. Schema and Table-Level Export

You do not always need to restore an entire database. Sometimes you need one table, one stored procedure, or just the schema definition. Explorer supports granular export of individual database objects.

1-Click Schema Export

Select a database in the navigation pane, then use Export Schema on the Database tab. Explorer exports the database schema (tables, views, stored procedures, functions, indexes) as .sql script files to your desktop. This is the fastest way to get a schema snapshot from backup.

Custom Schema and Data Export

For table-level data export, right-click the database and select Export schema and data. This opens a wizard where you can select specific tables and choose to export as .mdf data files or .sql scripts. The export runs on the machine where Explorer is installed.

Table-level export does not support every table type. Stretch Database tables, system-versioned temporal tables, and tables with certain external dependencies cannot be exported individually. For those, you need a full database restore.

10. PowerShell Automation

Every operation in Veeam Explorer for SQL Server can be automated through the Veeam.SQL.PowerShell module. This is separate from the main VBR PowerShell module and has its own set of cmdlets.

Key Cmdlets

Example: Automated Database Restore to Alternate Instance

For scheduled recovery testing (restore a production database to a dev instance nightly to validate recoverability), wrap this in a scheduled task running under a service account with Veeam Restore Operator privileges.

11. Limitations and Gotchas

Explorer must stay open during restore, publish, and export operations. If the user who launched Explorer logs out or is logged out by a session timeout policy, the operation terminates. The only exception is instant recovery, which is managed by the Veeam Explorers Recovery Service and survives console closure.

CDP replicas do not support point-in-time SQL recovery. CDP policies do not copy SQL transaction logs. You can only restore to the latest state of a long-term restore point. Short-term restore points are not supported for SQL Explorer operations.

Replication jobs do not support point-in-time SQL recovery. Same reason. Replication jobs do not copy transaction logs. You get latest-state restore only.

Transaction log files are stored as .vlb files. You cannot extract native .trn files from VBR's log backups through the standard interface. If you need raw .trn files for a manual SQL restore (for example, to initialize an AlwaysOn availability group replica), you would need to work with Veeam support or use native SQL log backups for that specific operation.

Instant recovery requires free drive letters. Each volume mounted from backup consumes two drive letters (one for the published mount, one for the background copy). For failover cluster instant recovery, every node needs the free drive letters. Plan your drive letter assignments if you have SQL Servers with many volumes.

Table-level restore has type restrictions. Stretch Database tables, system-versioned temporal tables, and tables with external dependencies cannot be individually exported. Use full database restore for those objects.

The Replace logic does not work for schema objects. If you are restoring individual schema objects (stored procedures, views) and a conflicting object exists in the target database, the restore will not automatically replace it. Drop the existing object first or restore to an alternate location.

Encrypted database restore requires extra steps. Encrypted databases need the certificate and master key available on the target server before restore. Veeam has a KB article covering the specific procedure. If you restore an encrypted database to an alternate server that does not have the encryption certificate, the attach will fail.

Veeam Installer Service avoids admin share dependency. If you want Explorer to deploy its runtime component to the target SQL Server without needing access to the administrative share (C$), pre-install the Veeam Installer Service on the target. This is a common requirement in hardened environments where admin shares are disabled.