Closed stuckj closed 3 years ago
No, it is not expected.
If the incremental job duration is less then cron period there is simple workaround:
RUN_JOB_IMMEDIATELY=yes
I think you're thinking of the opposite issue (which isn't really an issue). The duration isn't less than the cron period, it's MORE than the cron period. RUN_JOB_IMMEDIATELY
just starts the backup right away. I'm having the problem where I have a backup every hour, but the backup takes longer than an hour so multiple backups end up running simultaneously.
I had expected the backup to not start if the previous one hadn't finished yet, but it doesn't look like that check is done. I think it's relatively easy to add to backup.sh
though (i.e., just a PID file to indicate a backup is running). I think there actually needs to also be a prune PID file and neither backup nor prune should start from cron if either a backup or prune operation is already in progress.
I agree with you that this is the issue and it should be fixed.
I can try making the modifications and send a PR later this week. Bit busy right now. :)
Finally got around to this. Here's the PR: https://github.com/azinchen/duplicacy/pull/15. I tested this locally and it appears to be working.
Merged
It seems like there is no protection against multiple backup jobs running simultaneously. I have a large backup that finally completed and I noticed that the CRON jobs just start a new backup job based on the schedule regardless of whether the previous backup job actually finished or not.
Is that expected or did I mess something up?
If expected...then I guess I'll have another PR to work on. That seems like a recipe for disaster for large backups. :)