SureBackup for Hyper-V -- Virtual Lab, Application Groups, and Verification
SureBackup on Hyper-V does the same job as on vSphere: boots VMs from backup in an isolated lab and verifies that applications actually start and respond correctly. But the setup is meaningfully different. There is no vApp concept, no vSphere port groups to clone, and the network isolation mechanism works differently. If you have read the vSphere SureBackup article on this site and expect Hyper-V to behave the same way, you will hit a few walls before you get a working lab. This article covers the differences, walks through configuration from scratch, and explains how to handle multi-VM application groups on a Hyper-V cluster.
vSphere vs. Hyper-V: Key Differences
| Capability | vSphere SureBackup | Hyper-V SureBackup |
|---|---|---|
| Network isolation | vSphere port group clone | Isolated Hyper-V virtual switch created by VBR |
| Application groups | vApp concept with boot order and delays | Application Group object in VBR, no vApp dependency |
| IP masquerading | Supported via port group routing rules | Supported, VBR configures masquerading rules on the Hyper-V switch |
| Storage during lab | vPower NFS datastore on the mount server | vPower NFS on the Hyper-V host acting as mount server |
On vSphere, SureBackup relies on vApps to group VMs with startup order and delays. Hyper-V has no equivalent concept. VBR handles this entirely through its own Application Group objects, where you define the VMs, their boot order, startup delays, and the application test to run after each VM starts. This is actually cleaner to configure than the vSphere path because everything lives in VBR and there is no external dependency on vCenter or port group assignments.
Step 1: Create a Virtual Lab for Hyper-V
The Virtual Lab is the isolated environment where SureBackup runs your VMs. For Hyper-V, VBR creates an isolated Hyper-V virtual switch and configures masquerading so lab VMs can reach production resources for application testing (like domain controllers or DNS) without exposing their traffic to the production network.
- In the VBR console, go to Backup Infrastructure > SureBackup > Virtual Labs and click Add Virtual Lab.
- On the Host step, select the Hyper-V host where the lab VMs will run. This should be a host with enough free RAM to run the lab VMs concurrently.
- On the Datastore step, select the location for redo log files. Lab VMs write changes to redo logs while running. This is temporary storage only, discarded when the SureBackup session ends. A local fast disk is fine.
- On the Proxy step, select the Hyper-V host to act as the mount server, typically the same host selected above. This is where vPower NFS runs to serve backup data to the lab VMs.
- On the Networking step, configure the isolated virtual switch. Click Add and map each production network used by your lab VMs to an isolated counterpart. VBR creates the isolated switch and handles the port group mapping.
- Configure IP masquerading if your lab VMs need to reach production resources like domain controllers. Set the masquerade IP range, which is a temporary IP space used inside the lab for routing.
- Click Finish to create the lab.
Step 2: Create an Application Group
An Application Group defines which VMs to boot in the lab, in what order, and what tests to run to verify each one started successfully. For a multi-tier application, build the group with the SQL Server or domain controller booting first, with a startup delay and application test before the front-end starts.
- Go to Backup Infrastructure > SureBackup > Application Groups and click Add Application Group.
- Click Add VM and select the backup jobs and VMs to include. For each VM, configure allocated memory, maximum allowed boot time, and application initialization delay (how many seconds to wait after the VM reports as booted before running the application test).
- Set the Test script for each VM: a predefined test like SQL Server connectivity or Exchange store check, or a custom script that returns exit code 0 on success.
- Arrange VMs in the correct boot order. VBR boots VMs in the list order, waiting for each one to pass its test before starting the next.
- Click Finish to save the Application Group.
Step 3: Create the SureBackup Job
- Go to Home and click SureBackup Job.
- On the Virtual Lab step, select the Hyper-V virtual lab from Step 1.
- On the Application Group step, select the Application Group from Step 2. These VMs boot first and must pass their tests before any linked job VMs are tested.
- On the Linked Jobs step, add the backup jobs whose VMs you want to verify. VBR boots each VM from those jobs in turn, runs the configured tests, and powers the VM off before moving to the next.
- Configure the schedule. Weekly off-hours runs are a common starting point.
- Click Finish.
Outside of scheduled SureBackup jobs, you can start any backed-up Hyper-V VM in the virtual lab on demand. Right-click a restore point in the VBR console, select Restore to Hyper-V, and choose the virtual lab as the destination. The VM boots in isolation and you can connect to it via Hyper-V Manager for manual testing. Stop the session when done. Changes are discarded.
Interpreting SureBackup Results
After a SureBackup run, open the session report in the VBR console. Each VM shows one of four outcomes: Success, Warning, Failed, or Skipped. Success means the VM booted and passed all configured tests. Warning means the VM booted but a test returned an unexpected result. Failed means the VM did not boot within the allowed time or a test returned a failure exit code. Skipped means the VM was not tested, usually because an earlier dependency in the application group failed.
The most common false failure on the first SureBackup run is an application initialization delay that is too short. SQL Server and Exchange can take longer to fully start when running from a slower NFS mount. Increase the initialization delay in the Application Group settings by 30 to 60 seconds if you are seeing failures that look timing-related rather than genuine application failures.
If your lab VMs depend on Active Directory for authentication, you need a domain controller in the application group, booting first. AD services and DNS need to be fully started before any domain-joined VMs attempt to authenticate. A common setup is DC in the application group with a 120-second initialization delay, then application VMs in linked jobs. Without this, domain-joined VMs will fail their application tests because they cannot authenticate, not because of a backup problem.
What You've Completed
- Understood the key differences from vSphere SureBackup: isolated Hyper-V virtual switch instead of port group clone, no vApp dependency, and masquerading configured directly in VBR.
- Created a Virtual Lab for Hyper-V with isolated network switch mapping, masquerading, and an appropriate mount server.
- Built an Application Group with VMs in correct boot order, startup delays, memory allocation, and application tests.
- Created and scheduled the SureBackup job linking the virtual lab, application group, and backup jobs.
- Understood result interpretation and the initialization delay tuning typically needed on first run, plus the domain controller prerequisite for domain-joined VMs.