Issues backing up to Nutanix Objects

[lperezg]

Hi there,

I have a customer who is using Nutanix Objects as primary repository. Since the implementation he had multiple issues, most of them related to slow backups. They are backing up 240 AHV VMs & 20 SQL Servers with t-logs every 10 minutes (using VAW). All this backups go to a single bucket.

I reviewed the rescan tasks that Veeam runs periodically and now they are lasting 20hs or more, and in some buckets (there are some buckets that they have to create due to the previous bucket stop working) didn't even allow you to open a backup to restore from Veeam Explorers.
In the rescans the only error that I found is the following

Code: Select all

28/03/2024 10:33:06 a. m. Warning    Failed to synchronize o-s3-vmapp-xs-f4 Details: S3 error: Reduce your request rate. 
                                     Code: SlowDown 
                                     Agent failed to process method {Cloud.AcquireLock}. 

I take a look at the cases DB (or what's left of it) and I saw this same issue in a Dell ECS storage, pointing to saturation in the read/write tasks that the storage needs to run - but there was no solution posted (Case #06002818).

Is there any best practices or guide to follow to configure direct backups to local object storage?

[ronnmartin61]

We recently added a few jointly-agreed to practices to this Veeam Ready listing for Nutanix Objects - https://www.veeam.com/sys289

[sfirmes]

Luciano,

Is there an open Veeam Support case for this? If not, they should open one. It looks like the object storage might be getting overwhelmed due to api workloads since the warning text looks similar to the http 503 message that object storage platforms generate when they are getting overwhelmed. But without the log files, it is hard to confirm.

Also, you can reach out to me via Teams/email at anytime to discuss on-prem object storage performance.

Thanks

Steve

[lperezg]

Thanks for the reply Steve. The last case that the customer opened is #07186154 however they moved their backups to a NAS repo now to avoid the loss of data while we found a solution. I'll ping on Monday to review this, thanks!