Like the author I have also been very happy with Borg backup software ( https://www.borgbackup.org/ ).
The compression and de-duplication is very useful. A little bit of a learning curve to get everything up and running, but not too bad.
The compression and de-duplication is very useful. A little bit of a learning curve to get everything up and running, but not too bad.
Why is that the case and wouldn’t that make the encryption very weak? Simultaneous updates happen quite often.
Would restic have the same problem?
——————-
Update: The issue happens because Borg uses AES in the CTR mode (not AES GCM) and two clients could provide the same nonce. The server could then recover the plaintext from two cipher texts. This is the famous nonce reuse problem.
So Borg developers are not using established primitives for this use case. Also, I am not comfortable with the OpenSSL even though it’s got better since 2015. The libssl code base is a mess and buggy. On the other hand using the low level libcrypto library would expose developers to the crypto primitives with possibilities for errors for people not expert in cryptography.
Borg should consider ChaCha-Poly135 as in rclone (or at least AES-GCM).
[0]https://borgbackup.readthedocs.io/en/stable/internals/securi...
This is explained in the "Encryption" section: https://borgbackup.readthedocs.io/en/stable/internals/securi...
The important part is the part about avoiding re-use of the AES CTR value.
> Simultaneous updates happen quite often.
Personally I created a dedicated borg repository per machine I want to backup, because that avoids sharing passphrases across machines. This comes with the drawback that I cannot deduplicate across machines, but that is acceptable to me, because the data is mostly unique-ish anyway. I only backup the user data, not everything (e.g. /bin/).
I meanwhile read about it and updated my comment.
Would it be practical to rclone the output of the Borg into a cloud service using an rclone crypt remote? In my experience, rclone’s crypt remote is sluggish, even locally. I am not sure how the mount would work.
It’s unfortunate that we have to get the dedup from Borg and the encryption from rclone!
I gave it the old college try to recover, using the different tools to try to access it (the fuse mount, the CLI), I tried all sorts of different settings for my locale. At the time I had at least 2 other backups of that so eventually I recovered from my primary backup. I was testing out Borg at the time.
I've ended up using Restic more recently, and it seems to be fine. Uses kind of a lot of memory in some situations though. Small AWS instances have issues. My primary backups still go via rsync though.
I wonder if I am missing something compared to restic?
I haven't used borg. Only done some maintenance on restic backup jobs at work. Restic's command design is intuitive and the documentation is good. But Borg looks just fine in that regard as well.
I posted another question on Borg, in case you know the answer!
I used to run Crashplan with near-continuous backup for my important files, and I'm still missing this.
Around the same time I tried Restic. That ran into difficulties (don't recall what anymore) so I switched to Borg.
Borg has been 100% reliable, including a full restore of /home after my laptop was stolen.
Like I said I was hoping to get the 10-15 minute intervals I had with Crashplan.
The biggest difference for us is that borg really requires a server side 'borg' binary to talk to, which we have built into rsync.net. restic, on the other hand, can just connect to any old SFTP endpoint.
This means we need to preserve some amount of backwards-compat and so we maintain borg0.x and borg1.x binaries in our environment (and eventually, borg2.x).