Can restic handle backup
, check
, check --read-data
if they happen to run concurrently?
(read: systemd, .timers
firing at independent schedules)
Can restic handle backup
, check
, check --read-data
if they happen to run concurrently?
(read: systemd, .timers
firing at independent schedules)
check
creates an exclusive lock in the repository, which will prevent other concurrent operations on the repository. In contrast, multiple backup
operations can run concurrently.
If a backup
operation tries to run on top of check
, what is the behavior expected?
I had two stale non-exclusive locks (no output anymore), that lead to:
systemd[4874]: ~/.config/systemd/user/restic-check-deep.service:8: Unknown key name 'OnSuccess' in section 'Unit', ignoring.
systemd[4874]: Starting Check restic backup...
restic[3457328]: using temporary cache in /tmp/restic-check-cache-3886536458
restic[3457328]: create exclusive lock for repository
restic[3457328]: Fatal: unable to create lock in backend: repository is already locked by PID 3651194 on h by u (UID 1000, GID 1000)
restic[3457328]: lock was created at 2023-07-04 14:08:30 (432h57m5.430750427s ago)
restic[3457328]: storage ID 4e399071
systemd[4874]: restic-check-deep.service: Main process exited, code=exited, status=1/FAILURE
systemd[4874]: restic-check-deep.service: Killing process 3457404 (rclone) with signal SIGKILL.
systemd[4874]: restic-check-deep.service: Failed with result 'exit-code'.
systemd[4874]: Failed to start Check restic backup.
Is that accurate?
Can it somehow wait at that lock?
Or then vice-versa: the check
to wait for backup
to finish?
Stale locks are currently not removed automatically, you’ll have to call unlock
to remove them. Restic 0.16.0 (https://github.com/restic/restic/blob/master/changelog/unreleased/issue-719) will contain a --retry-lock
option that can wait a certain amount of time until the repository becomes accessible. Although I wouldn’t recommend to let the backup wait for several hours.