Would like some details on this ticket.

[backupquestions]

Ticket 04287742

I have a long standing cloud connect performance issue with my provider. This ticket was created by me and then the provider has been working on the issue with veeam support for a few days. (This ticket is recent but the issue has been there for months if not over a year) I've had other posts in this forum about it that never ended up with a real answer.

The provider says that veeam support believes from the logs that there is a "jittery connection" to them, and that our tenant is the only one receiving these "failed to receive" errors.

I would like some proof in the logs and confirmation that this is what has been found, because I find it hard to believe.

Each night the actual data copies go very smoothly, like 300gb of data across 75 or so vms is done in a few hours, but when we have issues it is almost always the "merge" portion of the job. This is when all the data is already done copying. The merge is a process that happens on the cc end right? It uses their cpu and their storage. This merge takes 6 to 10 hours and sometimes more to finish every day even when working fine. Would a jittery connection even cause this if it was true?

We have a 1gb connection to the internet upload and we have 0 issues with any other cloud service including utilizing wasabi for sobr stuff.

A lot of times in the veeam job stats it would say things like "all dns alias failed tonic provider" or similar as I'm just paraphrasing. Or it would say "cloud gate rejected connection".

I just need to get to the bottom of this and find whether we really have some kind of connection issue or if the issue is cc provider side. I would appreciate if some veeam management could take a look at what has been found and let me know. I would really like some high level engineers on this because the entire time we have had cloud connect we have this issue. This is our second year in it.

[foggy]

Hi Alabaster, the merge indeed happens on the repository side unless it is CIFS without a gateway on the target side. Could you please confirm this is not the case? You could also check if there's any traffic at the time it happens. There are not much details in the case you've mentioned but I believe you could ask your provider to include you in communication if you want to get some proof of what they've been told by our support.

[backupquestions]

It is a cloud connect repo added the normal way where a backup copy job is then pointed at it. It is not a cifs share.

Are you guys able to see what communication was given by veeam staff to them?

I will ask them to provide this as well.

[PetrM]

Hi Alabaster,

The ticket is on hold since provider works on the issue with our support team in a separate case. However, you may want to talk to a support manager in order to clarify the situation.

Thanks!