What is SureBackup?

SureBackup is a technology built into Veeam Backup & Replication that is used to help verify the “fidelity” of your Veeam backups.  It is a tool you should use if you use Veeam.  But let me back up a bit and explain a bit more why SureBackup is important.

Back in the good old days (eg before Veeam) backup was a relatively low-tech affair.  Your backup software would “freeze” system state on your server and create a backup.  Then the backup software would perform some sort of bit-level verification of the backup files created against the still frozen system state of your server.   If the verification passed you knew you had a “good” backup.  When Veeam arrived on the scene its technology was pretty revolutionary.  And it sure looked (and ran) differently from the rest of the backup pack!  One thing that stood out for me was the fact there was no verification step as part of the backup.  At least, there was no obvious verification step.

Veeam does an “inline” verification of the backup data stream for the whole length of the stream.  Veeam verifies data read out of the VMware or Hyper-V server “matches” data writing into the backup repository.  This is a “good thing”.  Yet things can go wrong once the data is written out.  So it is a “very good thing” to be able to verify the fidelity of the data whenever you want.

To provide this ability Veeam introduced Virtual Labs as well as SureBackup.  This gives admins the tools required to spin up VM instances from backup (no restores involved).  Scripts can be run to verify services and data.  In simplistic terms, SureBackup is really an automated way to run Veeam’s “Instant Recovery” feature with a few bells and whistles added.  Instant Recovery is Veeam’s technology to allow rapid spin-up of VM’s directly out of backup data.  VM’s are NOT restored.  The VM is synthesized from the backup data and mounted on a host for access just as if it was a “real” VM.  This is pretty cool technology!

It seems obvious that the very process of spinning up a VM from backup data implies fidelity of that data.  For the most part, that is true.  It’s a pretty good bet that a VM would not spin up if the data is corrupted.  But it is still a good idea to apply further steps to ensure things are truly good and that is the thrust of SureBackup.

How do I configure SureBackup?

Ok, now that we have a good idea of what SureBackup is, how do we go about configuring it?

There are really three pieces to the configuration:

  • Virtual Lab and verifying the network configuration of the lab
  • Application Groups
  • SureBackup Jobs

Each piece is important but the really critical piece is the configuration of the Virtual Lab and, specifically, its network component.  And this is the piece that most people stumble over as Veeam’s documentation and guidance is a bit “lacking”.  Trust me, I ground my teeth for the better part of 3 months working through issues with Lab configuration!

Configure the Virtual Lab

A Virtual Lab is basically a specialized “isolated” environment that Veeam creates in order to spin up VM’s without impacting the rest of your production network.  You build one by running the “Add Virtual Lab” wizard from the Backup Infrastructure section of the Veeam console.


When the Wizard runs it will present a standard set of prompts for information required to create the lab:




A couple of things to note, here.  The assumption is made that ALL machines involved with the Virtual Lab – the host the Lab is on, the host or hosts your VM’s are on AND the VM’s themselves — are all on the same network.  You can get around this but the best bet is to be as flat as possible.  The second thing to note is the name of the “Production Network” needs to match across all the servers that are involved with this particular Virtual Lab.  In general the name of the network will come from the name of the virtual switch on the host machine.  If you have differing switch names between your hosts you’ll end up having to create a series of Virtual Labs to cover all your VM’s.  The reason for this is the helper VM that is created as part of the Virtual Lab can only handle on Virtual Lab at a time which implies only one isolated network at a time.  More about this later in this post.


This piece is particularly important.  Veeam documentation indicates you can use “Basic” config if you are only working with a single server.  Ignore that!  ALWAYS select “Advanced”!


This piece creates the isolated network inside the Lab.


OK, this is the critical piece and it can be very confusing.  I’m going to highlight the entry then click on Edit to show the details.


The address MUST match the GATEWAY on your network.  It sounds weird but this critical.  The “masquerade” network address is the network that will be created INTERNALLY in the Virtual Lab.  Even though it is internal to the lab it still cannot match any other network in your “real” network.  Double check the address being presented as you can change it as required.


You don’t have to enter anything here so click Next.


If everything looks good click Apply then Finish.  This will create the virtual lab.

Networking Gotchas!

NOTE:  Earlier I stated the name of the “Production Network” is important.  In the above screenshot I’ve highlighted the Network mapping info.  This is the critical bit as the lab maps things by name.  You will cause yourself grief if your Virtual Switch naming is inconsistent between host servers.  If you try to work with VM’s from multiple hosts within the lab some network connections will fail.

Let me illustrate.  I have two Virtual Labs configured in my production environment.  Lab 1’s network mapping looks like this:


Lab 2 looks like this:


The two production networks are named differently.  Hyper-V includes networking information for a VM in the settings file for the VM.  This information includes the Virtual Switch name. Veeam uses this information when it is building a VM inside the Virtual Lab to provision networking and map the VM’s to the isolated network.  A Virtual Lab only creates ONE set of network mappings per lab.  Virtual Switch 1 —> Lab Isolated Network Virtual Switch is NOT the same as Intel(R) Gigabit 2p I350-t Adapter – Virtual Switch 1 —> Lab Isolated Network (Virtual Lab 1).   Therefore, any VM’s with Production network “Virtual Switch 1” as their configured virtual Switch CANNOT connect to the network in a lab where the Production network is something else.  Even though ALL machines (hosts, VM’s and Veeam server) are on the same physical network, the naming scheme will bite you in the backside if you are inconsistent.  I fought with this for months until a Veeam Support engineer spotted my misconfiguration and put me on the right path.  Thanks Michael!

So, I use Virtual Lab 1 to run SureBackup against VM’s backed up from host 1 and Virtual Lab 2 to run SureBackup against VM’s backed up from host 2.

My next post will continue to explore the process of configuring SureBackup by looking at Application Groups and SureBackup itself.

Veeam SureBackup
Tagged on:         

Leave a Reply

Your email address will not be published. Required fields are marked *