Which operations create a lock and when should I worry?

The documentation for locks states (emphasis mine)

The restic repository structure is designed in a way that allows parallel access of multiple instance of restic and even parallel writes. However, there are some functions that work more efficient or even require exclusive access of the repository. In order to implement these functions, restic processes are required to create a lock on the repository before doing anything.

It also mentions that there are exclusive and non-exclusive locks

At most one process can have an exclusive lock on the repository, and during that time there must not be any other locks (exclusive and non-exclusive).

I have a few questuins in the context of parallel backups, checks and purges for one repository. My main concern are operations happening from different sources that could overlap and step on each other

  • which are the restic operations that create an exclusive lock? (← these are the ones I need to make sure do not happen at the same time, right?)
  • which are the ones that create an non-exclusive one?
  • are the non-exclusive locks something I should worry about when building my backup strategy?

I am setting up something similar right now and I am also very interested in this. At the moment, I use the –retry-lock parameter with a suitably big value to force the backups into a sequence, but maybe there is a better way.

You may find this list helpful:

  • Operations that need a shared/non-exclusive lock can run at the same time as other operations that need a shared lock.
  • Operations that need an exclusive lock cannot run at the same time as any other operations.

Also this can be interesting, especially the non-blocking prune section.