tl;dr: Is it a good feature request to have a password that can only forget/delete but not read contents?
Assume the following situation:
- Laptop (relatively secure, no remote access, to be backed up automatically)
- Server (self-administrated, with rest-server as restic backend, other services running, more attacks possible)
Reading the restic thread model, restic assumes the laptop to be secure. Many attacks are prevented by restic’s design and I even trust my backend more than I would trust any cloud backend. But I still don’t want the backend server to be able to look at the backup contents, so I don’t provide it with a password. I don’t want the server to be able to read my backups. I want to have it automated. I want a manageable repo size. I want some resilience against ransom ware. So malware on the laptop should not be able to delete my backups. The rest-server with --apend-only helps with that last point. But as far as I can see, the requirements are partly mutually exclusive.
Approaches: I could
- Use append-only and the remote repo size keeps growing. con: repo size
- Use append-only run a second rest-server which can forget with a password provided by the user by hand. con: forget not automated
- Use append-only and use a second password only known to the server which can do the forget. con: server can not only forget but also read my backups.
- not use append-only and fully automate backup and forget from the laptop, the server cannot read it. con: ransom ware could delete my backups
All the above solutions, I could come up with, have at least one disadvantage (con).
Is there already a solution that all of my requirements?
Would it be a valid feature request to have keys/passwords that can only forget/delete snapshots but not read them (in this case approach 3 would have no disadvantage)?
I know that this is related to forum post 1537, but its not the same question.