Long (impossible) backups over WAN

[b.pedini]

Configured a job on my personal PC (Windows 10) to perform regular incremental backups on working days and an active full every Sunday, everything at 14:00; however since I'm using a SMB connection over WAN to a storage box from Hetzner (https://www.hetzner.com/storage/storage-box/bx20), this takes huge amount of time even tho I toggled the specific settings to use more of my processor to do the backup and compress to "maximum" to save bandwidth; still, it takes more than 12 hours for an active full and some times even more than 16 which then fails because I need to reboot my PC.
PS: speed test shows more than 15Mbps on upload, Veeam Agent uses just a bit more than half a megabit (Case #04582303).

Attached are the two full backups (last Sunday and today respectively):


Thanks in advance for any suggestion or thing to try!

[Gostev]

Internet speed tests typically use the closest server of a particular speed test provider, so this is rarely a good indication on what real-world speed to expect, especially when talking about busy cloud providers. Try copying a file to the actual server in Hentzner from the machine you're backing up - I see from the link that their boxes support SMB, so it should be easy to do. What transfer speed do you get this way? Give the test some time to run, as at first the file will go to the SMB Client cache, so the speed numbers will not be correct at first. Thanks!

[b.pedini]

Hello Gostev,
Thank you for your suggestion.

I'm currently running an ISO file copy from my Windows 10 PC to the Hetzner storage box with sustained speed of around 2.5Mbps almost stable with some quick spike down here or there to 1Mbps.
I know it's not much but for the price for gigabyte, it's doable. However it seems Veeam uses just shy of more than 1/5th of that speed, and surely not full bandwidth.
Also, tell me if configuration inside the job in the client matters, and if that is needed so I know if to post it over here.

Quick note: it also seems that short (incremental) backups get pushed anywhere from 2Mbps to 3Mbps, while I didn't see a single active full going more than 1Mbps for the main drive.

Again, thank you.
Bryan.

[Gostev]

From Veeam backup engine perspective, there's no difference between full and incremental - in either case, it's about the Source data mover reading the required disk blocks from VSS snapshots, and sending them over to the Target data mover. So perhaps there's some throttling going on the Hetzner side due to the amount of data in case of the full backup.

I would try doing a test backup to a different target to see if Hetzner is indeed the culprit here. With this test, it should be clear where the issue lies.

Normally, with local targets Active Full backup should be a bit faster because it is does sequential I/O, whereas incremental backup involves random I/O.

[b.pedini]

Indeed with local target was extremely faster, even with the community version of Veeam B&R on a Proxmox VM on my local home server.
However I would practically need this box to store my backup data, since my server is hardware-wise so unreliable that I'm mostly not trusting it anymore (thermal design so bad every SAS disk fails within 1.5ys of install, SATA is a little bit better but still, overheating drives).

I'll try to create an SMB share on a Linux box on my server (also @ Hetzner), linking to the storagebox mounted on the "VPS" (Proxmox VM too), and see if the issue is with the WAN of the storage box (internal traffic goes to a different route, might be better to use the WAN of the dedicated server instead) or if the box itself is a bottleneck.
Perhaps I could try to rent a box from another provider too for a couple of days / a month and see if that changes anything; since I finally have fiber to the cabinet @ home and can reach almost 20Mbps constant (compared to 1Mbps barely before fiber), I would like much more to use it fully for the couple tens of minutes it requires for an active full and less than a dozen for an incremental, rather than using bandwidth for long periods of time with the possibility of it crashing and needing to start over 'cause there is no "resume" function in Veeam if it fails. (remember, at the moment even an incremental starts from an hour-long and goes more from there)!

That said, thank you again Gostev for your time in this topic,
I'll keep this updated with the results.