Later on this week I’m getting the chance to present at my first ever Veeam User Group – My topic – Veeam & 3PAR Now as I was preparing some slides and asking around/researching the community I came to the realization that some people may be under some false pretenses as it pertains to the Veeam Backup from Storage Snapshot feature. For the most part I see people under the assumption that backing up from a storage snapshot is all about speed – however in my experiences it really hasn’t been. Now that’s not to say it isn’t faster, it most certainly could be, but not for any reasons that it is actually copying the data out faster, but for the reasons that it speeds up other functions of the backup process. To help with this, let’s take a look at both the “traditional” Veeam backup process and the Backup from Storage Snapshot Process
Traditional Veeam Backups
Veeam performs a lot of tasks when it completes a backup of a vSphere VM – but for the sake of this post, let’s just take a look at how it handles snapshots. The traditional Veeam backup process can essentially be broken down into three major steps
- Veeam instructs vCenter to take a snapshot of the source VM
- Veeam utilizes CBT data and copies those blocks which have changed to the target.
- Veeam instructs vCenter to delete the snapshot of the source VM.
Looking at it like this it appears to be quite simple but there are a lot of challenges with this. First up, the copying of data step – this could potentially take a long time depending on the initial size and change rate of your virtual machines. During this time, the VMware snapshot will continue to grow – which could possible double in size. When Veeam finally gets to step 3, the snapshot deletion, VMware is forced to copy all of those changed blocks that were written while the backup was running back into original vmdk – this process can and usually does involve a large amount of reads and writes, which most certainly affects the performance of our VM. On top of this VMware attempts to ‘stun’ the virtual machine by creating yet another snapshot to help with the removal – now if our VMs are generating data fast enough we could experience an overall loss of responsiveness as our storage tries to catch up. Now VMware has made a lot of changes as to how they consolidate and remove snapshots in vSphere 6 which I suggest you read about – but the issues of having to have an active VMware snapshot during the backup process remain….
Backup from Storage Snapshot
When Veeam performs a backup from a Storage Snapshot it is able to discard of the vSphere snapshot in a much more efficient way – we can break down the steps below…
- Veeam instructs vCenter to take a snapshot of the source VM
- Veeam instructs the storage array to take a SAN snapshot of the LUN containing the source VM
- Veeam instructs vCenter to delete the snapshot of the source VM. (Happens on production LUN)
- Veeam utilizes CBT and the VM snapshot data that still exists on the Storage Snapshot to copy out changed blocks to the target
- Veeam instructs the storage array to discard the SAN Snapshot
So how does this help you ask? We still see the VMware snapshot being created. The difference here is that Steps 1-3 take literally seconds. The vSphere Snapshot is created, SAN Snapshot is created, then the vSphere snapshot is discarded immediately after. Due to the nature of SAN Snapshots this essentially redirects all changed writes to our production LUN while leaving our snapshot LUN available for backup processing – all the while removing the requirement of having the VMware snapshot open for the backup duration. At the end of the backup process, the SAN Snapshot is simply discarded…
So, is Backup from Storage Snapshot faster – well, it depends. Sure, it does speed things up, but not in a data copy/processing way – more so in a snapshot commit way. In a Backup from Storage Snapshot job, our VMware snapshot is only open for a little time, therefore it shouldn’t take as long to consolidate it as if it were open for the complete backup job. That said, the real value of the Backup from Storage Snapshot comes from the short VMware snapshot commit time – and the no stun, more so than any decrease of the backup time.
So there you have it – just my two cents for the day! And hey, if you are in or around Toronto/Mississauga on Wednesday be sure to register and stop by the Veeam User Group!
Thanks for reading!
