Duplicity: copia de seguridad cifrada y eficiente en ancho de banda

Percepciones generales sobre Duplicity

• Se considera una herramienta de copias de seguridad sólida, de larga trayectoria y cifrada; algunos la han usado durante muchos años sin problemas.
• Crítica técnica principal: el modelo de copias completas + incrementales conduce a cadenas de copias largas, mayor uso de almacenamiento y la necesidad de realizar periódicamente nuevas copias completas.
• Algunos la encuentran intensiva en CPU (por ejemplo, ventiladores de macOS a toda velocidad) y menos eficiente que opciones más nuevas.
• Quejas por advertencias ruidosas de Python en la salida de cron; también se menciona que instalaciones antiguas aún pueden estar en Python 2.
• Problema reportado: cuando falla un backend (por ejemplo, un problema de enrutamiento IPv6 en SFTP), Duplicity puede abortar por completo pese a la configuración de “continue on error”.
• Nota de precaución sobre la semántica de restauración: especificar incorrectamente un directorio de destino puede sobrescribirlo en lugar de restaurar dentro de él.
• Frontends mencionados: Duply y DejaDup (con backend Restic experimental).

Comparación con otras herramientas de copia de seguridad

• Muchos comentaristas han migrado de Duplicity a Borg, Restic, Kopia o Duplicacy.
• Borg: elogiado por la deduplicación, instantáneas frecuentes rápidas, montaje FUSE para restauraciones sencillas, políticas de poda y repositorios pequeños; la crítica incluye la dificultad de que varios hosts usen concurrentemente el mismo repositorio.
• Restic: apreciado por la simplicidad de un solo binario, montajes FUSE, soporte para backends remotos “tontos” (S3, SFTP) y deduplicación + compresión de datos cifrados. Algunos informan un uso de memoria más alto, problemas de rendimiento y particularidades como granularidad de marcas de tiempo a nivel de segundo.
• Kopia: basado en direccionamiento por contenido, con deduplicación, compatibilidad con compresión zstd y reglas complejas de exclusión; algunas preocupaciones previas sobre el “hinchado” del tamaño del repositorio, pero otros informan paridad con Borg.
• Duplicacy: citado como fiable para configuraciones de varias máquinas y un solo repositorio, con replicación sencilla a la nube.
• Duplicati: múltiples informes de restauraciones extremadamente lentas o prácticamente fallidas en repositorios de tamaño moderado.

Estrategias de almacenamiento en la nube y S3

• Se proponen scripts simples de shell con aws s3 sync como alternativa, pero otros señalan:
  • Reflejan en espejo en lugar de mantener un historial de copias estructurado, salvo que se use versionado de S3.
  • No hay diferenciales a nivel de bloque ni deduplicación; los renombres/movimientos de archivos grandes son costosos.
  • El cifrado del lado del servidor no es de extremo a extremo; el cifrado del lado del cliente y la deduplicación ofrecidos por Borg/Restic/duplicity se consideran más sólidos.

Diseños basados en contenido y con deduplicación

• Los IDs basados en contenido y los hashes deslizantes (como en Kopia, Borg, Restic) permiten:
  • Deduplicación entre hosts.
  • Instantáneas lógicas “completas” sin copias completas periódicas, ya que los blobs se comparten y se recolectan como basura.
• Preocupaciones planteadas:
  • El compartido de blobs significa que la corrupción afecta a todas las instantáneas que hacen referencia a ese blob; se sugiere mitigar con redundancia (RAID, codificación de borrado) y verificación periódica.
  • Estos diseños pueden filtrar metadatos y parte de la información sobre la similitud de los archivos, por lo que los usuarios muy paranoicos podrían preferir tar/zip simples con cifrado de todo el archivo.

Usabilidad, GUI y orquestación

• Borg cuenta con GUI y orquestadores maduros (por ejemplo, Vorta, Pika Backup, borgmatic).
• El ecosistema de Restic está más fragmentado: existen varios wrappers (autorestic, resticprofile, Backrest, npbackup, Prestic) con distinta madurez, lo que dificulta la elección, especialmente para usuarios no técnicos y el soporte de macOS.

Integridad de datos y pruebas de copias de seguridad

• Se hace un fuerte énfasis en probar regularmente las copias de seguridad, no solo en crearlas.
• Para Borg, se sugiere ejecutar borg check --verify-data vía cron, junto con restauraciones manuales ocasionales (por ejemplo, en una VM) para confirmar la recuperación de extremo a extremo.
• Algunas herramientas proporcionan comprobación de repositorios y verificación de subconjuntos aleatorios; la detección de corrupción más la redundancia y las copias fuera del sitio se consideran buenas prácticas.

Otras advertencias y recomendaciones

• Advertencia explícita contra el uso de rdiff-backup debido a problemas reportados con el manejo de ENOSPC, operaciones “regress” complicadas y restauraciones ineficientes que implican muchos diferenciales inversos.
• Varios comentaristas recomiendan restic + rclone, o Kopia, como soluciones modernas, estables, cifradas y con deduplicación, que funcionan bien con backends en la nube y conjuntos de datos grandes.