Duplicity: backup criptografado e eficiente em largura de banda

Percepções gerais sobre o Duplicity

• Visto como uma ferramenta de backup sólida, duradoura e criptografada; alguns o usam há muitos anos sem problemas.
• Principal crítica técnica: o modelo de completos + incrementais leva a cadeias longas de backup, maior uso de armazenamento e necessidade de backups completos novos periodicamente.
• Alguns o consideram pesado em CPU (por exemplo, ventoinhas do macOS acelerando) e menos eficiente do que opções mais novas.
• Reclamações sobre avisos barulhentos do Python na saída do cron; também mencionam que instalações antigas ainda podem estar no Python 2.
• Problema relatado: quando um backend falha (por exemplo, um problema de roteamento IPv6 em SFTP), o Duplicity pode abortar completamente apesar das configurações de “continuar em caso de erro”.
• Observação de cautela sobre a semântica de restauração: especificar incorretamente um diretório de destino pode sobrescrevê-lo em vez de restaurar nele.
• Frontends mencionados: Duply e DejaDup (com backend Restic experimental).

Comparação com outras ferramentas de backup

• Muitos comentaristas migraram do Duplicity para Borg, Restic, Kopia ou Duplicacy.
• Borg: elogiado por deduplicação, snapshots frequentes rápidos, montagem via FUSE para restaurações fáceis, políticas de poda e repositórios pequenos; a crítica inclui dificuldade com múltiplos hosts usando o mesmo repositório ao mesmo tempo.
• Restic: apreciado pela simplicidade de um único binário, montagens FUSE, suporte a backends remotos “burros” (S3, SFTP) e deduplicação + compressão de dados criptografados. Alguns relatam maior uso de memória, problemas de desempenho e peculiaridades como granularidade de timestamp de segundo.
• Kopia: com endereçamento por conteúdo, deduplicação, suporta compressão zstd e regras complexas de ignore; algumas preocupações anteriores sobre o tamanho do repositório “inchando”, mas outros relatam paridade com o Borg.
• Duplicacy: citado como confiável para configurações multi-máquina, com um único repositório e replicação fácil para a nuvem.
• Duplicati: vários relatos de restaurações extremamente lentas ou efetivamente falhando em repositórios de tamanho moderado.

Estratégias de armazenamento em nuvem e S3

• Scripts simples de shell com aws s3 sync são propostos como alternativa, mas outros observam:
  • Eles espelham em vez de manter um histórico de backup estruturado, a menos que o versionamento do S3 seja usado.
  • Não há diferenciais no nível de bloco nem deduplicação; renomeações/movimentações de arquivos grandes são custosas.
  • A criptografia no lado do servidor não é ponta a ponta; criptografia no lado do cliente e deduplicação oferecidas por Borg/Restic/duplicity são vistas como mais fortes.

Projetos com endereçamento por conteúdo e deduplicação

• IDs baseados em conteúdo e hashes deslizantes (como em Kopia, Borg, Restic) permitem:
  • Deduplicação entre hosts.
  • Snapshots lógicos “completos” sem backups completos periódicos, já que blobs são compartilhados e coletados como lixo.
• Preocupações levantadas:
  • Compartilhamento de blobs significa que a corrupção afeta todos os snapshots que referenciam aquele blob; a mitigação sugerida inclui redundância (RAID, codificação de apagamento) e verificação periódica.
  • Esses designs podem vazar metadados e algumas informações sobre similaridade de arquivos, então usuários altamente paranoicos podem preferir tar/zip simples + criptografia do arquivo inteiro.

Usabilidade, GUIs e orquestração

• Borg tem GUIs e orquestradores maduros (por exemplo, Vorta, Pika Backup, borgmatic).
• O ecossistema do Restic é mais fragmentado: existem vários wrappers (autorestic, resticprofile, Backrest, npbackup, Prestic) com diferentes níveis de maturidade, o que dificulta a escolha, especialmente para usuários não técnicos e suporte ao macOS.

Integridade de dados e testes de backup

• Forte ênfase em testar backups regularmente, não apenas criá-los.
• Para Borg, recomenda-se executar borg check --verify-data via cron, junto com restaurações manuais ocasionais (por exemplo, em uma VM) para confirmar a recuperação de ponta a ponta.
• Algumas ferramentas fornecem verificação do repositório e verificação aleatória de subconjuntos; detecção de corrupção, redundância e cópias fora do local são consideradas boas práticas.

Outros alertas e recomendações

• Aviso explícito contra usar rdiff-backup devido a problemas relatados com tratamento de ENOSPC, operações “regress” complicadas e restaurações ineficientes envolvendo muitos diferenciais reversos.
• Vários comentaristas recomendam restic + rclone, ou Kopia, como soluções modernas, estáveis, criptografadas e com deduplicação, que funcionam bem com backends em nuvem e grandes conjuntos de dados.