Restic adds a lock to the repo during backup. If the process is killed during the backup, and the process is restarted and automatically resumes the backup, will there be a lock conflict? How should this be handled?
1 Like
The lock that backup creates is a non-exclusive lock, and since a backup only adds data to the repository, you can run the second backup attempt without problems. There will be a second lock, yes, but the first one will not be in the way - non-exclusive locks can co-exist.
You will only be hindered by the first lock when you want to run commands that need to delete/replace existing files in the repository, such as prune. If there is a lock in place, it will tell you and you can then use the unlock command to remove it, if you know itās just a stale lock.
3 Likes
Thank you for your response. If my script does encounter an abnormal termination after adding the exclusive lock, how should I automatically handle such exceptions in my periodic automated script?
1 Like
Thatās mostly up to you, but if you know for sure that that lock there is stale, then you simply delete it and re-run the command you want.
Edit: I realize I didnāt answer your question. Well, if you are running a script, and it (restic) detects a lock that prevents it from running, you effectively have two options. You can either delete the lock, or call for manual intervention. If you do the former, you of course need to make sure that thereās no other restic process using the repository. At the end of the day, it all comes down to your specifics.
1 Like
thanksļ¼I got it.
I have another questionļ¼in the manual referenceļ¼ if a exclusive lock with ālocks with timestamps older than 30 minutesā is considered a stale lock
If the restic check command takes more than 30 minutes to complete, the lock will be considered a stale lock, allowing it to be unlocked and running prune command. Could this potentially lead to data inconsistency issues?
A stale lock in itself does not cause any corruption. What could cause corruption is if you have multiple clients changing the contents of the repository in other ways than by just adding data to it.
That is not correct. Locks are continuously refreshed by a command to ensure that the lock does not become stale.
Okļ¼thank you for replay
Just to clarify; A stale lock can be caused for example by a restic process starting a backup, prune, or similar that creates a lock file in the repository, but that is then disconnected from the network, shut down or otherwise cancelled in a way such that it is unable to clean up and remove the lock file in a controlled manner. The lock file would then reside, and be detected by another restic process.