Question regarding Backup Copy Jobs targeting an immutable Wasabi S3 bucket

[massimiliano.rizzi]

Hello Community and good day,

first things first, Case # is 06398030.

We are noticing across different customers that it seems like that apparently, Backup Copy Jobs targeting an immutable Wasabi S3 bucket are simply taking too much time to process the VMs for the small amount of data being transferred. You can consider, for example, the screenshot below. Available upload bandwidth on the Veeam side is capped to 40 Mbps anytime:

==================================================

==================================================

It seems like that overall performance of these Backup Copy Jobs is kind of "slower" to an extent that either it takes a lot of time for these jobs to complete or these jobs exceed the allowed window and, as a result, Veeam Backup & Replication will automatically stop them.

I’m wondering whether we are not probably facing an issue here, but instead what we are observing is the nature of Backup Copy Jobs targeting an S3 bucket located in a Public Cloud and not on-prem, which depends on both network bandwidth constraints and load on the public cloud side at any given time. Is it correct to say that there is a heavier lifting on the Veeam side when using Backup Copy Jobs compared to a S3 bucket part of a SOBR ?

Any help on this matter will be greatly appreciated.

Thanks and Regards,

Massimiliano

[ken_weise]

Hi, no help here, but we're seeing the same thing. Over an hour to complete a copy job to Wasabi, for a few GB of data over a 1 gb/s connection. The data itself copies up in less than 1 minute. Four other steps take 10-15 minutes each "Initialize Storage", "Update Metadata", "Finalizing" and then even after the Finalize step, some jobs remain at 99% for an additional 10 minutes or so. At least this is what I'm seeing.

[massimiliano.rizzi]

Hi, no help here, but we're seeing the same thing. Over an hour to complete a copy job to Wasabi, for a few GB of data over a 1 gb/s connection. The data itself copies up in less than 1 minute. Four other steps take 10-15 minutes each "Initialize Storage", "Update Metadata", "Finalizing" and then even after the Finalize step, some jobs remain at 99% for an additional 10 minutes or so. At least this is what I'm seeing.

Hi there Ken,

I'm glad to hear that we are not the only ones in this scenario.

The screenshot below refers to a Backup Copy Job session I manually started yesterday. Available upload bandwidth on the Veeam side is capped to 40 Mbps:

==================================================

==================================================

I feel like the offload sessions, when the data is copied from the performance extents (on-prem) to the capacity tier in the cloud, require less "effort" going back and forth with a S3 bucket in the cloud part of a SOBR, and time than a regular Backup Copy Job.

I am interested to know the outcome discussion of this as I would really like to go the bottom of this.

Thanks !

Massimiliano

[massimiliano.rizzi]

Hello Community and good day,

please forgive me in advance, I would really appreciate if someone from Veeam could kindly share their thoughts on this topic

Thanks !

Massimiliano