Is there a proven way to prevent a long running backup scheduling overlap where you have a backup that hasn’t finished yet and a new one starts on the same repository?
It doesn’t seem like restic’s locking system prevents this. I want to schedule restic to run every few hours, but if it is already running I don’t want to cause problems so I want it to abort. Once the backup is caught up, it shouldn’t be a problem but when it has a lot to upload offsite, it might take longer.
I just want to share our approach to a similiar situation.
We once had the same requirement but no parallel backups on the same host, instead parallel restic forgets on various hosts which require exclusive locks on the same repository. We could not use flock or similar tools because they’re bound to a host and do not support cross-hosting mechanisms.
We then decided to use consul locking for this. We already had a consul instance running where all hosts which are backed up had access to via https endpoint. The idea then was a 2 step approach for the restic forget:
create a lock on central consul instance
do the restic forget and release the consul lock afterwards.
We automated it via setting of the following environment variables: