Slow backup over 10 mbit VPN

[sjordet]

Hi!

I have a server located in a remote location. It's connected to our office over a VPN-tunnel (Juniper equipment in both ends) that runs over a 10 mbit/s L2 fiber connection. It's plain layer 2 ethernet all the way, but as we are leasing this line, we are just paying for 10 mbit/s. this is solved by having 10 mbit/s link speed on the switches in each end.

When I transfer files over the same link with ftp, I get 1100kB/s easily.

But Backup exec just gives me 12 MB/minute. 1100kB/s should be 66 MB/minute, and I would at least expect somewhere around 40-50 MB/minute. The other servers this media server does backup are in our datacenter, and have between 1500 and 3000 MB/minute.

Is this really expected behaviour on such a link? I get just around 1/5th of the link speed...

Regards,

Stian

[teiva-boy]

It's the latency and encryption overhead that is affecting this.  It's pure physics and the nature of the RAWS agent that needs a low latency link.

If you want to address this "better," (I say better not best solution) you will want to leverage the deduplication option in BE2010 R3.

[sjordet]

Hi!

Thank you for your answer. Well, I can't see how the latency can be a problem. I have 2 ms ping from the backup server to the remote server. This is with the backup running. I expect it would be 1 ms with no backup running.

And do you really mean that VPN overhead is like 75%? That really doesn't make sense, I have around 80 sites connected over the same kind of connection, with same Juniper VPN equipment all over. They don't have local servers, so all traffic goes over the link. There are no speed problems whatsoever. All file transfers goes at around 10 Mb/s.

The speed problem is only valid for the backup, so I can't see how that's related to vpn-overhead. I expect there to be some overhead, but that I can just utilize 20% of the link speed can't be right. All tests with other things than BackupExec gives me very close to 10 Mb/s.

[teiva-boy · Accepted solution]

Trial the Dedupe option, enable client-side dedupe and most of your problems will be solved.  As is, BE over a WAN link is just poor performing using standard practices.

[sjordet]

We are actually licensed for dedupe, so I enabled client-side dedupe, and it tripled our throughput. Still it's way lower than I expected, and we are migrating to a local tape drive.

We can consider this closed, but I find it weird that I can transfer 9,8 Mb/s with ftp, while with Backup Exec it's more like 4,5Mb/s even with dedup.

Thanks for your efforts :)

[teiva-boy]

While it's "only," 4.Xmbps, the bright side is that less data needs to be sent overall, negating the need for speed...

And FTP is not a fair comparison to TCP, it's a lower overhead protocol overall, often 30% or faster than TCP.  TCP has overhead in the form of error correction and re-transmits.

[sjordet]

Well, FTP is a layer 7 protocol (as Backup Exec is) and they are both using the layer 4 protocol TCP.

As they are both using TCP, it's the same overhead and error correction and re-transmits for both.