SureBackup: Prove Your Veeam Backups Boot, Serve and Restore
Why this guide exists
Backups aren’t trusted until they are tested. SureBackup in Veeam Backup & Replication boots your VMs from backups in an isolated lab, runs health checks, and gives you evidence. This guide shows you how to build the lab, create tests, and schedule weekly proof without drama. If you prefer us to run and evidence the tests for you with offsite, immutable copies, see /services/cloud-backup/.
What you will get by the end
- A working Virtual Lab that boots VMs from backups safely.
- An Application Group that starts dependencies in the right order.
- A SureBackup Job that validates OS, network, and app services.
- Email reports you can show management and auditors.
- Tips to validate agent-based backups as well.
- Calm CTAs to a managed option when you want it.
Deployment choices
All-in-one
When: labs and small sites. Pros: quick to set up on the Veeam server host. Cons: limited I/O for multi-VM testing; noisy neighbours can slow verification.
Distributed
When: production and larger estates. Pros: a dedicated ESXi host or cluster, nearby proxies and fast cache disks make tests run fast; less impact on production. Tip: store redo-logs and vPower NFS cache on SSD.
Prerequisites
OS: Veeam Backup & Replication v12 on Windows Server. Hypervisor: VMware vSphere with access to the host/cluster you will use for the lab. Network: a VLAN you can isolate for testing; permission to create an isolated vSwitch/port group. Backups: recent, healthy restore points for the VMs you will verify. Accounts: Veeam admin and guest OS creds for app tests if needed.
Security note: the Virtual Lab is isolated; production traffic won’t be touched if you follow the wizard mappings. Question you’d ask later: can I test from immutable or cloud copies? Yes—SureBackup reads from backups; immutability blocks deletion, not verification. For provider-hosted copies, talk to your SP or use our managed option.
Install / Core setup
This guide assumes Veeam is installed, your VMware infrastructure is added, and backups exist. If not, complete those first.
Build the Virtual Lab (isolated test network)
Create the lab
- Backup Infrastructure > SureBackup > Virtual Labs > Add Virtual Lab.
- Choose the VMware host/cluster and the datastore for redo-logs and vPower NFS cache (SSD recommended).
- Networking: select “Basic” for fully isolated labs, or “Advanced” to map specific production networks via masqueraded gateways.
- For Advanced, define the “Proxy Appliance” settings (isolated gateway IP, DNS forwarders), and NAT rules for any ports you will test from the Veeam server (e.g. RDP/HTTPS).
- Finish and let Veeam publish the lab components.
Create an Application Group (dependencies first)
Why it matters
Many apps need a DC/DNS or a database before they pass a test. The Application Group starts them first, in order, with custom tests.
Steps
- Backup Infrastructure > SureBackup > Application Groups > Add.
- Add Domain Controller/DNS first, then database server, then the app VM.
- For each VM, pick tests: Ping, Heartbeat, Application test (port check or custom script), and timeouts.
- Save. Keep the group small and essential; extra VMs slow verification without adding value.
Create the SureBackup Job (the automation)
Wizard flow
- Backup Infrastructure > SureBackup > SureBackup Jobs > Add.
- Name the job; select the Virtual Lab and the Application Group.
- Add Linked Jobs or individual VMs you want to verify after the Application Group boots.
- Verification options: choose test order, timeouts, email notifications, and whether to keep VMs running for manual checks.
- Schedule it weekly (or nightly for critical systems). Save.
Run, review, and evidence
First run
- • Start the job. Watch the lab publish, then VMs boot. Expect a few extra minutes on first use while caches warm up.
- • When complete, open the report. Green ticks = passed. Amber/red = investigate.
Evidence pack
• Keep the report PDF, a screenshot of the running app in the lab, and the job log snippet. Store in your monthly “Recovery Readiness” folder. If you prefer a managed evidence pack, see /services/cloud-backup/.
Testing real service health (beyond ping)
Simple built-ins
• Port checks: 80/443 for web apps; 1433 for SQL; 389/636 for LDAP.
• Heartbeat: confirms VMware Tools responded. Good but not sufficient.
Custom scripts
• Use a PowerShell or batch script to hit a health URL, run a SQL query, or check a Windows service. Return proper exit codes.
• Keep scripts idempotent; avoid writes. The lab is not production.
Agent-based backups: verify those too
Approach
• Use Recovery Verification (SureBackup mode for agents). Select the agent backup, boot it in the Virtual Lab, and run the same ping/port/script tests.
• Network tips: give the agent VM a lab IP; use NAT rules to let Veeam reach its HTTP/SQL/SMB ports for tests.
Jobs that protect you
Backup Jobs
Objects: choose VMs/agents. Destination: local hardened repo or cloud repository. Retention/GFS: keep enough points to span your risk window. App-aware processing: on for SQL/Exchange/AD. Schedule outside peak hours.
Backup Copy Jobs
Source = backups, not VMs. Immediate for mirror-like offsite copies; Periodic for batch windows. Target: provider cloud repository. WAN acceleration if links are thin.
One-liner difference: Backups talk to VMs; Copy Jobs talk to backups.
Recovery mindset
Run SureBackup weekly. For critical apps, keep VMs running after tests and perform a quick manual click-through. Practice Instant VM Recovery quarterly so the team knows the flow. Keep a one-page runbook with contacts, SLA, and restore order. Prefer a managed cadence with immutable offsite copies and monthly drills? See /services/cloud-backup/.
Frequently solved problems
VMs fail heartbeat but ping works
Install/repair VMware Tools in the backup source; increase timeouts; verify OS boots fully in the lab.
Web test fails but site loads in browser
Open the NAT port in the Virtual Lab rules; test the health URL path; ignore SSL warnings or trust a lab cert.
SQL test times out
Ensure the DB VM is in the Application Group and starts before the app VM; add 1433 to NAT; test a lightweight query.
DNS or AD errors
Put a DC/DNS in the Application Group; point other VMs’ DNS to it; add AD port checks (389/636/3268).
Lab affects production
Use Basic isolation or careful Advanced mappings; never bridge lab VLANs to production; review Proxy Appliance routes.
Agent verification cannot reach ports
Add per-port NAT rules in the Virtual Lab; confirm the agent VM gets a lab IP; test connectivity from the Veeam server.
Quick reference checklists
Sizing
• SSD for vPower NFS/redo-logs. • One proxy per ESXi cluster under test. • Keep 20–30% headroom on the host running labs.
Job design
• Group by business service. • Start DC/DNS first. • Add short, decisive app tests. • Schedule weekly; email reports.
Security
• Lab is isolated; keep it that way. • MFA on Veeam console. • Immutable repo on-site plus offsite copies. • Config backup exported offsite.