Comments on: Veeam 3 Backup Faster, vRanger 4 Smaller ?

By: Matt Roblin

Matt Roblin — Fri, 19 Jun 2009 09:10:07 +0000

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.

By: jmattox

jmattox — Thu, 18 Jun 2009 23:04:37 +0000

Matt,

How did this go with vizioncore support?

By: Jmattox

Jmattox — Tue, 02 Jun 2009 01:02:19 +0000

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?

By: Matt Roblin

Matt Roblin — Mon, 01 Jun 2009 13:27:37 +0000

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!

By: mattroblin

mattroblin — Wed, 27 May 2009 17:56:04 +0000

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

By: jmattox

jmattox — Wed, 27 May 2009 13:48:38 +0000

Mattroblin, it would be interesting to see the backup time and size for vRanger 4 incremental’s.

By: Anton

Anton — Wed, 27 May 2009 10:22:15 +0000

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).

By: mattroblin

mattroblin — Wed, 27 May 2009 09:46:04 +0000

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.

By: Anton

Anton — Wed, 27 May 2009 08:48:08 +0000

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?