Veeam 3 Backup Faster, vRanger 4 Smaller ?
I have begun playing with the new vRanger 4 DPP Beta 2 to see how it compares with the current version and more importantly with the current rival Veeam 3.0.1.
Firstly it is important to note vRanger 4 is beta – there are bugs but the basics seem to work. I am not going to go into the differences between its predecessor – there are numerous major changes which you can check out at Vizioncore’s website.
However I thought I would just try a little test to see how vRanger and Veeam compare in a simple head to head backup.
I was using an HP Minitower with SATA drives as the backup server running both products – connecting to the same VMWare ESX 3.5 host (an HP DL380 G5 with local SAS disk). All were running 1Gb NICs.
The VM Guest being backed up was a 20GB Windows 2003 image – the results were as follows:
Vizioncore vRanger 4 DPP Beta 2
Time Taken : 17m2s
Backup Size : 4.9GB
Reported Throughput : 22MB/s
Veeam 3.0.1 (Set to Optimal compression)
Time Taken : 15m17s
Backup Size : 8.9GB
Reported Throughput : 22MB/s
Veeam 3.0.1 (Set to Best compression)
Time Taken : 14m6s
Backup Size : 8.9GB
Reported Throughput : 24MB/s
EDIT: After advice from Anton (see below reply) I recreated the job for the Best setting – the results were as below so Veeam still wins the race on speed / compression
Time Taken : 15m23s
Backup Size : 4.5GB
Reported Throughput : 22MB/s
I ran multiple tests for vRanger to ensure the same result and two different tests as noted above for Veeam as it had the option for altering the compression settings – ironically while this ‘Best’ function improved the speed of the backup the resulting file was the same size. Overall vRanger was acheiving compression of 75% versus Veeam’s 55% – it will be up to the individual to whether speed or size is most important.
So things are looking hopeful for vRanger at this stage although until a finished product is released there is no certainty what the final build will achieve. There are still quite a few glitches in the beta gui that need attention before it will be as clean as Veeam in terms of speed and usability.
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
I hadn’t recreated the job – as you suggested the new ‘Best’ job performed much better acheiving a backup size of just 4.5GB so much more in line with vRanger … time wise it took 20 mins but the throughput was only 16MB/s – probably because I was running it during the day. I will try again at night and post the result to give a final comparison…
Thanks for the info Anton.
No problems Matt. It is good for a quick test, but if you are looking to really compare the backup disk space requirements, then the testing should be much more complex than this.
For example Veeam Backup really shines in the long run: for instance, if you have most typical 1 month backup retention policy, then due to synthetic backup Veeam Backup backups take 75% less space than vRanger’s fulls+differentials .
Another thing is built-in deduplication: if you backup multiple VMs made from the same template in the same job, then even after single pass Veeam Backup backups will take 10-20 times less disk space than ones produced by vRanger.
Please let me know how your speed testing goes, current numbers are pretty small for 1GB if you have SSH connection enabled, unless ESX VM storage, or backup storage are being bottlenecks here (for instance, OpenFiler iSCSI based storage is very slow).
Hi Jason,
I will be trying incrementals over the next few days to see how vRanger 4 performs – will be sure to post my results later this week.
Matt
vRanger 4 incremental backup – ran it several days later from a full (the target guest sees little activity) and the backup still took 20 minutes – but the storage of the end incremental was only 0.37GB so a good level to get to. I have yet to test restores with any venom so will be interested to see how it handles the incrementals.
Powershell interaction next!
Your speed on incremental backups is strange our avg scan time to find changes is about 5 GB/min. So, a 20 GB VMDK would only have an over head of 4 mins. Then if I add in your transfer time of the backup size at 16 MB/s, the 20 mins does not add up. Would you mind zipping up your logs and sending them over? So we can take a look?
I have been dealing with Chris testing some differentials in the past week. Have just started a few days for incrementals as a comparison.
Not sure if it is on the list for GA or future versions but would like to see an average transfer rate in the email / reports so there is a way of trending throughput – it would be useful for fault finding …
However differentials are looking good so far – fast and reliable with no failures for a 9 day continuous run.
I am still having trouble fathoming the powershell side – the get-help is ok but because I can not access all the templates in the beta it is tricky to get all the functions working.
Veeam leverages synthetic backup, so altering compression settings on the existing job will not have any effect existing backup size. You should create new job with Best compression selected at the time of creation, then compression results should be very different.
Also, the backup speed you are getting is quite slow for Veeam: did you provide SSH connection settings in ESX host properties, so that Veeam Backup could leverage the service console agent?