Restic doesn't support compression and probably won't. https://github.com/restic/restic/issues/21

Borg has a "lackluster" encryption scheme. https://borgbackup.readthedocs.io/en/stable/internals/securi...

Restic can't pull backups. https://github.com/restic/restic/issues/299

Borg can't either, but it has "borg import-tar", which might be good enough.

> 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-456...

Could you explain why you find their encryption scheme 'lackluster'? I'm not seeing that conclusion in the linked document.

Borg 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).

Yeah, 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).

Restic 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/

A 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.

Borg doesn’t require server side support. You can mount locally using, say, SSHFS.

However having server side support reduces backup times.

I 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

In 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

hmmm ... it appears that I might be the one that is not quite right ... I was positive that there was a less-featured usage mode over plain old SFTP.

Either way, having the borg executable on the server side is the "correct" way to do things.

borg does either use a directory as repo (no matter whether local or mounted via network fs) or works client/server via pipes that are usually over ssh (in that case, it needs a remote borg process to talk to). instead of ssh, one could also use anything rsh-like, but of course ssh is the best option here.

no sftp inside borg (nor anything else).

Restic 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).

I 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.

We 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.

I 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.

They’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

I 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.