BackupCopy interval over-ride

[Provogeek]

Have been dealing with a very problematic BackupCopy job for 6.5TB virtual machine.

With the size of the VM, the BackupCopy sync takes a very long time. We used a seed to get the bulk of the data to the DR site, and have since been trying to get our first sync to complete. This first sync has been plagued with issues causing the sync to get restarted, one of those issues is discovering a 3.1TB thin disk that had 90% blocks allocated causing huge delays in the backup even though there was no data on the disk. Then I miss-sized the target WAN cache disk size, and on top of that got hit with both a power failure as well as a router failure. [bang head on desk]. We got through these issues, got the sync back up and running each time and all would go well for a day or so, then the job would stop due to an expired sync interval. Even though I would expect the timer to start for the sync cycle at the moment I click the Sync Now button. Opened a case with Veeam Case # 00932255 and it seems the timer starts the moment the job is created, not when I click the Sync Now button.

Is there any way to over ride this behavior in a BackupCopy to force a job to keep going even if the sync cycle has expired? After this past expired sync cycle, I just allowed the system to start the sync on it's own and so far it is going well. With my own mistakes corrected, and crossing my finger no other environment issues occur, I expect this time it to complete in the sync cycle (7 days). But if the backup gods decide I don't get an off site backup of this VM just yet, I would like to not have to wait until the end of the sync cycle to start it again.

[foggy]

You can set the sync interval for a longer value to let the initial sync to run long enough to complete. Sync Now command by itself just starts the new interval that lasts until a new interval must be started according to the schedule.

Basically, if the job was not able to complete due ti interval expiration, data transfer will be resumed during the next sync interval and missing blocks (those that are required to build the new restore point corresponding to the VM latest state) will be transferred along with the changes occurred since the last source restore point.