Slow

[DanielJ]

I have set up a new VBO server and patched it to v5.0.2.42. I find it runs slow beyond all reason. I had the same customer previously on a VBO 3 server, they do have a lot of data but the incrementals still finished in under 24 hours most of the times. Now I'm just backing up a part of the previous data (Sites), an incremental has been running for 17 hours, "processing rate" alternating between 0 and a few kb/s, the object count is up to about 10%. It feels like I'm missing something. Storage is the same as before, CPU and RAM as well (using a few percent CPU, and more or less constantly 18 of 24 GB available). I have played around a bit with the proxy thread count, with no noticeable difference. I know there is no such thing as fast backups from O365, but my expectation was that VBO 5 would run more efficiently than VBO 3, and definitely not a lot slower. Is there anything obvious I can check or try before opening a ticket?

[Polina]

Hi Daniel,

After v3, there were a few changes to sites processing, but anyway, the speed decrease doesn't look right at all. Please open a case with support to troubleshoot and share it's ID here.

Thanks!

[chris.childerhose]

Did you try adding additional backup accounts to see if that helps with the speed? Check here - https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=50

[DanielJ]

I finally managed to convince the customer to create some auxiliary backup accounts, which I have added to the configuration now. Will they be used right away or the next time a job starts? It's still the same job running as in the original post 13 days ago, so I'm hoping it will help without having to restart. But I guess not. So far I'm seeing the same depressing kilobyte speed. Also: should/could I increase the thread count now that more accounts are available?

Edit: I tried to find out from the proxy logs what accounts are used, but it seems that info is only logged when throttling occurs.

[Polina]

The new configuration is applied immediately, no need to restart a job.
The usage statistics on aux accounts is displayed in logs upon job completion. You'll see how many requests were processed by each of the accounts (or apps) from the pool.

By increasing the number of threads, you'll increase the risk of throttling at the same time. So before doing that, I'd check the logs for 429 and 503 errors. If those are still present, then you may consider adding more aux accounts rather than threads.