One of the great things about Veeam Backup and Replication is that is comes with a suite of great, unique features - some of the big reasons it ended up being my "backup" solution. The focus of this article is the SureBackup feature that in essence is a live verification of your backups. I'm not talking some data hash comparison between the source and backup data. I'm talking about live booted systems from the backup data including application checks - all automated.
In a nutshell, SureBackup fires up the backed up image(s) of the virtual guests inside of a network bubble(Virtual Lab) on a designated ESX(i) host and then runs some checks against those VM's to ensure they are running properly indicating a successful backup - then optionally tears the whole bubble down when done. As part of the configuration, you decide which VM's are brought to life inside the bubble and checked, typically the list is based on dependencies of the systems being verifed. For example - to check almost any Windows based server that is part of a Windows domain, you will need an Active Directory / DNS server included.
So a bit more about this network bubble. In order to run the backed up VM's and not need to re-address them on the network, worry about name collisions, etc., Veeam uses the concept of a Virtual Lab. A Virtual Lab is really composed of small linux proxy / router appliance and some network settings that are automatically deployed to a specific ESX(i) host. Behind the scenes isolated portgroup(s) are created on the ESX(i) host which are interconnected by the linux proxy appliance. It does take a basic grasp of networking to understand how to answer the network configuration for the proxy appliance - possibly the biggest hurdle to creating a Virtual Lab and SureBackup jobs. Check with your friendly network administrator if you have any questions - it really isn't so difficult but if not done properly will cause you and the network headaches! Once setup, the proxy creates isolated networks that are identical to your production networks so the VM's being run there have no idea anything is different. The proxy keeps their traffic off of your production network and can provide NAT'd access from the production network to the isolated systems for testing / restore activities - very cool!
What can you do with SureBackup? I've already mentioned the primary purpose of SureBackup - to validate your backups by actually bringing them online and testing the OS and applications automatically on a schedule. There is another very handy way to leverage the SureBackup feature that is more so implied by the name of the Virtual Lab configuration. An option in a SureBackup job is to leave things running and not tear the job down automatically. And what this really allows for is potentially automated rebuilding of a copy of production systems in an isolated environment for testing of patches, configurations, upgrades, etc. And given the NAT features of the proxy appliance, on a properly configured network end users can easily have access to these test systems. I'm sure there are other creative uses - please mention them in your comments!
During my time thus far learning and working with SureBackup, I've gathered the following tips:
- Be realistic about the IO load you put on your backup target storage. The SureBackup VM's are running off this storage so align your space and IO requirements with the underlying storage accordingly. Small numbers of large SATA drives, or a highly de-duplicated disk system may not be well suited to acceptably performing SureBackup jobs.
- Be cognizant of the load the SureBackup VM's will put on your ESX(i) host. If you create large SureBackup jobs with many VM's, they require RAM and CPU like any normal VM. A handy feature is the ability to, per VM, have Veeam automatically scale back the RAM allocated by some percentage - use it.
- Set Timers accordingly. SureBackup has timer settings used to determine if a job is taking too long or the OS / application is not responding(i.e. a backup did not work!). Depending on your storage performance, etc these may need adjusting - the defaults should be fairly sufficient. I found I needed to slightly increase the Application Initialization timeout for VM's with apps that really hit up the disk on start-up (SQL, Exchange).
- Access to the backup files. As it stands today a SureBackup job ran against a backup done with Reverse Increment will lock the files and prevent a subsequent backup from running successfully while the SureBackup Job is active. For long running lab / testing situations the current suggestion is to copy the backup to another Veeam server, import it, and run SureBackup there against the copy. If you use Forward Incremental backups check the Veeam forums for any concerns.
- Don't adjust the proxy appliance or isolated networks for the Virtual Lab from the vSphere client. Doing so will create a logical disconnect from what the Veeam Server expects and what it finds. It will break the Virtual Lab configuration.
As I continue to explore and work with SureBackup I'm sure more ideas will surface on ways to further leverage this great technology. Please post a comment with your ideas!