Protect the VM and its application state, then recover a separate copy and prove a business operation. A successful backup job is one piece of evidence. It does not establish that the recovered database, service accounts, application dependencies and network configuration work together.
This guide uses Veeam Backup & Replication 13 as a concrete third-party reference workflow. It does not describe or imply a NetLeverage product capability. Confirm support for the exact backup-server, hypervisor, guest and application builds before using the procedure. All examples are for an authorised isolated lab; none has been executed for this article.
1. Define what must survive
Use a small lab application with a Windows application VM and a SQL Server VM. Give the test a unique identifier and create synthetic records through the application, not by changing production tables. Retain the record identifiers, committed UTC timestamps and expected results outside the protected VMs.
Define the recovery point objective (RPO), the maximum acceptable data loss, and recovery time objective (RTO), the maximum acceptable service outage. Distinguish those targets from the measured data gap and recovery duration. Choose a test cadence fine enough to measure the proposed data-loss target.
Create a recovery manifest:
| Item | Required evidence |
|---|---|
| Application | Version, expected transaction and external dependencies |
| VM | Inventory identity, disks, firmware, network adapters and encryption dependencies |
| Database | Database names, recovery model, backup ownership and log-backup arrangement |
| Access | Approved recovery operator and separate access to protected recovery credentials |
| Repository | Independent failure domain, access controls, capacity and retention policy |
| Timing | Application record timestamps, recovery-point time and validation completion time |
These are recommended evidence fields, not claims that one backup product automatically discovers or protects all of them.
2. Separate snapshots from backup copies
VMware snapshots depend on their underlying disks and are intended for temporary use. They do not provide an independent recovery copy. A backup application may use a snapshot while reading a stable disk view, but the backup's recoverability depends on the resulting repository data and its metadata. VMware snapshot best practices: https://knowledge.broadcom.com/external/article/318825/best-practices-for-using-vmware-snapshot.html
Before a lab job, record existing snapshot state and available datastore space. Establish a stop condition for unexpected growth or low capacity. Do not delete snapshot files manually or initiate consolidation merely because a warning appears. Investigate the backup task, disk chain and storage conditions first.
3. Configure the job around application consistency
Start with an installed, supported backup server, registered lab vCenter, suitable proxy and existing repository. In the backup job wizard, select the specific lab VMs, confirm every required virtual disk is included, and choose the intended repository and retention. Review exclusions explicitly.
On Guest Processing, enable application-aware processing and select approved guest credentials through the product's credential store. Application processing may need guest access and permissions; a vCenter login alone is not proof that it can process SQL. Do not place credentials in a runbook or screenshot. Veeam documents its application-aware processing model: https://helpcenter.veeam.com/docs/vbr/userguide/application_aware_processing.html?ver=13.
Open Applications, select the SQL VM and its General settings. Choose Require successful processing when the job's contract requires application consistency. The alternative that ignores processing failures can complete with a crash-consistent image. Select SQL log handling only after the DBA has identified which product owns transaction-log backups. Where this image job must not affect the existing backup arrangement, assess its copy-only option with the DBA. Application processing settings: https://helpcenter.veeam.com/docs/vbr/userguide/backup_job_vss_application_vm.html?ver=13
A VSS-aware backup is coordinated with participating writers. A custom application without a supported writer or documented quiescing procedure needs its own consistency design. Coordinating one VM also does not automatically provide a single consistent transaction point across independent application and database VMs. VMware VSS background: https://knowledge.broadcom.com/external/article?articleNumber=344277
4. Collect evidence from one bounded backup
Run one approved lab job while the synthetic application workload produces numbered records. Keep the workload bounded and record its start and stop times.
Inspect the VM-level job details, not only the job's overall colour. Record application-processing status, warnings, backup start/end, selected disks and resulting restore point. Compare the outcome against the required consistency mode. Investigate any warning before describing the point as application-consistent.
After the task finishes, compare snapshot state with the pre-job record. Confirm the temporary backup snapshot has been cleaned up and no new consolidation issue remains. A pre-existing unrelated snapshot must not be removed as cleanup for this test.
Keep backup logs and application logs together. If application processing fails, troubleshoot permissions, connectivity, writer/application health and concurrent protection tasks. Do not change the job to ignore failures just to obtain a green result.
5. Restore to a separate identity and network
Create a dedicated restore-test destination with enough capacity and a network isolated from production. Test that isolation before restoring: account for routing, uplinks, DNS, outbound mail, scheduled jobs, webhooks and external APIs. A different port-group name alone is not isolation.
In the full-VM restore wizard, select the recorded restore point and Restore to a new location, or with different settings. Select the lab host/cluster and datastore, assign a clearly different VM inventory name, and review every target. The original-location mode has different overwrite consequences and is not part of this test. Restore-mode reference: https://helpcenter.veeam.com/docs/vbr/userguide/full_restore_mode_vm.html?ver=13
At Network, map every adapter to its approved test network or select Disconnected until isolation is verified. Multi-NIC VMs need all mappings reviewed. Inventory renaming does not change the guest's hostname, IP configuration or domain identity. Restore network mapping: https://helpcenter.veeam.com/docs/vbr/userguide/full_restore_network_vm.html?ver=13
Do not attach a restored domain member to production to make authentication work. Supply a separately designed isolated identity dependency, or document that authentication remains untested. Restoring domain controllers requires an AD-specific recovery procedure beyond this guide.
6. Test the recovered service
Start the isolated dependencies in their documented order. Confirm database recovery completes and application services start without unresolved errors. Then execute the same application transaction used before backup: authenticate, locate a known record, create a new synthetic record and read it back through the normal application path.
Check several consecutive records around the selected recovery boundary. Record the newest confirmed recovered commit and any missing or inconsistent sequence. A VM boot and a database listed as online are useful checks but do not replace this transaction.
Measure:
- Data gap: simulated incident time minus newest recovered committed-record time, with the workload's sampling uncertainty stated.
- Full service outage: service interruption to successful end-to-end application acceptance. Include detection, investigation, decision/authorisation, operator access, restore, dependency startup, traffic restoration and validation. Compare this complete interval with the agreed RTO.
- Recovery execution duration: declared recovery start to application acceptance. Report it separately; it omits any detection and decision delay before declaration. Record interruption, detection, declaration, access and acceptance as separate timestamps.
- Errors: missing records, failed authentication, broken dependencies or incorrect transaction results.
A drill that begins with the operator already ready measures execution only unless it also simulates and times detection and decision. If interruption time is unknown, report that uncertainty and do not claim full RTO compliance. AWS defines RTO against the interruption of service; the milestone split here is an editorial measurement design. Recovery objective definition: https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html
With multiple services, report each dependency's tested scope. Do not infer distributed consistency from one successful SQL query.
Acceptance, cleanup and limits
Pass only when the required consistency evidence exists, the application returns correct results, the measured data gap and complete service-outage interval meet their respective targets (or the drill is explicitly accepted for execution testing only) and the source environment remains healthy. Record failures as unresolved recovery requirements.
After preserving evidence, power off test copies and have the operator review their unique identities before removing those copies through the normal lab cleanup process. Retain the backup according to policy. Cleanup must not delete source VMs, original disks or unrelated restore points.
This exercise does not prove recovery after loss of the repository, identity service or encryption keys. Those need separate failure scenarios and tested recovery access. Replication and retention also do not establish immutability without evidence of the actual repository controls.
Related topics: cloud disaster recovery, SQL performance and VMware snapshot risk.
Learning notes
- Application consistency needs explicit processing evidence and a working restore.
- A renamed VM can still carry the original guest identity.
- Recovery time ends when the required application service is usable.
Sources and review status
See the source ledger for dates, version scope and limits, the author self-check, and the series index. Independent review and lab validation remain pending.