What happens with an incomplete Capacity Tier (Cloud Object Storage) Move?

[premeau]

I am starting my exploration of SOBR and Capacity storage.

I am trying to move a ~1TB Desktop image over a "SOHO" / consumer internet connection (Meaning bad upload speeds.)

The initial copy is expected to take long enough that I do not expect it to be able to complete before something interrupts it.

I ran a "small scale" manual move, and it appeared that most of the existing blocks were deleted when the next manual move was triggered.

Does Veeam keep track of the blocks that have been transferred from the incomplete transfer and use them for future transfers, or will it re-transfer anything that is transferred prior to the indexes being moved (created) in the cloud?

[veremin]

The blocks that have been successfully moved to the capacity tier (even during incomplete transfer) will not be re-uploaded during the next session. Thanks!

[premeau]

This is not matching up with what I am seeing... over 400GB representing over a million object storage blocks have been deleted during two move to capacity tier restarts.

(I have the stats from Wasabi..)

S3 compatible service is Wasabi.
Veeam 9.5.4.2866 (9.5u4b)
Encryption is enabled on the object storage repository (not on the source / performance repo).

If this is not the expected behavior, I will open a support case.... it certainly seems as if I will not be able to get the backup seeded to the cloud at the current pass. (And even if I successfully seed my backup, I will pay a pretty large premium for early "deleted object storage" with Wasabi..)

[Gostev]

Yes, it is definitely not expected. Our object storage integration was designed from ground up with public cloud in mind, so the engine fully expects the Internet connection to come and go, and is capable of resuming transfers without restarting from scratch.

Having said that, for low bandwidth connections in particular (less than 50 Mbps), you may get better results by instead copying backups to a Veeam Cloud Connect service provider that supports our built-in WAN acceleration. This does miracles, reducing bandwidth requirements (and thus speeding up transfers) up to 10 times.

[premeau]

Support case 03871980 has been created.

[veremin]

Thank you for proving us with the case Id. Kindly, keep working with your support engineer on finding the root cause. We will follow the investigation internally, and provide additional help (if any is needed).

Thanks!

[premeau]

Just to update this for the forum.

My current support case is 03948454. (I was out of contact during the holidays.)

The key detail in my issue is that this was during the movement of the first backup from the job to the SOBR capacity tier (no previous block checkpoints exist) and the job is interrupted (for any number of reasons) and is restarted with a different backup file from that job.

In that situation, it appears to be functioning as designed, all of the blocks uploaded after the last checkpoint are deleted. I am currently asking if there is a good way to prevent that during the extended initial seeding of a large backup set. (At my current upload bandwith and backup set size, I need 16+ days for the initial seeding. (The change-sets after that are substantially smaller and would transfer in under an hour.)