S3 Offloading or Backup Copies - which is faster?

[wane]

Hello,
We have the requirement to backup the write-ahead logs of about 100 database servers using VeeamAgent for Linux.The logs themselves are written to a directory on the respective systems.
The Veam Agent job then backs up these files every 30 minutes from directories or mount points or partitions. The Veeam Agent Job is successfully and backed up regularly within a backup job and in less than 30 minutes.
The second challenge, writing copies (immediate copy) to a remote location, often fails and we also have no synchronous data between backup and copies because the copy job takes longer than a backup job, e.g. more than 30 minutes.

We are now considering whether we are faster and more performant with a capacity tier and "copy backups to object storage as sonn as they are created" than with backup copies.

Hence the question of whether it is possible to make a general statement as to whether S3 offloading is faster than backup copies.

By the way: both repositories (backup and backup copies) are All Flash systems.

[veremin]

Hence the question of whether it is possible to make a general statement as to whether S3 offloading is faster than backup copies.

No. It primarily depends on the speed of your Internet connection and the speed of network connection to the remote location. Thanks!

[Andreas Neufert]

What does the current backup copy job show as bottleneck?

[wane]

In this case a backup copy job doesn't show the bottleneck in the statistic window as a backup job does..Maybe because of using Veam Agent, I don't know...

[wane]

No. It primarily depends on the speed of your Internet connection and the speed of network connection to the remote location. Thanks!

Our remote site is connected via dark fiber at 40g. I definitely exclude the connection as bottleneck...

[Gostev]

Then something else is a bottleneck... our support should be able to tell from performance debug logs.

In general, I would expect S3 offloading to be at least a few times slower than Backup Copy in your environment.

[wane]

I will open a support ticket and post the result...

[wane]

We may have found the solution. It was the vCPU configuration. We had 2 cores per 7 sockets. The MS SQL database could not deal with this. We switched to 14 cores and 1 socket, and now everything runs perfectly.
There are restrictions for the MS SQL standard at this point.