Duplicity: Encrypted bandwidth-efficient backup

Overall perceptions of Duplicity

• Seen as a solid, long-lived, encrypted backup tool; some have used it for many years without issues.
• Main technical criticism: full + incremental model leads to long backup chains, larger storage use, and need for periodic new full backups.
• Some find it CPU-heavy (e.g., macOS fans spinning) and less efficient than newer options.
• Complaints about noisy Python warnings in cron output; also mention that older installs may still be on Python 2.
• Reported issue: when one backend fails (e.g., SFTP IPv6 routing problem), Duplicity may abort entirely despite “continue on error” settings.
• Cautionary note on restore semantics: specifying a target directory incorrectly can overwrite it rather than restoring into it.
• Frontends mentioned: Duply and DejaDup (with experimental Restic backend).

Comparison with other backup tools

• Many commenters have migrated from Duplicity to Borg, Restic, Kopia, or Duplicacy.
• Borg: praised for deduplication, fast frequent snapshots, FUSE mounting for easy restores, pruning policies, and small repos; criticism includes difficulty with multiple hosts concurrently using the same repo.
• Restic: appreciated for single-binary simplicity, FUSE mounts, support for “dumb” remote backends (S3, SFTP), and dedup+compression of encrypted data. Some report higher memory use, performance issues, and quirks like second-level timestamp granularity.
• Kopia: content-addressed, deduplicating, supports zstd compression and complex ignore rules; some earlier concerns about repo size “ballooning” but others report parity with Borg.
• Duplicacy: cited as reliable for multi-machine, single-repo setups with easy replication to cloud.
• Duplicati: multiple reports of extremely slow or effectively failing restores on modest-sized repos.

Cloud storage and S3 strategies

• Simple aws s3 sync shell scripts are proposed as an alternative, but others note:
  • They mirror rather than maintain structured backup history unless S3 versioning is used.
  • No block-level differentials or deduplication; renames/moves of large files are costly.
  • Server-side encryption is not end-to-end; client-side encryption and dedup offered by Borg/Restic/duplicity are seen as stronger.

Content-addressed and deduplicating designs

• Content-based IDs and rolling hashes (as in Kopia, Borg, Restic) enable:
  • Cross-host deduplication.
  • “Full” logical snapshots without periodic full backups, since blobs are shared and garbage-collected.
• Concerns raised:
  • Blob sharing means corruption affects all snapshots referencing that blob; mitigation suggested via redundancy (RAID, erasure coding) and periodic verification.
  • These designs can leak metadata and some information about file similarity, so highly paranoid users might prefer simple tar/zip + whole-archive encryption.

Usability, GUIs, and orchestration

• Borg has mature GUIs and orchestrators (e.g., Vorta, Pika Backup, borgmatic).
• Restic’s ecosystem is more fragmented: multiple wrappers (autorestic, resticprofile, Backrest, npbackup, Prestic) exist with varying maturity, making choice harder, especially for non-technical users and macOS support.

Data integrity and backup testing

• Strong emphasis on regularly testing backups, not just creating them.
• For Borg, running borg check --verify-data via cron is suggested, along with occasional manual restores (e.g., into a VM) to confirm end-to-end recovery.
• Some tools provide repository checking and random subset verification; corruption detection plus redundancy and offsite copies are considered best practice.

Other warnings and recommendations

• Explicit warning against using rdiff-backup due to reported issues with ENOSPC handling, complicated “regress” operations, and inefficient restores involving many reverse differentials.
• Multiple commenters recommend restic + rclone, or Kopia, as modern, stable, encrypted, deduplicating solutions that work well with cloud backends and large data sets.