Do I need to be careful about locking with rest-server?

[grifferz]

Hi,

I’m evaluating using restic on about 40 hosts with the repo on a host with rest-server, so all clients talk to the rest-server only when they do restic backup. Any repository management that I do, I will do on the repo host using local filesystem (not the rest-server).

I will space the client backups out randomly throughout 12 or so hours each day, but do I need to be worrying about locking? i.e. if I want to do some maintenance like forget --prune or a check, do I need to make sure that I have exclusive use of the repo? I see that restic when operating on the local filesystem takes an exclusive lock when it needs to so I think that means it takes care of having exclusive access itself, right?

Should clients run unlock before their backup run or is that not necessary when the clients are talking to rest-server?

I see that the documentation for unlock says that it only removes stale locks, so in my ideal world that exits with a failure if the repo is locked for maintenance by an active process on the repo host, or else is cleared to proceed. Is that how things should go?

I have seen many example systemd service files for restic backups that do:

ExecStartPre=restic unlock
ExecStart=restic backup …

which would fail the unit if the ExecStartPre were to fail, so that seems to be what I want, as long as that is compatible with the usage of rest-server.

Thanks,
Andy

[MichaelEischer]

@grifferz

I will space the client backups out randomly throughout 12 or so hours each day, but do I need to be worrying about locking?

Do all clients use the same repository or separate ones? Be aware that ALL clients have full access to everything into the repository to which they backup to.

@grifferz

Should clients run unlock before their backup run or is that not necessary when the clients are talking to rest-server?

rest-server doesn’t perform any magic in regard to locks. Different backups don’t conflict with each other. backup and prune/check do though.

@grifferz

I see that the documentation for unlock says that it only removes stale locks, so in my ideal world that exits with a failure if the repo is locked for maintenance by an active process on the repo host, or else is cleared to proceed.

unlock does not return an error if locks remain, but it won’t delete active locks either.