Since day 1 we are tuning our VB4AWS environment but its everything but stable. Health check detects corrupt RPs etc. We were told to no run backup jobs at same time of retention job which is running at midnight. But our backup windows only starts at 8pm, so we will always hit the retention job.
Our largest job is having only 89 instances. It's often running ~22 hours due to some single large VMs - it's failing often. In the logs there are AWS messages to slow down requests. I know that AWS has a documentation how to work around this limits with different namespaces. I get the feeling that VB4AWS is not optimized to do that. In general VB4AWS needs a lot of attention an fine tuning. How does this work for people that really have a lot of VMs?
Are you already running on the latest version? As there have been plenty of optimisations to overcome some of these points.
For overcoming AWS limits, it may be needed to talk to AWS to enhance the limits for those accounts but that is hard to tell via the forums.
Additionally, we have our sizing guide (https://bp.veeam.com/vbcloud) to assist you with numbers and examples. Which instance size are you running for the appliance?
Personal blog: https://foonet.be
GitHub: https://github.com/nielsengelen
If you consistently keep hitting those limits, we can try to work together looking into your accounts with your local Veeam team however we have seen accounts where AWS had to assist.
Are you already in contact with your local team by any chance? I’m sure we can figure out and optimise things together.
I will also look into your cases and DM you once I have feedback / more clear information.
Personal blog: https://foonet.be
GitHub: https://github.com/nielsengelen
What do mean with 'local team'? It's just strange that we run into so many issues when backing <100 AWS instances to AWS S3. In on-prem VBR we backup ~1500 VMs and offload them to S3. We don't see those big issues there, we also had some issues there with 'slow down you requests' but could workaround it. But AWS support also told there that the request coming from Veeam are not optimal. But this is support, no R&D.... Anyhow, backing up <100 instances in VB4AWS is much more error prone and takes ages compared to S3 offloading. But it's maybe a completely different process.
It is indeed a very different process underneath. The end format is the same but it’s not the same logic. I am surprised AWS team states that as we just benefit from their native API’s and have worked together to optimise it on all sides. Could you provide me more details by any chance in DM?
Again, most likely this is a matter of adjusting the worker size and more insight in your infrastructure. And with local team, I mean your usual Veeam sales team your company works with.
I’m still digging into the cases but will send you an update once I find out more.
Personal blog: https://foonet.be
GitHub: https://github.com/nielsengelen