When a full restore is the wrong move
When SQL breaks, the first request is usually narrower than “restore the VM.” More often it is “get this database back to before the bad change” or “show me what was in last night’s backup.” That is the sort of job Veeam Explorer for Microsoft SQL Server handles well.
It opens a SQL-aware view into a Veeam Backup & Replication restore point and lets you pick the recovery method that fits the problem in front of you: restore a database, recover to a specific time, roll back to just before a bad transaction, publish a database from backup, run instant recovery, or export schema and data without rebuilding an entire machine.
If the backup captured SQL correctly, the workflow is familiar whether the source came from a VM backup, Veeam Agent for Windows, or the Veeam Plug-in for Microsoft SQL Server. You can launch the Explorer from the VBR console, from the Windows Start menu, or through PowerShell. Opening the tool is easy. The part that matters is whether the backup job, SQL settings, and target environment were ready before you needed them.
Start with transaction logs
If logs are not being captured, your recovery window ends at the image-level restore point. That is fine for some incidents, but not for the 1:47 AM bad update scenario where the question is “how close can we get to the moment before it went wrong?”
In Veeam, log handling is configured in the backup job, not inside SQL Server. On the Guest Processing side, enable application-aware processing, tell the job to process transaction logs, then turn on periodic SQL log backups. In most production environments, starting with a 15-minute interval is reasonable and then adjusting from there based on what the application can tolerate. That interval is what really sets your SQL RPO between image-level restore points.
VBR stores those logs as .vlb files rather than native .trn files. Explorer knows how to use them during recovery, but that distinction matters if you were expecting raw SQL log backup files for some other workflow.
I would also keep log ownership clean. If Veeam is handling transaction logs for a database, I would not leave a SQL maintenance plan or another product truncating that same chain. Sooner or later that creates gaps, and gaps are what kill a clean point-in-time restore.
Check the recovery model early
The next thing I verify is the recovery model, because people are often sure it is right until they actually query the database. If a database is in Simple recovery, the point-in-time conversation is over before it starts. Full is usually the setting you want. Bulk-logged can still work, but I treat it cautiously around heavy bulk operations because granularity can change.
A quick check looks like this:
SELECT name, recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;
If you find a database in SIMPLE and you need point-in-time restore, change it like this:
ALTER DATABASE [YourDatabase] SET RECOVERY FULL;
No restart is required.
What the Explorer is actually good at
What makes the SQL Explorer useful is not that it has a long feature list. It is that the recovery path can match the mess you are dealing with. Sometimes the latest good copy is all you need. Sometimes the exact timestamp matters. Sometimes you know the transaction that did the damage. Sometimes the business just wants the application back online as fast as possible. And sometimes there is no need for a restore at all because publishing the database or exporting one object answers the question faster.
Whenever I can, I restore to an alternate instance first. It is the cleaner place to validate assumptions before I touch production.
Point-in-time restore in practice
This is usually the recovery path teams care about most. Explorer mounts the backup, finds the SQL data files plus the Veeam log backups, identifies the restore point just before the target time, and replays forward until it reaches the timestamp you selected. The log replay happens on the target SQL Server. Explorer copies what it needs from the repository, and SQL Server applies the logs.
The UI workflow is straightforward:
- Open the restore point in VBR and choose Restore application items > Microsoft SQL Server databases.
- Let Explorer mount the backup and load the SQL instance tree.
- Find the database.
- Choose Restore database > Restore point-in-time state.
- Select the target time.
- Pick the original or alternate target instance.
- Provide the required SQL and guest OS credentials.
- Start the restore and watch the session log.
The wizard itself is not complicated. The real limitation is the log coverage you already have. With 15-minute backups, you can usually get close. With hourly logs, the outcome is naturally rougher. Explorer cannot replay what was never captured.
When transaction-level restore is worth the extra work
Sometimes a timestamp still is not precise enough. You know which transaction caused the damage, and you want to land just before that specific operation committed. That is where transaction-level restore helps.
It is more exact than a normal point-in-time restore, but it asks more from the environment because it needs a staging SQL Server. The staging server replays and indexes the transactions so Explorer can show you the list. From there you can find the offending operation, whether it was an accidental DELETE, a bad bulk UPDATE, or a schema change that should never have made it into production, and restore to the point immediately before it committed.
That extra precision has a cost. It is slower, the staging server needs enough disk to hold the database while logs are replayed, and the SQL version should match the source or be newer. If AlwaysOn Availability Groups are involved, I also pay attention to time-zone consistency across nodes because that detail becomes important fast.
Instant recovery is about getting service back fast
Instant recovery is the answer when uptime matters more than waiting for a full copy to finish. Explorer publishes the database directly from backup over iSCSI so the database can come online quickly, while the full data movement continues in the background.
Under the hood, Explorer talks to the Veeam Mount Service on the mount server and starts two iSCSI sessions. One attaches the database files to the target SQL instance. The other copies the data to native storage in the background. While that copy is running, writes are captured in the cache on the mount server, which by default lives under C:\ProgramData\Veeam\Backup\IRCache\.
When the copy finishes, you do a switchover. The published database pauses briefly, cached writes are synchronized, and the recovered copy takes over. This is the path I would use when the application team cares more about reconnecting quickly than about waiting for the full restore to land first.
One practical detail is easy to miss: once the session is started, you can close Explorer. Instant recovery is managed by the Veeam Explorers Recovery Service on the mount server rather than by the console window.
Publishing a database for inspection
Publishing looks similar to instant recovery at first glance, but the goal is different. You temporarily attach a database from backup so you can inspect it, query it, or pull something out of it. There is no background migration and no switchover at the end.
This is useful for the smaller questions that show up during incident work: did the customer record exist in last night’s backup, was that object present before the change, can we verify one row before we restore anything bigger? In those cases, publishing is usually cleaner than doing a full restore just to answer one question.
A couple of cautions matter here. Published databases are not being protected by VBR while they sit in that temporary state. If the Explorer session ends badly, the database can stick around in a Recovery pending state and need manual cleanup in SQL Server Management Studio. And I would not rename a published database while it is mounted, because Explorer tracks it by name and cleanup gets messy fast.
Object-level export is more useful than it looks
A lot of requests sound like database restores until you ask a second question. Sometimes the person really wants a schema snapshot, one procedure, a handful of rows, or a quick comparison against the backup copy. That is where Export Schema and Export schema and data earn their keep.
Export Schema is the quick option when you need tables, views, procedures, functions, indexes, and related objects as .sql scripts. If the need is narrower, Export schema and data lets you choose specific tables and export them as .mdf files or .sql scripts.
I still treat object-level export as a convenience feature rather than a universal answer. Stretch Database tables, system-versioned temporal tables, and objects with external dependencies can push you back toward a full database restore.
PowerShell is where this becomes operational
If this is part of your regular recovery testing, PowerShell is worth knowing. The SQL Explorer has its own module, Veeam.SQL.PowerShell, separate from the main VBR PowerShell module. That catches people, because they assume everything sits in one place.
The core cmdlets cover the workflow you would expect: open a restore session, enumerate databases, inspect the available restore interval, restore a database, run instant recovery, publish a database, export data, and then clean up the session.
A practical example looks like this:
Import-Module Veeam.Backup.PowerShell
Import-Module Veeam.SQL.PowerShell
$backup = Get-VBRBackup -Name "SQL-Production-Backup"
$restorePoint = Get-VBRRestorePoint -Backup $backup -Name "sql-prod-01" |
Sort-Object CreationTime -Descending | Select-Object -First 1
$session = Start-VESQLRestoreSession -RestorePoint $restorePoint
$databases = Get-VESQLDatabase -Session $session
$databases | Select-Object Name, SizeMB, RecoveryModel
$pass = ConvertTo-SecureString "YourPassword" -AsPlainText -Force
$sqlCred = New-Object System.Management.Automation.PSCredential("DOMAIN\sqlsvc", $pass)
$targetDb = $databases | Where-Object { $_.Name -eq "CustomerDB" }
Restore-VESQLDatabase -Database $targetDb `
-ServerName "sql-dev-01.yourdomain.local" `
-InstanceName "MSSQLSERVER" `
-SqlCredential $sqlCred `
-GuestCredential $sqlCred
Stop-VESQLRestoreSession -Session $session
If you want a real confidence check on recoverability, automate that restore to a non-production target on a schedule. That tells you far more than a sea of green backup jobs ever will.
Things that still trip people up
A few limitations are easy to forget until you are already in a hurry. For normal restore, publish, and export operations, Explorer generally needs to stay open. Instant recovery is the exception because it gets handed off to the recovery service.
CDP replicas and replication jobs do not give you point-in-time SQL recovery because SQL transaction logs are not part of those workflows. If the plan depends on replaying logs to an exact time, those job types are not the answer.
The .vlb detail matters too. If a process truly depends on native .trn files, plan for that separately. Do not discover the mismatch halfway through a restore plan for an AlwaysOn workflow.
Instant recovery can also fail on something as ordinary as drive-letter exhaustion. Mounted volumes consume letters, and clustered environments need them available on each participating node. Encrypted databases add their own dependency chain, since the target SQL Server needs the correct certificate and master key before the attach can succeed. In hardened environments where admin shares are disabled, pre-installing the Veeam Installer Service on the target can save you from a preventable deployment problem.
What I would test before trusting this in production
Before I relied on this workflow during a real incident, I would run it end to end in a lab or non-production path. I want to see transaction logs landing on the schedule I think I configured. I want proof that an alternate-instance restore works with the credentials and access I plan to use. I want to know that instant recovery has space on the mount server, a sane cache path, and enough drive-letter headroom to finish cleanly.
That kind of dry run tells you more than a successful backup job ever will. That is really where Veeam Explorer for SQL Server becomes useful: not as a feature list, but as a set of recovery options you already know how to execute under pressure.
