Veeam Backup & Replication – VMware Snapshot-less recovery points

Do you have High IO workloads that you cannot afford to have a VMware snapshot take place?

This was a nice feature that was sneaked into V10 without many people realising.

A common challenge with High IO workloads with VMware snapshots is that it would or could kill performance of likely this mission critical system when a VMware snapshot takes place, which either means you take that risk and manage to get a backup to happen during a relevant window, you leverage crash consistent storage snapshots which also do not require a VMware snapshot or GASP! You just do not do anything and hope that nothing happens to this MISSION CRITICAL system.

Ok so what can we do? – The theory

What if I told you, you could take an application aware and consistent storage snapshot without having to take a VMware snapshot?

If you are running one of the many storage integrations that are supported by Veeam then you are in luck. You can configure a Storage Snapshot only job with your application aware processing configured within the wizard and that is it. Ok there are some caveats. The VM’s virtual disks must be located on the same datastores and they must be unique within the backup job.

Here are some examples:

If you have one Veeam orchestrated snapshot job configured and you have 3 VMs from the same VM Datastore then the traditional method of creating a backup will take place which will involve a VMware snapshot.

Example 1

If you have one VM on a datastore that has high IO and you do not wish this to be affected with VMware snapshots then create one backup job that contains only this VM and you will achieve this application consistent storage snapshot.

Example 2

Finally lets take a Tier 1 application that is made up of 2 virtual machines, these machines reside on their own VM datastores and storage volumes, they are also both added to the same backup job this will also achieve that application consistent storage snapshot.

Example 3

Things to remember

• VM must be the only VM in storage volume / datastore within the backup job.
• If the VM is not the only VM in the storage volume / datastore and backup job, then VMware Snapshot will still take place.
• All VMs that do not qualify will be processed in parallel.
• All VMs that do qualify they will be processed sequentially.

Walkthrough

I am going to pick 3 virtual machines for this test

To match these jobs with the examples above:

• Snapshot-less Orchestrated Snapshot – Same – Example 1 (2 VMs on the same datastore and same storage volume)
• Snapshot-less Orchestrated Snapshot – Single – Example 2 (Single VM on its own unique datastore)
• Snapshot-less Orchestrated Snapshot – Multi – Example 3 (2 VMs on their own unique datastores within the job)

The key to note here is that the datastores mentioned above all contain other VMs in the environment but they are not included in the backup job.

Ok let us walk through creating the orchestrated snapshot job to make this happen. Ok so this is pretty simple but it is important to know where VMs are being stored to take advantage of this functionality, if that VM moves then it will revert back to a VMware snapshot unless it is a VM in it’s own Backup Job. First of all as with all Veeam jobs, give it a relevant name.

Click add and choose your virtual machines, this can be straight via the VM name and remember there is a search function there that will help with choosing out granular machines. You can also use vSphere tags but remember where the VMs are placed in order to use that option.

Next up, because we are running orchestrated snapshots for this role, at this point you will have already had to install or add your storage system within Veeam Backup & Replication, this way depending on the storage system you are using you can select the option for Primary Storage Snapshot Only for your specific storage integration.

The next screen is for application aware processing, this is the whole reason for the enhancement, we could already do crash consistent snapshot orchestration prior to v10 and this does not have the same limitations. For crash consistent you can have multiple VMs residing on the same storage volume. Add in your credentials and hit the test here to confirm all is good.

Most likely you are going to want to schedule this to happen to sort your RPO requirements.

Summary, this is what the job looks like, you can either save this and exit or you can say start the job now.

The Results

Now its worth pointing out that the systems I have chosen for this demo are lab machines, if you didn’t guess they are an Active Directory Domain Controller, Veeam ONE server running SQL Express and Veeam Backup & Replication also running SQL Express. (not the Veeam Backup & Replication server running the jobs) none of these systems are actually running high IO workloads this is to prove the concept so please ignore the durations.

This first one is in line with example 1, we have two VMs stored on the same datastore and storage volume and clearly both within the same backup job, you can see I have highlighted that in this instance we are going to take a VMware snapshot.

The second example is of a single VM in its own backup job. You can see that there is no “creating VM snapshot” or “Removing VM snapshot” you only see “Primary storage snapshot created successfully”

Finally, we have example 3, this shows 2 VMs in one backup job but both VMs are stored on two different storage volumes / datastores. Much the same as example 2 above now you can see that no VMware snapshot is taking place just the storage snapshot.

And just to confirm that we are application consistent here we have the logs being truncated in the summary below. There were some also enhancement in this area when it comes to SQL and Oracle that I will have to get to in another post.

So, you could do this kind of prior to Veeam Backup & Replication v10 but they would be crash consistent and that’s a huge risk to take on such important systems. Veeam also has this capability already with the storage integration with Cisco HyperFlex as this uses the native VM snapshot engine and API available on the HyperFlex system to achieve this.