5 ms·

Like the author I have also been very happy with Borg backup software ( https://www.borgbackup.org/ https://www.borgbackup.org/ ). The compression and de-dupli

by graton 6y ago

Like the author I have also been very happy with Borg backup software ( https://www.borgbackup.org/ 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.

aborsy 6y ago
I also like Borg back up. I wonder if I am missing something compared to restic?
- more-coffee 6y ago
  Borg is supposedly a bit faster, restic supports a ton of backends https://github.com/restic/restic/issues/1875 https://github.com/restic/restic/issues/1875 Also restic does not allow to backup unencrypted. 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.
  - aborsy 6y ago
    Thank you ! I posted another question on Borg, in case you know the answer!
- magicalhippo 6y ago
  I found restic did not scale well with a large amount of files when I tried it a few years ago. Has this changed? Is Borg better? I used to run Crashplan with near-continuous backup for my important files, and I'm still missing this.
  - stevesimmons 6y ago
    I too used to use Crashplan until they discontinued their personal subscription and with it the option to backup to local drives. 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.
  - fidelramos 6y ago
    I don't know what you call large, but my personal restic backup runs weekly, ~250000 files, 2 TB, finishes in 7 hours saturating a 600 Mbps connection over S3 protocol. I'm very happy with restic.
    - magicalhippo 6y ago
      Well I have about 2-3x as many files, but only ~100GB. The main concern was finding out which files to take backup of, it would take quite a long time. Like I said I was hoping to get the 10-15 minute intervals I had with Crashplan.
- rsync 6y ago
  "I wonder if I am missing something compared to restic?" 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).
aborsy 6y ago
I have a question about Borg’s encryption. It’s stated [0] that if multiple clients update same repository, the server might be able to decrypt data. 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/security.html#attack-model https://borgbackup.readthedocs.io/en/stable/internals/securi...
- TimWolla 6y ago
  > Why is that the case [...]? This is explained in the "Encryption" section: https://borgbackup.readthedocs.io/en/stable/internals/security.html#encryption 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/).
  - aborsy 6y ago
    Yes, thanks! 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!
linsomniac 6y ago
Of course, as with all backups, you should make sure to run a test recovery. I ran into a situation with Borg where the encoding of one of my filenames caused that file and anything else behind it in the backup to be unrecoverable. Or at least I was never able to find a way to recover it. 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.
m3nu 6y ago
Since we are talking about Borg, I should plug my https://BorgBase.com https://BorgBase.com service, which is offsite backup hosting, specialized for Borg only and offers additional feature, like append-only mode, quick setup of isolated repos and monitoring for stale backups.

by graton 6y ago

aborsy 6y ago

I also like Borg back up. I wonder if I am missing something compared to restic?

more-coffee 6y ago
Borg is supposedly a bit faster, restic supports a ton of backends https://github.com/restic/restic/issues/1875 https://github.com/restic/restic/issues/1875 Also restic does not allow to backup unencrypted. 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.
- aborsy 6y ago
  Thank you ! I posted another question on Borg, in case you know the answer!
magicalhippo 6y ago
I found restic did not scale well with a large amount of files when I tried it a few years ago. Has this changed? Is Borg better? I used to run Crashplan with near-continuous backup for my important files, and I'm still missing this.
- stevesimmons 6y ago
  I too used to use Crashplan until they discontinued their personal subscription and with it the option to backup to local drives. 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.
- fidelramos 6y ago
  I don't know what you call large, but my personal restic backup runs weekly, ~250000 files, 2 TB, finishes in 7 hours saturating a 600 Mbps connection over S3 protocol. I'm very happy with restic.
  - magicalhippo 6y ago
    Well I have about 2-3x as many files, but only ~100GB. The main concern was finding out which files to take backup of, it would take quite a long time. Like I said I was hoping to get the 10-15 minute intervals I had with Crashplan.
rsync 6y ago
"I wonder if I am missing something compared to restic?" 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).

aborsy 6y ago

I have a question about Borg’s encryption. It’s stated [0] that if multiple clients update same repository, the server might be able to decrypt data. 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/security.html#attack-model https://borgbackup.readthedocs.io/en/stable/internals/securi...

TimWolla 6y ago
> Why is that the case [...]? This is explained in the "Encryption" section: https://borgbackup.readthedocs.io/en/stable/internals/security.html#encryption 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/).
- aborsy 6y ago
  Yes, thanks! 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!

linsomniac 6y ago

Of course, as with all backups, you should make sure to run a test recovery. I ran into a situation with Borg where the encoding of one of my filenames caused that file and anything else behind it in the backup to be unrecoverable. Or at least I was never able to find a way to recover it. 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.

m3nu 6y ago

Since we are talking about Borg, I should plug my https://BorgBase.com https://BorgBase.com service, which is offsite backup hosting, specialized for Borg only and offers additional feature, like append-only mode, quick setup of isolated repos and monitoring for stale backups.