5 ms·
What about Borg vs Restic? Which is better?
by jlelse 5y ago
What about Borg vs Restic? Which is better?
- formerly_proven 5y agoRestic doesn't support compression and probably won't. https://github.com/restic/restic/issues/21 https://github.com/restic/restic/issues/21 Borg has a "lackluster" encryption scheme. https://borgbackup.readthedocs.io/en/stable/internals/security.html https://borgbackup.readthedocs.io/en/stable/internals/securi... Restic can't pull backups. https://github.com/restic/restic/issues/299 https://github.com/restic/restic/issues/299 Borg can't either, but it has "borg import-tar", which might be good enough.
- Freak_NL 5y agoCould you explain why you find their encryption scheme 'lackluster'? I'm not seeing that conclusion in the linked document.
- formerly_proven 5y agoBorg uses static AES keys and requires a way to store nonces because of this. In a multi-client scenario there is no way to do that without trusting the server to some extent, so the encryption is vulnerable to nonce reuse. > When the above attack model is extended to include multiple clients independently updating the same repository, then Borg fails to provide confidentiality (i.e. guarantees 3) and 4) do not apply any more).
- ThomasWaldmann 5y agoYeah, that's an issue which can be avoided by using 1 repo per client. There are some ideas on the issue tracker for fixing this long term (like random nonces, session keys, ...), but that stuff will have to wait until after borg 1.2 (which soon goes into release candidate phase).
- dmos62 5y ago> Restic can't pull backups There's ways to pull backups. You'd use ssh forwarding and/or the REST backend for append-only backups. See this comment: https://github.com/restic/restic/issues/299#issuecomment-456310904 https://github.com/restic/restic/issues/299#issuecomment-456...
- aborsy 5y agoA major difference is that, Borg needs a server side code running as well, unlike restic. Restic can take up a lot of RAM, unlike Borg. Borg offers the option of no encryption. This is useful when backing up to a local drive that is already encrypted, for example with LUKS. But, they are generally similar.
- beermonster 5y agoBorg doesn’t require server side support. You can mount locally using, say, SSHFS. However having server side support reduces backup times.
- rsync 5y agoI think you are both not quite right ... Which is to say, you don't need the borg executable server-side if you are happy to run it over SFTP transport which limits some functionality. Yes, of course you could talk over an sshfs mount point but I can't think of why you would do that over the more basic SFTP transport. The accepted, and full-featured, way to run borg is with the executable on the server side and I will point out that the borg project distributes a "frozen" version of the tool that allows you to run it without having python in your environment. I believe they use py2exe to pack it up. This is important for us[1] as we have no interpreters of any kind in our environment (no shell, no python, no perl) so we can only run binary executables ... [1] rsync.net
- beermonster 5y agoIn the FAQ [1] SSHFS is mentioned a few times and here is the citation where I got this idea from when I read it way back when: “When Borg is writing to a repo on a locally mounted remote file system, e.g. SSHFS, the Borg client only can do file system operations and has no agent running on the remote side, so every operation needs to go over the network, which is slower.” SSHFS would be tool agnostic/transparent though of course would result in operations going over the network as it’s not a local repo, but pseudo-local. I’m curious, how do you use plain SFTP transport with borg using rsync.net? [1] https://borgbackup.readthedocs.io/en/stable/faq.html https://borgbackup.readthedocs.io/en/stable/faq.html
- beermonster 5y agoRestic runs natively on Windows too which is useful in heterogenous environments Filippo Valsorda thinks[1] the encryption implementation looks sane. [1] https://blog.filippo.io/restic-cryptography/ https://blog.filippo.io/restic-cryptography/
- hashhar 5y agoRestic doesn't implement compression and most probably never will (since compression when combined with encryption has been known to make the encryption "weaker"). Borg's "encryption" doesn't instill confidence in me. Restic ships as a static binary so you can shove the version you used to create the backup and will be able to restore it forever (assuming we still run x64 machines). Borg requires a server side component so cannot natively backup to cloud object stores. Restic can. Borg OTOH is very lean and doesn't take a lot of RAM compared to Restic. You cannot go wrong with either. I tried both and found Restic much easier to run and manage and the memory usage wasn't an issue for me (~4TB backups).
- formerly_proven 5y agoI don't think the reason Restic won't support compression is because of some security concerns (Restic encrypts blobs separately, and you'd compress things blob-wise as well), but because there simply wasn't any space designed into their file formats to signal compression, so it's essentially impossible to implement it without breaking compatibility. Borg's story is actually similar but the opposite. Attic only used to support zlib, other methods were added later. This was possible because the zlib header uses only a few values for the first two bytes, so there is enough room to indicate various compression formats.
- jlelse 5y agoI use restic as well, was just interested to see what's different about Borg. But I think restic was the right choice, already saved me once from data loss.
- beermonster 5y agoThey’re both a fine choice really. And being open source there’s no harm (other than time) in trying both and seeing which suits your use case best
- thde 5y agoWe found that restic (at least in its newest version) uses ~ the same amount of RAM or even less that Borg on some systems. But no big differences there.
- ale42 5y agoI wont comment in terms of features, but in my experience Borg is slower than Restic. This might be worth considering for low-end servers, and for big amount of data. Restic used to have an extremely slow prune (purge unused old data) feature, but this has improved dramatically in one of the latest releases.