Multiple Errors on S3 Offloads

[kavanelli]

Hi,

I had a Case opened #06289567 regarding issues with our offloads.

It was opened for months and the before it was closed we were at a stage were there was an issue with our Cloud Partners Cloudian storage and a case was opened with Cloudian. Even though I updated the ticket multiple times that we were waiting on Cloudian to resolve their issue. The Veeam Case was still closed.

Cloudian have come back and said their issue is resolved we are still seeing lots of Offload jobs failing with the following error

12/14/2023 2:14:01 PM :: DeleteMultipleObjects request failed to delete object [Veeam/Archive/Backups/91949ee7-e666-4324-8732-f9163da6cb3a/a27cab50-07bd-4310-bfe9-00c64e7f9946/blocks/9e35e8b0e72debf8691c1f38aa1e6ca7/1997.9657103a58f11aae264d97d3d23b4abe.33e6293b22f310efd4575bda479aae43.blk] and [229] others, error: ServiceUnavailable, message: 'The server is temporarily unavailable. Please try again later.'

Or

12/14/2023 2:08:57 PM :: Scale-out repository rescan is required: performance tier is not synchronized with capacity tier


I have run a Rescan of the Repo, anyone any ideas of this issue or how to get a Case reopened

[Gostev]

Hi, you can always open a new case and refer in it to the previous case. But from the above I see no reason to open a Veeam case as our support engineers won't be able to do anything with a 3rd party storage device being "temporarily unavailable" and will rightfully tell you to contact the storage vendor to solve this issue first. Thanks

[kavanelli]

@Gostev It was being investigate for Months before the 3rd Party was involved. It was just an RMD scan that was required which had been carried out 2 time previous during the ticket. There were multiple errors not only relating to the 3rd Party but the Case was still closed

I have a opened another ticket and referenced it, but this was a ticket opened for a few months and I'm afraid that I will have to go back over the same steps with a new engineer waste a lot of time.

[Gostev]

Sounds good. I can see how backup storage availability issues can result in multiple different features failing spectacularly so perhaps in the end it was all related in one way or the other. Remember our support operates with an immense customer base and so any real product issues are immediately highlighted and amplified with hundreds of identical cases, sometimes in a single day! So whenever they see some atypical failures in one particular environment only, it immediately provides them a strong indication of those issues being storage-specific.