Feature Request: Allow Backup Copies to continuously run

[KelKnowles]

I have a number of customers using backup copies where I constantly run into the following limits:

1. If I set the backup copy interval to too high then it only copies one recovery point per interval - It would be great to just offer an option without setting an interval at all to have backup copies happen as soon as the backups appear.
2. If I set the backup copy interval to match the backup interval occasionally there are failures since incremental backups end up failing if the copy job exceeds the interval. - It would be good to provide the administrator an option to allow the backup copy to run over the interval without immediately failing. Backup jobs for example already have the "Terminate job if it exceeds the backup window" but it is off by default. I would like a similar option in backup copies to allow the administrator to choose the termination behavior. I would prefer to allow the job to run to completion instead of terminating it but backup copies strictly enforce this and it ends up resulting in tons of wasted time to keep resyncing VMs which fail to copy and unless I am mistaken it messes up the CBT on the VM backup copy and forces it to re-read much more data on subsequent runs.

Is there any way to change the behavior of the backup copy jobs in the current version with a registry entry or setting to match either one of these options? If not I would like to request the options for future versions.

[foggy]

Hi Kelly, thanks for your feedback. Under normal circumstances, backup copies happen as soon as the backups appear on source right when you match the backup and backup copy intervals. (Btw, how you backup copies are scheduled? Do you start the interval a few minutes after the source backup job is scheduled, as best practices prescribe?) If you size the copy job so that it is not able to finish until the interval expires, then it should terminate to prevent source backup job issues, since it is more important to let the latter complete successfully - this doesn't mess up CBT and backup copy will finally be able to catch up on everything it should have copied.

[KelKnowles]

Foggy, I would love it if there was a way to completely remove the backup copy interval altogether. I want to be able to just move all backup recovery points to into backup copies to a secondary location - in this case CloudConnect. I typically keep my primary backups as forward incremental with periodic synthetic full so there is not an issue with the source files in use like there would be if I used a different method.

The main issue I seem to have is if something happens to make the incremental job go over the interval than it churns a bunch of time which just seems to get wasted. If for example, you have a VM with a disk where it gets 1TB of changes and you get 960GB through the copy of that disk then the interval expires then the job will fail leaving that 960GB of copies as an incomplete copy and during the next cycle the software will spend a lot of time just re-reading the same 960GB of changes that has already been sent versus just sending the remaining 40GB of changes. I usually have to manually go and change the backup copy interval to much longer to just ensure that I get a good copy when something like this happens.

I would also think it would be great if there was just an option to use the backup copy interval as it is currently designed but allow it to be gracefully terminated meaning it would not start a new VM after the interval but would complete copying the VM that is in-process when the backup copy interval expires.

I had an idea which might work which is to create a PowerShell which checks for the backup copy state to be idle and then performs sync now if it is idle. I would then run that as "Run the following script after the job". I have never done this before so if anyone thinks it is viable and would have an example of the script it may do the exact behavior I need.

[mkretzer]

I would also wish the copy interval to disapear. This is a construct that caused us headache exactly for the reasons mentioned here.
The system should simply copy as soom as a backup is there and should take as long as it needs. If there would be a warning like "copy job running longer than x hours" it would make more sense.

Every day we have messages about copy job not running in its timewindow... Most of the time when the job starts again and the source is still running. These kind of messages lead to me and my colleagues ignoring Veeam error mails which is bad.

I discussed it with Veeam support:
- Setting Interval to more than 24 hours (our source jobs run once a day) lead to backups not immediately copied
- Setting the interval to much less than 24 hours lead to even more mails
- Setting the interval to about 24 hours still causes mails when source jobs take slightly longer but seems to be the best option

[foggy]

If for example, you have a VM with a disk where it gets 1TB of changes and you get 960GB through the copy of that disk then the interval expires then the job will fail leaving that 960GB of copies as an incomplete copy and during the next cycle the software will spend a lot of time just re-reading the same 960GB of changes that has already been sent versus just sending the remaining 40GB of changes.

This is not the case, backup copy will not copy it all over but will transfer only blocks required to build the latest VM state. This incomplete restore point contains valid data that can be used for restores.