So here’s a question… what happens if a client is backing up, but then isn’t paying any attention to it and closes the lid of their laptop and goes home?
I’ve got a stale lock now. I can call restic unlock which will probably remove it - but what happens if the client wakes up and reconnects? What happens if I run a prune, THEN the client reconnects? Or connects DURING the prune? Would this affect only his backup, or could it corrupt the repo?
The backup will be interrupted, but the data that was already uploaded to the repository will not have to be uploaded again on the next run.
Depending on what type of backend you use and how you set up your restic instance, the backup session on the client might continue or retry once the client wakes up again, or it might fail when it detects that it no longer has an active connection to the repo.
Stale locks aren’t uncommon. Please see the documentation for locks for some background on how locks work in restic.
If the client just ran a backup, it will have created a non-exclusive lock, which will not prevent it or other clients to back up to the repository. Whether or not the client continues the backup when it wakes up depends on the type of backend, as I mentioned above.
If you run a prune, restic will create an exclusive lock, which means that other clients may not write to the repository anymore. I’m not sure what happens if a client went to sleep and then wakes up and meanwhile there has been an exclusive lock created, but I would think that it detects this when attempting critical operations. Someone else will have to chime in though. Personally, I make sure that when I run prune, the client won’t be accessing the repo.
I wouldn’t be too worried, but instead of saying too much and potentially wrong things I hope someone else can chime in.
“Corrupt the repo” is a bit non-specific, so instead I will explain what is likely to happen instead.
Any packs that the backup client uploaded will have been removed by the prune, assuming that no other backups between the interrupted backup and the prune operation would have used those same blobs. The interrupted backup, assuming that restic actually continues with the backup instead of bailing, will be missing blobs and so the repository will fail restic check. In this scenario, forgetting the broken snapshot will fix the problem.
It is also likely that the client will add at least one index file that refers to blobs that were deleted by the prune operation. This could cause all sorts of problems, including clients deduplicating against blobs that don’t actually exist. I believe both restic check and restic prune will complain bitterly about this situation, and restic prune may fail entirely. restic rebuild-index would correct the problem.
Thanks, that makes sense. Duly noted!