Guidance: Initial SOBR replication with Offload Window: Does it start again?

[Wallachuck]

The initial SOBR disk to disk to cloud backup is a 2.5TB vbk file. It's a poor 30Mbps upload internet connection and the "Offload Window" is set to stop the cloud object storage replication the during working hours.

It's running a few evenings now but I noticed each evening when it starts up the cloud object storage replication, the progress bar seems to imply it's starting again from the very beginning and not continuing on from the previous day. Can anyone confirm what is happening here? If you set an Offload Window and the job is not finished does it start again the following day or does it continue from where it left off?


Also, one other question. It's not currently a problem but it could be in the future so some guidance would be great:
The disk backup repository is a standalone USB disk. Let's call it say: Z:\Backups
If this USB disk fails and a new USB disk is put in with an empty Z:\Backups, how does Veeam and the SOBR offsite replication handle this sudden loss of local disk backups?
I enabled " This repository is backed up by rotated drives" just in case the USB disk fails and I put a new USB disk in it should just run a full backup but then I read SOBR doesn't like this option.

[Wallachuck]

Last night (day 12) it uploaded approx 110 GB of the 2.5TB vbk full backup file

In Veeam, drill down to "Backup Infrastructure" - "Backup Repositories" and the scale out repository shows "used space 59GB".

However in the cloud bucket (scale out repository) shows: 3TB used. This should have been enough to store the 2.5TB vbk full backup file in the cloud bucket. Yet the offload of this filename starts again each night when the "Offload Window" is ready.

[sfirmes]

If you set an Offload Window and the job is not finished does it start again the following day or does it continue from where it left off?

During the next offload, VBR will resume from the last checkpoint that was established during the previous offload process.

Thanks

Steve