What about Borg vs Restic? Which is better?
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.
> 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).
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).
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...
Filippo Valsorda thinks[1] the encryption implementation looks sane.
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.
However having server side support reduces backup times.
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
“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?
Either way, having the borg executable on the server side is the "correct" way to do things.
no sftp inside borg (nor anything else).
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).
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.