Can restic handle `backup`, `check`, `check --read-data` ran concurently?

Getting Help
1

Can restic handle backup, check, check --read-data if they happen to run concurrently?

(read: systemd, .timers firing at independent schedules)

1 Like
2

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.

2 Likes
3

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?

4

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.