3 ms·
> Why is that the case [...]? This is explained in the "Encryption" section: https://borgbackup.readthedocs.io/en/stable/internals/security.html#encryption htt
by 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 agoYes, 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!
- TimWolla 6y agoI never used rclone, but I can tell you that a borg repository basically is a number of encrypted blobs of up to 500 MB size that are never going to be modified again (only created and deleted) + a few small metadata files. It rsyncs quite well.
- troyjfarrell 6y agoI can confirm that cloning a local Borg repository to a cloud system works. One of my systems uses Borg to make a local backup. Next, B2's command line tool synchronizes the local Borg repository to B2.