I have been running restic for many years. It has worked very well, except: once every 1–2 months, backups fail, because the repository is locked for whatever reason. This requires manual monitoring and fixing.
There is a need for a lock free mode. I recall some back up software like duplicacy back up without locks.
Is there any plan for this?
Or restic design doesn’t allow it?
I know there is a flag ––no–lock, but this is for operations on a read only repository. It cannot be used for back up.
Update
I see Rustic can operate lock-free. It seems it’s doable. Why not importing to restic?
Ultimately, I suspect it is just a case of time and priorities. Restic has many features and PRs competing for developer time: Restic 0.18/0.19 roadmap · GitHub
It seems very likely some form of lock-free or improved locking solution will eventually be implemented, but that requires someone with the time and motivation to design and agree upon said solution, and then actually write the code
Hi, I have a script doing my backup and I always call the ‘unlock’ option before starting the backup. I then check the return code and make sure it was unlocked before continuing the script. I get an email if it does not unlock. I have never had any issue except one time when I was doing a bunch of restore and backup test. I am not sure why, but restic would leave some processes hanging that kept a lock on the repository. As soon as I rebooted the system it was all fine again.
Not a great idea. If Several restic processes access the repo , the repo may break. Lock is there for a reason, and its removal is not with a simple script.
By default restic unlock only removes stale locks. It will return a none-zero code if there is an active lock on the repository. I use it mostly to see if there is an active lock but I am fine with it removing stale locks. If a process has not touched the repository for 30 minutes it should be fine in my case if it gets locked out. The process is probably not coming back and it is time to move on. I just kind of assumed that if the failed process left a half done back up or something like that, the next backup would reset the state of the repository (or at least give me an error).
