With the move to v9 and per-VM copies, I seem to have come across a major issue with the design of Backup Copy jobs.
As background, my infrastructure is:
Manager Server (virtual 4 cpus, 8GB ram), Manager server is disabled as a proxy.
2x Proxy server (each one has 24 cores, 64 GB ram, 2x FC, 2x10Gbe)
3Par 7400 storage
DD2500 with 10 DDBOOST repos handling various production/non-production lines of business.
Gateway server for each repo is set to automatic. Unless I'm missing something, this configuration allows a backup job to be load balanced between the two proxies (and looking at network performance during backups that is the case). So each proxy is writing to the repo at the same time and we get good throughput on each job.
We had backup copies running on v8, from one repo to another repo on the DD2500. Performance was slow, but tolerable and understandable as we are going from deduplicating storage to deduplicating storage. As we upgraded to v9, we also switched over the per-vm files on the repositories (which if your are using DDBOOST or StoreOnce is a god-send for performance). However, I then noticed that the Manager server was handling all of the Backup Copy jobs and was loaded (total memory consumption). Scanning the Backup copy job, the difference in load on the Manager is that due to the per-VM files, the Backup Copy job process spawns many threads to handle each VM which loads the machine.
Having opened the ticket with support, the only offered solution is to set the gateway server for the repository. Now as I noted above, I do not do this as it achieves load balancing between my proxies. If I set a gateway server, I have to drive all my traffic through a single server on a backup job even though I have two proxies. The disabling of the proxy on the Manager does nothing to affect it's ability of a data mover for a backup copy job. Without the gateway server set for the repo, from tests that I tried, the Manager is always selected to move the backup copy job. Disabling the data mover service on the manager server just causes the Backup Copy job to fail. So I end up with an under-powered Manager server trying to be the data mover for the Backup Copy job when I have beefy proxy servers sitting idle.
It make me see that there is several design issues with Veeam in regards to Backup Copies.
- First, you should be able to turn off the ability of a server to be a data mover. Especially for the Management server.
- Second, if a data mover is unavailable, move onto the next one, don't fail the job.
- Lastly, the Backup copy job should have the ability to set a list of proxy/data movers, in the same way that the backup jobs can
I suspect that this will be fixed at some point given the progress I've seen since starting working with v6. It's just disappointing seeing the performance increases with v9 per-VM, and the to lose some of that by having to hard-code my proxies.