Rest-server --append-only : how to delete snapshots?

Getting Help
1

I have set up a rest-server (on host zoo) and started it with:

rest-server --path /nfs/restic --append-only --private-repos --tls

Creating restic snapshots was successful by a client host and he is not able to delete them, BUT I also cannot delete/forget/prune the snapshots via the server:

root@zoo:~# restic -r /nfs/restic/test forget -n --prune --keep-daily 7
enter password for repository:

For THIS test repository I know the password, because I have created it, but later in production mode I (the rest-server admin) do not know the passwords of the repositories! They are secret by the clients, because they belong to other departments/institutes. They will not share their passwords.

Have I missed something or is the append-only mode only useful if clients and server have the same admin (run by the same institution)?

2

You have not misunderstanding anything. This is how it works. You cannot BOTH eat the cake AND have it too.

1 Like
3

With IBM SP (ex TSM) such a configuration is possible.
But SP’s usage is awkward.

4

What configuration? That the client can only add backups, but at the same time can also delete backups? :slight_smile:

5

That the client can only add backups, but the SERVER can delete backups without knowing the secret encryption password of the client. The server must not read (decrypt) the files.

6

For that to work you either need a backup repository where deduplication is not used on a chunk level, or that the server can somehow determine which parts of the actual data stored matches which snapshots. I suspect SP does not work the same way as restic and is not designed with the same goals in mind. Restic is designed to be completely independent of the server and not trust the server at all.

7

Maybe you could workaround this problem by implementing a small REST service to handle your scenario without official support in the server or restic?

Just first thoughts on a high level:

  • expose a new https API endpoint in a language of your choice over TLS to ensure secrets are not readable over the network
  • the new API would be hosted on the same server as restic rest server to have access via restic to the local repo
  • the API would get only a HTTP request with the secret and the target repo
  • the retention policy is stored on the server, probably just a config file. The important part is that the client has no control over the retention policy and therefore can’t bypass the append-only mode to delete all backups.

After an successful backup or on a cron schedule, the client could invoke the API over the network, e.g. by using curl and send the password. The password should not be persistent by the API, it should just be passed to the restic CLI invocation to clean up the repo.

If I am not mistaken, this could be a potential solution to your request, but it would require additional coding on your end.
Not sure if the rest server project is willing to add support for something like that, but it would at least not store the secret of the target repo on disk, it would be only available inmemory for the time until the restic call gets submitted. Still, if your server is compromised, you could sniff the secret. But you would be already able to delete files on local disk as well. The difference in the risk profile is, that receiving the secret, even temporary, could still grant an attacker the option to view your files, if the secret gets leaked.