Linux Veeam proxies

[danswartz]

Thank you! I've been hobbling along with one proxy, because that is all the windows server licenses I had available. Just spun up two CentOS 7 VMs (4GB ram, 2 cores), and fired off my daily backup, but selecting a full backup. Got about 600MB/sec sustained throughput (and the proxies were the bottleneck.) Hotadd mode.

[HannesK]

Hello, thanks for your feedback.

Actually, CentOS 7 is the OS that did not have great performance out of the box in our stress tests So it's interesting to see, that it works so good for you.

The best test results we had out of the box were with Ubuntu 19.x, Debian 10 and openSUSE 15.1

Best regards,
Hannes

[danswartz]

I only went with CentOS, because it's my most familiar distro

[danswartz]

One oddity I noticed. My daily incremental runs at 3AM or so. I notice that job is still running. It's doing the 'Compacting full backup file' for the last 6+ hours! It's showing 77% done. If I monitor the Linux repo that hosts the backups, it is showing 100MB/sec sustained reads, but almost no writes. While typing this, I noticed the job moved from 77% to 78%, so it is making progress, but this seems wrong, no? The current stats show 'Processed: 299.7GB Read: 94.5GB Transferred: 3.9GB'. The repo in question has 700GB+ of backup files. While testing the linux proxies, I did a couple of full backups, so there are no less than 3 full backups in that directory that are 200GB+. I'm guessing that was not a good idea It's now up to 80%. I think when it finishes, I need to manually delete the two older full backups...

[Gostev]

In general, compact operation is handled solely by the repository-side data mover, so backup proxy platform can't impact it in any way.

[danswartz]

Understood. As I said, I suspect I caused this by running those 2 full backups, tripling the space usage in that one directory.