One of the questions I usually ask prospective customers is: do you have a Backup strategy? The question might seem a bit rhetorical and usually so it does the answer: Yes I do! At this point my next question is: do you have a Restore strategy? It is at this point where the conversation is getting the traction at the right speed. Veeam SureBackup provides the ability to verify the recoverability of your data. The main reason why backups occur it is because they offer the ability to swiftly restore the data when and where you need it. But all Backup or I should say Restore strategies are not all the same and this is where Veeam SureBackup comes into play.
How is Veeam SureBackup different and how does it work?
Veeam SureBackup leverages a patented technology called Veeam vPower NFS to present and publish in an isolated environment the VMs in the Backups. At that point the Veeam SureBackup job will perform various testings including amongst the others ping test, heartbeat test, CRC verification on the backup file and last but not least applications’ verification tests. All these settings are automatic and can be conveniently scheduled to occur at specific times. For example on the latest backups available and even on specific days when running the Full and Incremental Backups. Veeam SureBackup powers on the VMs directly from backup files, runs the tests, produces reports and once completed powers down the VMs in the isolated environment. All happens automatically. Simply put the Veeam SureBackup job consists in the configuration of two important elements: Virtual Labs and Application Groups.
Virtual Labs are the isolated environments where Veeam SureBackup runs the VMs directly from the Backups and performs the verification tests. From an infrastructure point of view the Virtual Lab is a virtual appliance compiled on the fly and running during the Veeam SureBackup jobs. It is based on a Linux VM configured with 1 GB of RAM Memory. This machine is the “gateway” between the Production environment and the isolated bubble where the verification will occur.
Application Groups as the name is suggesting is a group of VMs from backups for which we need to verify specific applications running into Production. For example Veeam SureBackup jobs can be used for testing and verify the backups of Microsoft Domain Controllers, SQL Servers, Exchange Servers, Oracle Database Servers and a lot more. Application Groups are highly configurable as covered later in a dedicated article.
In this article a quick overview of the Veeam SureBackup jobs starting with the configuration of Virtual Labs and Application Groups. More articles will follow up showing how to verify Linux and Windows machines including popular enterprise applications like Microsoft Active Directory and Oracle Database Servers.
Veeam SureBackup job configuration
The first component to configure a SureBackup job is to prepare a Veeam Virtual Lab. From the main console let’s browse to Backup Infrastructure > SureBackup > Virtual Labs.
At this point we can start the wizard to create the Virtual Lab. As the menu is suggesting we need to identify the hypervisor Host (VMware in this case) where to create the Veeam Linux VM which will help creating the isolated bubble where to run to verification tests. It is possible to create as many as required. The specs for this Linux VM are very little:
- 1x CPU
- 1x GB Ram Memory
- 1x GB Disk
For this environment I will create 2 of them. The first one to run all verification jobs from Backups and the second to run “permanent” testing environments (Veeam OnDemand Sandbox) which we’ll cover in a separate article.
Next step is to identify the hypervisor Host where to run the Linux Virtual Lab appliance.
In addition, from the configure button we have the ability to customize the name of the VM folder and Resource Pool in VMware vSphere. This is excellent as it gives more configuration options from a VMware vSphere perspective. For example, we can change the Resource Pool settings as required.
In the Datastore we can choose the location where the Virtual Lab VM will be created and where the redo-logs will be located as well during the verification job. In a nutshell: when running the Veeam SureBackup job will read directly from the source backup file and only the changes (from backup file) will be written in this datastore. When the verification process is completed all the changes will be discarded. Any datastore available to the vSphere or vCenter environment is fine. So for example lower Tiers of storage could be used for these purposes as well. It is worth noting that sureBackup jobs write only a small portion of the data (redo-log) and not the entire VM as it appears in the Backup file.
The Proxy section defines the virtual network or even better the Port Group (in the case of VMware) the Virtual Lab will use. So if the VMs part of the test are using the Production network, the Virtual Lab should use the same one unless Layer3 routing is available.
In the configure let’s choose the intended network for Virtual Lab. In addition, the option to use either dynamic or static IP addresses.
From the Networking step of the wizard and depending on the current vSphere Networking environment it is possible to choose between 3 options:
Basic single host: use this when VMs in the backup and Virtual Lab VM use same network on same VMware vSphere Host. This leverages the VMware virtual Standard Switch configuration (vSS).
Advanced single host: use this when VMs in the backup are connected to multiple Port Groups at the same time. Virtual Lab VM uses same network on same VMware vSphere Host. This leverages the VMware virtual Standard Switch configuration (vSS). Virtual Lab will include all of them if required.
Advanced multiple host: use this when VMs in the backup are connected to multiple Port Groups at the same time and are spread on different hosts. For example AD machine on host 1 and SQL server on host 2. Virtual Lab VM uses same network on same VMware vSphere Host. This leverages the VMware virtual Distributed Switch configuration (vDS). Virtual Lab will include all of them if required.
In this case I will use the advanced multiple host option. This means the same Virtual Lab can be used also to verify VMs running on different vSphere Hosts that are connected to the same virtual Distributed Switch.
With the Advanced option let’s choose the appropriate virtual switch. In this case this would be the one dedicated to the infrastructure.
As a next step from the chosen virtual Distributed Switch let’s choose which Network Port Group the Virtual Lab will use. Typically, this would be the Production network. What if one VM is connected to multiple virtual networks, for example a router? Simple, it is just a matter to add them in this wizard. The Virtual Lab can create all the networks required as in use by the current machine in the live environment.
For each one of the added virtual networks we can configure settings separately. In particular in this step we are determining how the isolated networks will connect to the Virtual Lab. It is possible to add specific settings for each virtual network connected.
This is where the magic happens: Veeam SureBackup powers on a VM from backup as it is including the network configuration. Of course, it will maintain the same IP addresses as per backup. Of course this might generate an IP conflict. Virtual Lab uses IP Masquerade technique to give the option for the Veeam Backup Server on the Production network to “see” the VMs in the isolated network but not the other way around. So for instance:
- Production Network: 192.168.1.x/24
- Masquerade Network: 192.168.255.x/24 (or any Private IP subnet)
- Isolated Network: 192.168.1.x/24
Veeam Backup Server can talk to VMs in the isolated network but not the other way around. VMs in the isolated network cannot communicate with other machines on the Production network. This is automatically controlled in Virtual Lab configuration.
Additionally, it is also possible to specify DNS server for internal name resolution.
What if there is a requirement for the VMs in the isolated network to communicate with specific machines in the Production environment? It is possible to create static mappings between the Production and isolated networks. More on this in a dedicated article.
At this point the Virtual Lab wizard has enough information to deploy the Linux virtual appliance with the chosen settings.
In a final step the wizard shows the folder, resource pool and network settings created on the chosen vSphere Host.
It is possible to create multiple Virtual Labs based on requirements. Ideally starting with two different ones, one for verification and another one for sandbox environments would be ideal. More to cover in a dedicated article.
When taking a look at the vCenter infrastructure a new VM in a new Resource Pool is created with the chosen names. As anticipated the Virtual Lab is using by default 1x CPU and 1 GB of RAM Memory.
The second components of the Veeam SureBackup is the Application Group. It is essentially the group of VMs and applications to test and verify. In this case we’ll start with a simple Linux Ubuntu VM Backup. The wizard is straight forward.
We can choose to add the VM data from Backups, Replicas and even Storage Snapshots.
In this case, adding a single VM from a Backup file. In reality, we can add more into the same SureBackup job.
For each one of the VMs it is possible to identify the role and let Veeam SureBackup to run the pertinent tests and verify the application. This list is not exhaustive and is already available with Veeam Backup Server. In a separate article we’ll review the steps to create additional verification options for other applications.
The wizard now shows a quick summary with the main Application Groups settings.
Everything is now ready to run the Veeam SureBackup job and verify a sample Linux Ubuntu VM.
Thanks foor writing