Restic best practice for permissions (SFTP, local root)

Hello everybody,

I recently discovered restic and was so excited that I am switching all my scattered backup solutions with one centralized repo.

And here is my “problem”: I established a connection (SSH/SFTP) from my Raspberry Pi to my main server (Ubuntu). First backup works fine, I can execute restic-commands against the remote repo.

Afterwards I did a backup on the main system itself with sudo rights. Of course these files where saved with root ownership.

But now I can’t inspect the repo remotely for example with restic snapshots. I get a “Permission denied” with SSH_FX_PERMISSION_DENIED error. The problem is clear. But what is best practice in this constellation? Execute a recursive chown over repo after running the (sudo) backup on main server?

Thank you for your thoughts.


This is somewhat related to this thread:

The tl;dr is that currently, restic forces 700 permissions on files. One way to solve this problem would be to run the rest server and have all backups (even that happen on the same machine) use the rest server as the backend. This way, the ownership of the repository files will be consistent: whatever user the rest server is run as.

Okay. These are two options but not realy a best practice. I also found this in the documents to grant universal read permissions for a restic user. I will give the different solutions a try. Thank you for support.

I wouldn’t go so far as to say that using the rest server is not a best practice. It can help with privilege separation, as well as enforcing append-only operations (so that remote clients cannot delete any information).

I just started with the read-only option from the official docs yesterday and will give it a try for some time now. As far as I understand the rest-server is something like 3rd party or at least in beta status? And what about perfomance of http vs. SFTP?

The rest server is maintained by the same team who maintains restic. We have been using it in production for months without issues.

I haven’t found any significant performance difference between the two. Note that we have our rest server behind another HTTP daemon that performs TLS termination, so in our setup both mechanisms are encrypted. When doing unencrypted HTTP, I would expect it to perform either slightly better or the same (the backup process is almost certainly going to be I/O-bound, not CPU-bound, making encryption overhead likely negligible).