Hacker News new | ask | show | jobs
by mendym 623 days ago
is there a reason to use the borg encryption[1] over rclone crypt[2] or vise versa?

1. https://borgbackup.readthedocs.io/en/2.0.0b11/quickstart.htm... 2. https://rclone.org/crypt/

3 comments

Rclone crypt is not much related to Borg. That’s a tool for copying files from one machine to another, in this case encrypting before copying. That’s rsync, working with cloud.

Borg is a different tool, for backup. It deduplicates, encrypts, snapshots, checksums, compresses, … source directories into a single repository. It doesn’t work with files, rather blocks of data. It includes commands for repository management, like searching data, pruning or merging snapshots, etc. You will then transfer or sync the repository to wherever you want, with a tool such as rsync/SSH or rclone. Rclone is now natively supported, so that you don’t need to store the repository locally and on remote, rather back up directly to remote.

I would also wonder what the difference between this package and Restic is. as far as efficiency and encryption.
How good at deduping is this when encryption is enabled? I was looking at rsync.net and it killed me that they don't support encryption in a sane way.
It's very sane: encrypt the bits, then send it to the host.

Curious what you think is not right with their methods.

Sure, but there is some requirement to not just blindly copy everything over-and-over, and that is where I've seen things get tricky before. If you enable encryption you have to re-upload the entire snapshot periodically.

It's annoying because if you have TBs of stuff that blows. I'm just curious what systems exist for incremental, encrypted backups that don't require full uploading new snapshots.

See here in the NOTE section. Re-reading this, it might a limitation of Duplicity. https://www.rsync.net/resources/howto/duplicity.html

Author of HashBackup here.

Duplicity is very old backup software that uses the "full + incremental" strategy on a file-by-file basis, like tape backup systems. The full backup must be restored first and then all of the incrementals. This becomes impractical over time, so as with tapes, you must periodically repeat the full backup so the incremental chains do not become too long.

Modern backup programs split files into blocks and keep track of data at the block level. You still do an initial full backup followed by incrementals, but block tracking allows you to restore any version of any file without restoring the full first and all following incrementals. The trade-off is in complexity: tracking blocks is more complex than tracking files.

It has nothing to do with encryption.

> they don't support encryption in a sane way.

Should the storage provider provide support for encryption on their end? Would you not want to store the keys locally?

The provider should not. It provides a false sense of security.