Periodic Copy job retention reset

[ortec-RW]

Hi

I'm having troubles with my Period Copy (pruning) jobs. These jobs in fact are running continously. Only when the periodic moment is there, do they actually start doing something. The rest of the time they are idle, but are still running.

But the trouble starts when I have to reboot my Veeam server. Off course this reboot needs to stop or break these continous jobs (you cannot have a running job on a server that is down). But why don't the jobs go back to their idle state when the server is back and running again ? Instead they create a new restore point right after the server is running. As if it were the first time they were started. In fact they were just started, but the periodic moment is not there yet.
This means I get a new restore point for free, but it messes up my retention count.

Say I have a Copy Job that runs continously, but only needs to do its thing once a month. I set the rentention to lets say 6 months. Meaning I always have 6 restore points available spread apart 1 month each. But If I do a server reboot somewhere within those 6 months, the job get reset and creates an additional RP and this means I loose the oldest RP. And the new RP is no longer spread out 1 month like the others. Asuming I don't do the server reboot at exactly the moment a monthly RP should be made.

Am I missing the point ?
Do I need to do something to prevent continous jobs being reset this way ?

Grtz
Richard

[PetrM]

Hi Richard,

I've just discussed the case with my colleagues from QA department and it's not expected that backup copy creates new restore points after reboot, perhaps this is just a coincidence and the interval itself was expired? If not, then please open a support case and share case ID with us.

One more thing to try is to disable the job before reboot and enable it back after Veeam server is up again. If you make reboots on schedule, you can script it using these cmdlets.

Thanks!

[ortec-RW]

Hi Petr

Just finished some additional testing I did this afternoon. I cannot reproduce the issue on a test system/job/object in combination with those reboots. So your story is true, which makes sense. I would not have expected this behavior at all.

I now think the issue is with the orginal data, causing new restore points to be created or still there, that need to be copied by the Copy job the moment it starts (after reboots). If these never finish, the restore point stays in limbo and the whole thing repeats after the next reboot.
Need some more time to figure out if this really the case, since we did have some issues with the original job that this copy-job gets its source data from. If I cannot make sense of it I'll open a call.

Greetz !!
Richard

[PetrM]

Hi Richard,

Ok, please keep us posted on results of your tests. Also, I suggest to keep in the criteria for new restore points selection:

Code: Select all

Time of restore point creation >= current time – backup copy interval

You can find additional details on this page of our help center.

Thanks!