Restic: Unencrypted backups

I've heard this feature request a few times now, and I had in mind that there was an issue about it. Since I can't seem to find it, this feature request is tracked here. The short version is: We may at some point eventually add an option to disable encryption, but that's not on the roadmap at the moment.

The long version is:

• Encryption is not expensive any more, at least not if you have AES-NI (hardware accelerated encryption), which is quite common nowadays (at least in laptops and servers)
• restic not only cares about encryption, but also about authenticity and signing the data. We need to find a way to implement this without encryption, so we'll need to keep a key/password anyway.
• Once we have a code path that allows unencrypted backups, there's a chance that attackers find a way to trick a client into saving the data without encryption into an (originally) encrypted repository. That happened with other backup programs before, so we need to be super careful, which takes time and resources we don't have at the moment.

I may add further points when I find them.

An alternative reason to want unencrypted backups (locally) is so a central repository could be shared by multiple users - i.e. on my home server I'd like to send backup to it via HTTPS, but let them all be deduplicated into a common repository, even if they're presented as being logically separate to individual users.

there's a chance that attackers find a way to trick a client into saving the data without encryption into an (originally) encrypted repository.

Hm, i thought the idea was that a repository is either encrypted or not, so it would not be possible to save data unencrypted into a repository that is encrypted... And if an encrypted repository is somehow replaced by an unencrypted one with the same name and location, the user should notice that no password have been asked. Maybe a warning in bold red blinking text can be printed, that the repository is unencrypted :).

@wrouesnel you can do that already, distinguishing by hostname! (I was wondering the same the other day) :)

@alexeymuranov how do you determine if the password entered by the user is the encryption password for an encrypted directory, or the MAC password for verifying authenticity of an unencrypted directory? more --switches? It becomes very messy very fast.

I'd like to have this option for making local backups. For example, every day I run a backup of my ~/Music directory on my server, but I don't need that to be encrypted. The backup isn't to protect against hardware failure or loss (I have other backups for that), but simply to protect against accidents and bitrot. And the server is rather low-powered, so encryption overhead is an issue.

@alphapapa for that there's rsync.
EDIT: And file permissions / attributes. BTW, what is the difference between "hardware failure" and "bitrot"?

@cfcs, rsync does not deduplicate.

for that there's rsync.

@cfcs As we all know, a mirror is not a backup. ;) Using Obnam, I keep a series of backups, similar to restic: keep = 7d,8w,12m,3y Ever since I almost lost my GPG key (because it was mysteriously truncated to 0 bytes without my noticing, and the truncated file was backed up repeatedly), and I had to dig it out of a years-old backup on a CD-R, I recognize the importance of keeping old backup data around.

BTW, what is the difference between "hardware failure" and "bitrot"?

Bitrot typically goes undetected until you need the rotten data, and does not render the whole device unreadable. Hardware failure is, e.g. the disk completely failing, the system failing to boot, etc.

And as Alexey points out, rsync does not deduplicate, nor does it provide for pruning of old backup data, nor data integrity checks, etc. rsync is a fine tool, and I use it regularly, but not to make backups.

Encryption is not expensive any more, at least not if you have AES-NI (hardware accelerated encryption), which is quite common nowadays (at least in laptops and servers)

Unless your software is written in go. Go's crypro is software only for anything except intel - so with an arm device you are stuck with "estimated backup time - 14 days" for the same file set that gets completed in less than 30 minutes with the official openssl based backup solution on my NAS.

I would like to see this feature, too. I'm using SSH for transfer and I'm storing my backups on LUKS/cryptsetup encrypted volumes, so encryption just adds the risk of loosing the encryption key. Also encryption adds more error-proneness and adds unnecessary load to the CPU.

Nevertheless encryption is very useful, when I'm backing up to a untrusted target.

People might be motivated to safe a text file including the password along with the backup...

I also use a luks/dm-crypt encrypted backup target. Its an external USB disk that I mount to /Backup/
You can just create a password file at that location (/Backup/restic_password) and feed it to restic by using --password-file. The repository goes under /Backup/restic_repo/
Its important to make the password file immutable, or you are screwed if it gets lost by accident: chattr +i /Backup/restic_password
Also I just use "restic" as password, just in case.

Restic's encryption feature is very usefull if you backup to untrusted targets like cloud providers. But if you just use external drives that you store at home, or a NAS in your basement, than forced encryption is kinda mad. The average user will forget the password anyway.

Allowing unencrypted backups would allow ZFS or BtrFS or NTFS or whatever filesystem to compress backups.

(Encryption could be done via dmcrypt at a lower layer if desired)

Allowing unencrypted backups would allow ZFS or BtrFS or NTFS or whatever filesystem to compress backups.

Same here, no compression and mandatory encryption takes up too much space on my backup server. My use case (some images, lots of small xml/txt/csv files) would greatly profit from either no encryption (so ZFS could do its thing) or compression (~2.3 compression ratio with zstd,5).

If you are using ZFS, why not just use zfs send snapshots?

ZFS snapshots are not sufficient for backup in many cases. If you have undetected corruption in a file, or if you want to have years worth of savesets, ZFS snapshots don't help all that much. Like, say you're using FreeNAS and want to maintain a year of weekly backups. The scheduling and snapshot management built into FreeNAS isn't _really_ sufficient to pull that off correctly. It's not "enterprisey".

If you have a more elaborate scheduling system it would probably work a lot better. There's also the problem of zfs send requiring a snapshot to exist before you can ship it; you also have to manage a snapshot schedule and make sure your snapshot and send scheduled are synchronized (manually) so that you hit your RTO/RPO.

And yeah.. I'm talking enterprise features on FreeNAS. But that's the concern...

Encryption is not expensive any more, at least not if you have AES-NI

The AES-NI requirement excludes a lot of older servers (which in some cases are _especially important_ to back up!).

I'm helping someone get some better backups running on a collection of servers in rural Africa, on 10+ year old donated hardware (some of it even 32-bit still!). I fear that encryption will simply add too much overhead, so I guess for now I'll need to look elsewhere.

+1 for no encryption

this would be usefull

+1 for no encryption

this would be usefull

Please use the thumbs up feature on the original issue instead of '+1'-ing to avoid flooding watchers' inboxes. Thank you!

What's the status of this feature?

I need to backup files (shared documents like user manual translations) from internal samba server that all the users at the company have access to anyway, they're not really confidential within bounds of the company. Backup encryption in this case is pointless, I'm using jailkit for additional security for backups anyway, and I use btrfs filesystem with enabled compression. I backup stuff like VM disk dumps in other ways anyway. Encryption is not an issue in my usecase, preventing data loss is about the only priority. Using a password like 'restic' is kind of silly workaround.

Please implement this.

@mrkafk What is the actual problem for you with restic having encryption? Even if you don't need it, you'd need very specific reasons for it to be a problem, as your CPUs most likely have support for hardware encryption.

I've described my actual problem: given the specific context I don't need it, while as I understand at least it eliminates compression gains in btrfs filesystem. I have tons of files to back up, that's why I'm using btrfs with compression enabled in the first place because with RAID-1 for hw redundancy I need a lot of diskspace (were it not for that, I'd much rather use ext4). Also, encrypting with what amounts to fake password and doing encryption unnecessarily feels... silly.

Ok, out of the things you wrote I gather one actual problem, namely that BTRFS compression isn't as effective as it could be without encryption. That's a good point. Besides that I don't see anything that limits you due to restic's encryption.

It's impossible to loose the encryption key if it is not encrypted. That's especially relevant for backups.

Mebus

It's impossible to loose the encryption key if it is not encrypted. That's especially relevant for backups.

That's been discussed like the world would be ending tomorrow already :) https://github.com/restic/restic/issues/1786