encryption is very good feature and becomes more and more important. if you backup to any external cloud server encryption is a must!
if you only do backup to internal servers encryption could be omitted - when maybe you are the only one who have access to the files that are backuped and the backup server.
so to run a backup without giving password could be in some cases useful. at the moment i set the passwort in my ENV-file, that i source with my backup script. as i am the one who as access that’s ok.
Problem with simple passowrds like “password” or “123456” is, that in case of a restore you will have to remember even those simple passwords. you can assure, that you will remember a few years later those simple passwords. that’s a problem if you have to do a full restore on a clean and (empty) machine…
you somewhere have to write down or remember the password.
Encryption is a common feature of modern filesystems. There is absolutely no reason to add an additional encryption layer when backing up from an encrypted notebook to an encrypted home-server via an encrypted SSH connection.
It obscures the setup with no added benefit.
We are living in a world of layered protocols. Restic is a single layer making the assumption that encryption is always desired. But that depends on which other layers are used underneath, therefore that assumption is not a good one.
Restic could just use an empty password internally when decryption is turned off. No need to change its implementation.
@DavHau The encryption in your filesystem and the encryption in restic serves different purposes. Your filesystem encryption cannot prevent someone with access to the filesystem from reading the contents of your repository, this is part of why restic uses encryption. You can read more about this in the thread model document: References — restic 0.15.1 documentation
In other words, your comparison of filesystem encryption and restic’s encryption isn’t really applicable.
Your server is trusted. With restic, and you can back up the repo to an untrusted server also.
Even with a trusted server, file system encryption is a different story. When you are using your computer, the password to that is in the RAM. It’s basically unencrypted.
Backup encryption creates a portable format. You can backup that repository anywhere.
Daniel, just like you, I’ve created this account just to say, “mandatory” is not applicable for a software said to be “free”. There is no free will here. We have many types of backups, each are for a different reason. I’ve met restic while I was looking for an incremental backup solution for “human error backups”. I don’t need encryption, that’s all. You guys are doing a very good job developing restic, thanks, but this “mandatory” thing is deal breaker. Lastly, betatester77 thank you mate, I’ll check rsnapshot.
There was recently a discussion on Hacker News about that topic as well. The general sentiment was that this is a deal breaker and a solution forced on used though misguided “security”
The design goals for restic include being able to securely store backups in a location that is not completely trusted (e.g., a shared system where others can potentially access the files) or even modify or delete them in the case of the system administrator.
Includes means that this is one of the possibilites. If the threat model stated that Restic is for backups on hostile environments only then OK - a niche backup system (and a good one).
