There are several threads on GitHub regarding encryption or empty passwords. They are all locked without a definite answer.
My question: is there today a plan to implement either a backup without encryption or with an empty password?
I find that restic is great, but I need to have an unencrypted or empty-password backup. For reasons.
What I am trying to say is not whether encryption is good or bad, just if I can not have it or have an empty password (now, or someday).
Always requiring a password and encryption for the repository is sort of a feature. So itâs not too likely that this will change. For short to mid term the answer is definitely no.
I agree.
Encryption will be increasingly important in backups due to privacy. Requiring it is a good feature.
I personally ended up with restic, because people suggested that itâs great in encryption and developers have appreciation for software security.
For encryption-less backup, you may want to look at rsync.
If you donât care to encrypt things, you actually have a lot of options for backup. Down to really simple copy solutions to something sophisticated like rsync.
I am curious, what is the downside of encrypting for your workflow? Do you feel like you may lose the password?
Rsync just moved files . More flexible version of move. Itâs not a backup software, with compression, deduplication, encryption, backends, with repository operations.
Thank you, this is clear.
Requiring (as opposed as having it as a default, but allowing to disable it) it means that the people who do not need/want it will not use the software, thatâs all. You may be of the opinion that this is dumb but it is their informed choice and will not affect anybody else than them.
With this approach, http://neverssl.com should be banned and people actively pushed away from it because it poses security risks. Maybe Chrome should also block it for good measure.
FWTW I work in information security and wrote some security software you may even have used if you are in the field. And yet, I need these unencrypted backups.
This is just to say that @MichaelEischer answer was really to the point: it is a design decision that will not change, I respect it and wonât unfortunately use restic then.
I can recommend rsnapshot.it builds snapshots with rsync while hardlinking unchanged files. So ot has also some kind of deduplication.
Password 123456. Problem solved. For additional insurance, put the password in the repository. Itâs just a file with almost zero overhead work.
I believe a significant reason behind the current ethos is that encryption is baked into restic at every turn; itâs not one of those programs that has data safety added in as a useful extra: itâs a cornerstone of restic. To add a feature that allows for unencrypted repos means that code has to be added to bypass encryption, which makes everyoneâs data less safe.
There is no rational reason to compromise the security of peopleâs backups to add support for insecure workflows; if your use case canât cope with including a password or password file then itâs a fundamentally broken process and it is this that needs fixing.
@Wpq I know you donât want to hear reasons for or against, but Iâm curious; what is your use case for not having a password in the repository?
It is purely experience based, there is no quantifiable reason.
I work in IT and information security for 30 years. I saw a lot of cases where the software that was doing X could not deliver (because data corrupted, bug, whatever). In a few cases, we managed, miraculously, to recover by using the data format to extract at least some data. We wrote a few articles about that in the past so that others can learn on our misery (it was either a failed encryption header, of logical drive went wrong).
I do not want to close this possibility for a backup. I know that there can be endless explanations how encryption will not hinder this, or that recovery outside of restic is not possible anyway but if I do not need the encryption (because I donât), why taking the extra risk.
I like restic and I will probably end up having âpasswordâ as the password, and a file in the repository that says README - the password is here.txt. And hope for the best to recover files.
By âhope for the bestâ I mean âautomate recovery testingâ 
I am glad to know that you have addressed all possible situations/processes in the world and can authoritatively claim that. Good for you.
Yes, this is my current plan too.
Okay, so if I may try to summarize, the reason you want to have no encryption and preferably no password is to remove complexity and reduce the risk that the software has bugs that might render the backups unrestorable.
I think its worth to know that in the processes that delete or rewrite something, there is always the implicit assumption that even if the same content is written, it will result in a different repository file. For instance there is no guarantee that a pack rewrite wonât pack exactly the same blobs in a new pack. Then this new pack is written and afterwards the old pack is deleted - without a check if the names are identical.
The encryption (using a random nonce) ensures here that that check is not needed as a different nonce will result in a different pack file.
Moreover keep in mind that the encryption not only encrypts but also MACs the data, so you also get an (additional) data corruption check by this.
About your motivation to disable encryption to be able to retrieve information even if arbitrary things break: I understand how you are thinking. Note that even if you know the password, you (and restic) also needs to derive the master key which is actually used for the encryption. This key is derived by any key file and the corresponding password for that key file. That is, if you loose or corrupt your key file, it doesnât help you to know the password. So, some people suggest to generate multiple keys - this is even possible using the identical password. Alternatively you might think of doing extra backups of your key file.
Yes, and I forgot that one can forget the password
You might want to create backup copies of the config file and the keys folder. The config file is somewhat recoverable, but a damaged key is not.
Thatâs a joke, right? 
Itâs an additional joke!