Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Restic 0.13.0

restic.net

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Restic 0.13.0

#61

Post by aborsy »

ThomasWaldmann wrote: post #58
aborsy wrote: post #49

Earlier quoted context omitted.

Restic in my experience has been rock solid. I actually switched from Borg. Borg’s crypto has known limitations; its Python error messages are long and messy; it complained more frequently. Restic’s repository format is simple and well documented, which is important for long term data recovery (and fixes in case changes occur in the repo). The crypto is from a good source, and well regarded. Multithreaded, fast, nice…

About "Borg’s crypto has known limitations": We've just merged new crypto code into master, based on AEAD ciphers (AES-OCB and chacha20-poly1305) and session keys - so the potential nonce management issues are soon a thing of the past. There's current work adding argon2id as default for the KDF (was: pbkdf2), likely soon to be merged. Also checking blake3 for the ID hash (MAC) right now (but platform / build compatib…

Very welcoming improvements, especially the introduction of the standard AEADs from a standard source.

I look forward to these crypto features!

Will error correction coding be on roadmap at some point?

Re: Restic 0.13.0

#62

Post by eliaspro »

timmg wrote: post #21

I have a hand-coded backup system for my photo library that writes to S3. It runs every night at 2AM. The one feature I have that's important to me is this: it will figure out what files need to be uploaded and then upload as many as possible for an hour then stop. That means that it runs for at-most an hour a night. The reason I need/wanted this feature is that I might come home from a trip with (eg) 30G worth of ph…

On Linux, this can be easily achieved by using RuntimeMaxSec= [1] in the corresponding service unit.

[1] https://www.freedesktop.org/software/systemd/man/systemd.ser...

Re: Restic 0.13.0

#63

Post by cma »

sliken wrote: post #60
sigio wrote: post #26

Earlier quoted context omitted.

Don't notice this much.... disk is usually the bottleneck, and otherwise it will be the network to the remote backup location. Still backups complete in seconds: Repository: ssh://backup/./backups/mungedhostname.borg Archive name: 20220327-2201 Archive fingerprint: 8b710144579c8d531e7c4a0192304323081b14a71445557608d859494bbe84b6 Time (start): Sun, 2022-03-27 22:01:35 Time (end): Sun, 2022-03-27 22:01:52 Duration: 17.…

Sure, for spinning disks, but deduplication, compression, and encryption can easily be the bottleneck if you have some NVMEs.

And you can turn the compression way up to where it is very expensive but gives much better space savings.

Re: Restic 0.13.0

#64

Post by beermonster »

ThomasWaldmann wrote: post #58
aborsy wrote: post #49

Earlier quoted context omitted.

Restic in my experience has been rock solid. I actually switched from Borg. Borg’s crypto has known limitations; its Python error messages are long and messy; it complained more frequently. Restic’s repository format is simple and well documented, which is important for long term data recovery (and fixes in case changes occur in the repo). The crypto is from a good source, and well regarded. Multithreaded, fast, nice…

About "Borg’s crypto has known limitations": We've just merged new crypto code into master, based on AEAD ciphers (AES-OCB and chacha20-poly1305) and session keys - so the potential nonce management issues are soon a thing of the past. There's current work adding argon2id as default for the KDF (was: pbkdf2), likely soon to be merged. Also checking blake3 for the ID hash (MAC) right now (but platform / build compatib…

Is there anything that must be done to take advantage of these new AEAD ciphers on an existing repo/archive ? Or is it all under the hood and transparent to the end user?

Re: Restic 0.13.0

#65

Post by ThomasWaldmann »

beermonster wrote: post #64
ThomasWaldmann wrote: post #58

Earlier quoted context omitted.

About "Borg’s crypto has known limitations": We've just merged new crypto code into master, based on AEAD ciphers (AES-OCB and chacha20-poly1305) and session keys - so the potential nonce management issues are soon a thing of the past. There's current work adding argon2id as default for the KDF (was: pbkdf2), likely soon to be merged. Also checking blake3 for the ID hash (MAC) right now (but platform / build compatib…

Is there anything that must be done to take advantage of these new AEAD ciphers on an existing repo/archive ? Or is it all under the hood and transparent to the end user?

It is still early in the development process, but it might be just for new repos.

Re: Restic 0.13.0

#66

Post by ThomasWaldmann »

aborsy wrote: post #61
ThomasWaldmann wrote: post #58

Earlier quoted context omitted.

About "Borg’s crypto has known limitations": We've just merged new crypto code into master, based on AEAD ciphers (AES-OCB and chacha20-poly1305) and session keys - so the potential nonce management issues are soon a thing of the past. There's current work adding argon2id as default for the KDF (was: pbkdf2), likely soon to be merged. Also checking blake3 for the ID hash (MAC) right now (but platform / build compatib…

Very welcoming improvements, especially the introduction of the standard AEADs from a standard source. I look forward to these crypto features! Will error correction coding be on roadmap at some point?

There's this ticket: https://github.com/borgbackup/borg/issues/225

I don't see anything of that in the near future of borg, esp. as long as the fundamental concerns there have not been addressed.

Re: Restic 0.13.0

#67

Post by ThomasWaldmann »

cma wrote: post #12
mekster wrote: post #3

Unless it's for experimenting, I've stopped caring for backup solutions other than borg and zfs as the only way to prove their stability is to have them exist for a while without big complaints and new ones all seem to have complaints. Just having no data loss isn't enough which is the absolute base point but huge memory consumption and other operational issues are also showstoppers.

Borg being single-threaded is painful in the era of consumer 12 and 16 core CPUs, and even prosumer 64-core.

I agree that a multithreaded borg could utilise resources better, esp. IF you have a lot of changed / new data to back up.

But OTOH, for many users this is primarily the case for the first backup, but not for their daily / hourly backups when most files are unchanged - for that, I guess speed is I/O bound and all your CPU cores won't help you with that.

So for N-1 backup runs, it just works good enough already for many users. And for that 1 initial backup, some patience helps. :-)

Implementing MT is planned since long, but due to the above, other stuff had higher priority.

Re: Restic 0.13.0

#68

Post by bccdee »

Mo3 wrote: post #16
bccdee wrote: post #15

Earlier quoted context omitted.

Yes! I back up directly into Backblaze B2 using restic.

Excellent. One more question. Assuming someone gains access to a node - will they be able to access the backups or screw with them in any way?

There's an object lock feature which prevents objects in a certain bucket from being deleted before X amount of time has elapsed. This might be able to prevent backups from being tampered with.

If that doesn't work, there's a restic server which can act as an intermediary and which has an append-only mode which would prevent backups from being tampered with if your computer were compromised.

Post reply on HN