Every day, I am backing up 2 archives to the same (remote) REPO and the 2nd fails due to timing overlap.
If you were on OMV 8 and the latest borg plugin, it would automatically wait 3600 secs.
So, you should set BORG_LOCK_WAIT to 3600 in Environment Variables tab for that repo.
I did that (even to 7200) but borg ignores that variable.
Not sure what the problem is. It works on omv8 https://github.com/OpenMediaVa…rgbackup/default.sls#L148
All I can say is to upgrade. I'm not going to change anything with the omv7 version.
The export works but Borg <2.0 ignores that variable. Or have you ever succesfully tested the lock wait?
That is the problem with remembering something I added seven months ago. I found out the env variable didn't work but left it in preparation for borg 2.0 since omv8 still uses borg 1.4. The flock changes were to really fix the issue and prevent the collisions. I have tested that every single night for months on my own primary server (not dev or test) where I run four jobs at the exact same time to one local repo and three jobs at the exact same time to one remote repo. I use this plugin heavily and dogfood changes before pushing it out.
so you implemented a workaround that prevents the collision in OMV8 by default without setting the env? Is that right?
Yes. flock is a tried and trusted tool for that exact purpose. It is not really a workaround. It is just external to borg. I use it with many scripts at work that I don't want to collide.
I am surprised that you had to go through implementing this and Borg doesn manage that by itself.
It would make sense. I guess they just assume people will create their own queue. This problem wasn't a problem in earlier borg plugin versions because people couldn't change the time the tasks ran. cron kicked off a run-parts (just run all jobs in hourly directory for example) which would run the jobs serially.
Don’t have an account yet? Register yourself now and be a part of our community!
