Improving Backup Job Performance when Veeam is Running on a Virtual Machine
Recently I have been keeping an eye on a particular Veeam backup job for a customer. I've noticed that the processing rate of the job seemed quite slow. When you consider the virtual machines are running in an ESXi 5 cluster, using shared storage on a Fibre SAN with 10k SAS drives and redundant paths via 2 QLogic fibre channel switches, I was expecting to see processing speeds higher than 20mb/sec. After checking the statistics of the backup job, I noticed that the primary bottleneck was listed as "Source."
Veeam's help center talks about the various methods of data retrieval and what Veeam VBR provides. Starting from the most efficient to the least efficient:
- Direct SAN Access
- Virtual Appliance
After reviewing how the backup proxy was configured, I noticed it was on Automatic. This resulted in Veeam analyzing the backup proxy and connected datastore configuration to determine the best method of transport. This would not always result in the best performance when a backup job took place, as it was defaulting to Network mode.
I noticed that the backup job reported the bottleneck was "Source." Reviewing the job statistics, it looks like the job was failing over to "nbd" - which means it was trying to back up the virtual machines by accessing the hypervisor I/O stack over the network, rather than taking advantage of being able to access the storage directly through the hypervisor I/O stack. The processing rate just appeared to be unusually slow.
Our customer's Veeam server is a VM, with a physical-compatibility mode RDM where our backups were being written to. The VM does not have direct access to the SAN via their fibre fabric, but it still has the ability to perform hot add backups. After seeing that Veeam was attempting to back up all of our VM data over the network, I decided to give the Virtual Appliance transport mode a try since our Veeam virtual machine doesn't have direct SAN access. Turns out, the performance boosted tremendously.
After changing the transport mode to Virtual Appliance, the proxy was retrieving data directly from the hypervisor I/O stack rather than via the network. Our datastore cluster is available to the Veeam VM, so this mode of transport worked beautifully, and the processing rate jumped from 20mb/sec to somewhere around 220mb/sec. Overall reads from the VMs to the backup repository increased dramatically! Notice how I've selected "Virtual Appliance" as the method of transport:
After I changed the transport mode to Virtual Appliance, the bottleneck was now listed at "Target." Notice the processing rate jumped up to 204mb/sec! I've seen it jump even higher at times, but this happened to be when I grabbed a screenshot.
So there you have it, a good way to boost your backup performance by making a quick and easy change to your Veeam's transport mode.
comments powered by Disqus
- Migrate from Oracle to SQL Server and Save - Webinar Replay
- Webinar Posted: SQL Server 2014 Overview / Product Review / Key Features
- Whitepaper Published: Migrating Oracle on Sun platform to Microsoft SQL Server 2012