Slow 2nd backup

[dreic]

Hi all,

we are evaluating Veeam 8 for backing up our VMs. We have 12.4TB of data, backup storage is EMC DataDomain 2500 (not DD Boost enabled) and EMC VNXe3300. DD is connected over teamed 10Gb network interfaces to core switch, VNXe is also connected over teamed 10Gb interfaces to core switch. There is no firewall between Veeam server and backup target.

Full backup to VNXe took 11:40
Full backup to DD took 6:09

The problem is backup speed at 2nd run when it needs to take incremental backup. Processing speed is 8-9MB/s which is very bad. What i see happening on the server is that Veeam is accessing backup target so i am assuming it is comparing the backed up data with new snapshot and afterwards it backs up the changes. That process goes very slow and i think that's the reason of slowness. Am i correct about the way how veeam is doing 2nd 3rd ... backup? What can we do to improve backup processing?

Thanks!

[foggy]

Damir, what are the bottleneck stats for the backup job and what backup method do you use? Is it reverse incremental?

[dreic]

Target is bottleneck , i tried reverse incremental and incremental but result is the same. Veeam VM is sitting on our vsphere HA cluster so it's using Virtual Appliance for transport mode.

[foggy]

Could you please provide more details on those job runs (both forward and reverse incremental passes, full and incremental): job duration, processing rate, amount of read/transferred data? Thanks.

[dreic]

Processing rate is 306MB/s to VNXe, DD i think it was 490MB/s for full backup. Jobs are doing forward incremental.

Rest is mentioned in 1st post.

[nefes]

Your case may be similar to ones described here: http://forums.veeam.com/vmware-vsphere- ... 24031.html
Please open support case, they will look into your logs and provide a fix, if applicable.

[foggy]

I don't see anything except the processing rate regarding incremental job runs (which produce the issue) in your first post.

Anyway, contacting support, as Nikita suggests, and providing them full logs for investigation is the most effective way of addressing this issue.

[dreic]

Ok i will contact support. Thanks!