SOBR offload fails on single vm - NoSuchKey

[squebel]

Hello,

We have had case 07168234 open for a few weeks now. There is a single vm in a job with about 40 other servers going to a standard SOBR that is set up for immediate copy over to a capacity tier bucket that's throwing this error - "Processing JOBNAME Servername Error: S3 error: The specified key does not exist. Code: NoSuchKey". Support is basically suggesting there is no way to fix it for this single vm and we have to basically either start from scratch for the entire job which seems just ridiculous or pull out this one single vm and create its own special config in order to get around the problems it is having.

I'm hoping that some of the Veeam engineers and product managers see this and have a better suggestion. I can't understand how this one vm can't go through some kind of resync or whatever to get it back in sync with everything else.

[Mildur]

Hello Squebel

I checked the case. As far as I know, this was the only option for older versions we had.

May I ask, are you using v12.1?
Our capacity tier health check should recognize missing blocks and upload them again from the performance tier:
https://helpcenter.veeam.com/docs/backu ... tier-works

If the health check detects missing data blocks, Veeam Backup & Replication marks these blocks and restore points associated with them as corrupted. Veeam Backup & Replication will upload these blocks to the capacity extent again during the offload session.

Maybe that could solve the issue you see without creating a new job or using a new bucket.

Best,
Fabian

[squebel]

Fabian, thank you for the response. I have enabled the sobr healthcheck. Surprised that that was not suggested earlier in the case. I will say, I had another similar situation but it was with a straight copy job to an S3-backed repository (not sobr capacity tier) and the heathcheck made no difference.

The job was originally set up in v11 but we are at 12.1.0.2131 now.

I have updated the ticket with some new notes about multiple offload tasks with different names for the same sobr and the same vm failing in different tasks which is confusing.

[squebel]

Update on this: nothing cleaned it up. We had to move stuff out and get creative with how to make the jobs start working again. Not ideal to say the least.