Learn Veeam - Backing Up SQL, Exchange, AD & Oracle

#Introduction

In episode 5 we touched on application-aware processing; in episode 8 we touched on Explorers for application item restores. In episode 10 we combine both thoroughly: database application backups — SQL Server, Exchange, Active Directory, and Oracle — from the perspective of consistency, Application Group design, and agent jobs.

Databases are the heart of business, and backing them up wrong means inviting disaster. This episode builds a proper understanding of what makes a database backup restorable correctly.

#Application-Aware Processing & VSS

#Why Databases Need Special Treatment

As covered in episode 5, a hypervisor snapshot produces a crash-consistent backup — the disk files are intact but the application is not. For databases this is dangerous: uncommitted transactions can corrupt the database during recovery. Application-aware processing (VSS) solves this problem.

#VSS on Windows, and on Linux

Windows (SQL, Exchange, AD): Veeam triggers VSS — applications finish their transactions (quiesce), then the snapshot is taken. The result: an application-consistent backup, safe for point-in-time recovery.
Linux (Oracle, PostgreSQL, MySQL): Veeam runs pre-freeze scripts (e.g. ALTER TABLESPACE ... BEGIN BACKUP for Oracle) and post-thaw scripts so the database is consistent without VSS.

#Guest Credentials and Connectivity

Application-aware processing requires valid guest credentials. For SQL and Exchange, Veeam also needs access to the application (e.g. the SQL instance) to perform log truncation and restore-aware logging. Configure it in the job wizard: Guest Processing → Application-aware processing → Edit → enable per application.

Important

The crash-consistent vs application-consistent difference determines whether a database can be restored. A crash-consistent backup of a SQL Server might be recovered by SQL recovery, but it can also fail or lose the last transactions — and you will not know until you try. Always use application-aware processing for production databases.

#Application Groups: SQL + AD + File Server

#What Is an Application Group

An Application Group is a set of VMs that are backed up and tested as a single ordered entity — aware of dependencies between applications. A classic example: a file server holds a database attach from SQL, and both are used by AD. An Application Group ensures:

VMs are backed up in the correct order (SQL before the file server).
Tests (SureBackup, episode 8) verify the whole stack works.

#Creating an Application Group

From the console: Backup Infrastructure → Application Groups → Add. Select the VMs, then give each VM test scripts (e.g. ping, check port 1433 for SQL). This group then serves as the basis for a SureBackup job — full verification that the entire application stack can come to life from backup.

#Agent Jobs for Databases

#Veeam Agent + Application Plugins

For physical servers or cases where agent-level is more appropriate, Veeam Agent for Windows supports application plugins:

Microsoft SQL Server — the plugin performs transaction-log-aware backups and second-level restore points.
Microsoft Exchange — mailbox-level backups directly from a physical server.
Microsoft SharePoint — item-level restores.
Oracle — via the Veeam Agent for Linux plugin with RMAN integration.

This pattern gives stricter RPO (transaction log backups can run frequently) without touching the hypervisor.

#Transaction Log Backups

Veeam uses SQL log backups for point-in-time restores (PITR) in the restore step: after restoring the full backup, roll forward the transaction logs to the desired minute. To take advantage of this, enable Log backup in the SQL job:

Point-in-time restore via logs

Full backup ──▶ Log1 ──▶ Log2 ──▶ Log3 ──▶ TARGET TIME

#Application Restore Practice

#Explorer for SQL / Exchange / AD / Oracle

Once application-consistent backups are available, granular restores use the Explorers:

Explorer for SQL — restore a full database, table, or rows; publish to an instance.
Explorer for Exchange — restore mailboxes, folders, items to Exchange Online/on-prem.
Explorer for AD — restore AD objects (user/group/OU), re-apply attributes.
Oracle Explorer — restore a datafile, tablespace, or database.

A quick flow via PowerShell:

Start a SQL restore session

$rp = Get-VBRRestorePoint -Name "SQL-01" | Select-Object -First 1
Start-VBRSQLRestore -RestorePoint $rp

Then select the needed items in the Explorer GUI.

Tip

Test application restores at least once a month. Backing up SQL with VSS is useless if you have never proven that Explorer for SQL actually returns a database to an instance. Make "application restore drills" part of your monthly SOP — episode 20 connects them to reports and monitoring.

#Verification

After this episode, make sure:

The SQL/Exchange/AD job ran Success with application-aware processing active.
Explorer for SQL successfully restored a database to a test instance.
The Application Group includes SQL + AD + file server in the correct order.
(Optional) Transaction log backup is enabled for PITR.

#Closing

Key takeaways:

Application-aware processing (VSS) produces application-consistent backups — a requirement for correct database restores.
Application Groups orchestrate multi-application backup & testing (SQL + AD + file server).
Agent jobs + plugins handle SQL/Exchange/SharePoint/Oracle on physical servers.
Transaction log backups enable point-in-time restores.
Explorer for SQL/Exchange/AD/Oracle for granular application item restores.

In the next episode, episode 11, we will cover M365 & Salesforce backups — Veeam Backup for Microsoft 365 (Exchange Online, SharePoint, OneDrive, Teams) with per-user licensing, and Veeam Backup for Salesforce for metadata & data, whose platform scope expanded in v13. Your SaaS data will finally be protected!