1. 14

  2. 5

    I’m mostly using borg for backups, but still use duplicity where I want the backup source to only be capable of encrypting new backups and not decrypting old ones. Is there another backup system, nicer than duplicity, that allows you to make backups using only the public part of a keypair?

    1. 1

      Duplicity can also use your public key. Instead of providing a passphrase you can use the --encrypt-key flag to provide your key’s fingerprint.

      1. 2

        Exactly, that’s why I’m still using it. But is there a nicer alternative?

        1. 2

          Not sure if it’s nicer, but tarsnap does it and hasn’t been mentioned so far

          1. 2

            While tarsnap is really cool, the pricing makes it sort of in a different category (i.e., it’s good for backing up important stuff, whereas duplicity, restic, borg, duplicacy, etc, can be affordable to backup everything).

    2. 3

      I tried Duplicity with GPG but sadly I found it lacking, even for rarely looked at archives. I eventually moved to restic and it works splendidly.

      1. 3

        I also do backups using restic against a cloud storage (in my case a Ceph cluster), this has two advantages:

        1. backups are stored redundantly
        2. restic backups against an HTTP endpoint are much faster than over SSH
        1. 2

          My biggest complaints about restic are the lack of access controls and slow pruning of data. Perhaps those may be fixed one day.

          1. 2

            What were you missing from duplicity?

            1. 5

              Not the OP, but the fact that you can’t delete intermediate incremental backups is pretty bad… Pruning is a pretty key aspect of most backup strategies (as I want daily going back N days, weekly going back N weeks, monthly going back N months, etc). Also, duplicity would run out of memory for me (but restic would too – I eventually settled on the free-to-use-but-not-free-software duplicacy, as I wrote about https://dbp.io/essays/2018-01-01-home-backups.html – some more details about the OOM stuff on the lobsters thread https://lobste.rs/s/pee9vl/cheap_home_backups )

              1. 3

                For one, being able to restore single files without scanning through the archive. The duplicity guys do know about the problems with using tar, but I don’t know when they’ll be able to move away from it.

                1. 3

                  Are you sure this is not possible with using –file-to-restore ?

                  1. 2

                    I’m not 100% sure, I’m just going by my limited knowledge of the tar format and what my link says:

                    Not seek()able inside container: Because tar does not support encryption/compression on the inside of archives, tarballs nowadays are usually post-processed with gzip or similar. However, once compressed, the tar archive becomes opaque, and it is impossible to seek around inside. Thus if you want to extract the last file in a huge .tar.gz or .tar.gpg archive, it is necessary to read through all the prior data in the archive and discard it!

                    My guess is that –file-to-restore has to search for the file in the .tar.gz. If you find otherwise, I’d be interested to know!

            2. 2

              I’ve started creating “archives” of files that I rarely need to look at. It makes duplicity’s dumb full+incremental backup strategy sort of tolerable. The “just use gpg” encryption is too good to give up so far!

              1. 2

                I love duplicity because I feel safe that the data isn’t in some obscure format everything will forget how to read in the future. one full + incrementals with par2 feels very safe