Duplicati: guía definitiva de backups cifrados en NAS y nube

Tengo un NAS en el rack y, hasta hace poco, la copia de seguridad de esa máquina era un script de rsync que alguien más escribió. Funcionaba, más o menos, hasta el día que el disco falló y me di cuenta de que el script nunca había cifrado nada: los archivos estaban en el NAS en texto plano, guardados con la misma contraseña que usaba para el WiFi. Esa noche aprendí la lección de la manera cara.

Desde entonces vengo usando Duplicati para casi todo lo que necesita respaldo en la casa y en el laboratorio. No es la mejor herramienta del mundo, y no pretende serlo. Lo que gana Duplicati es que es el único de la familia que trae interfaz web, varios destinos en la misma configuración y planificador integrado, sin que tengas que cronar a mano ni montar un wrapper de restic. La 2.4.1.0, que salió el 29 de octubre de 2026, le agrega lo que más me faltaba: pruebas de restauración automatizadas, que se ejecutan solas después de cada backup.

Qué es Duplicati y en qué se diferencia de la línea de comandos

Duplicati es un cliente de backup cifrado, escrito en C# sobre .NET, con licencia MIT desde 2024. La idea central es simple: divides tus archivos en bloques, comprimes lo que se comprime, cifras cada bloque antes de subirlo y después solo mandas al destino remoto los bloques que todavía no están ahí. Es deduplicación a nivel de bloque, no de archivo: si dos archivos distintos comparten un bloque de contenido, ese bloque se sube y se almacena una sola vez. Al final de cada ejecución se sube además una lista de archivos que explica cómo recrear todo lo procesado.

La diferencia con restic, borg y kopia no está en el algoritmo de deduplicación, que cumple el mismo papel en los tres casos. La diferencia está en la operación. Duplicati trae:

• Interfaz web propia, servida por el propio binario en el puerto 8200, para configurar destinos, revisar historiales y ejecutar restauraciones.
• Varios destinos en una sola configuración. La 2.4.0.0 agregó además el modo sync, que copia archivos sin cifrar ni deduplicar, como espejo en vez de como versionado.
• Planificador integrado. No dependes de cron ni de systemd timers.
• Actualizador automático, con canales stable y canary separados.

Duplicati frente a la línea de comandos

El trade-off es que el servicio corre como root y que el modelo de configuración es más pesado que un simple YAML de restic. Si lo que necesitas es un backup de script desatendido y legible, Duplicati te va a sobrar. Si lo que necesitas es una consola donde ver qué pasó con cada versión, la diferencia es enorme.

Capacidad	Duplicati	restic	borg
Interfaz web integrada	Sí, en el puerto 8200	No	No
Planificador propio	Sí, sin cron	No, con cron o systemd timer	No, con cron o systemd timer
Varios destinos en una configuración	Sí	No, un repositorio por configuración	No, un repositorio por configuración
Cifrado por defecto	AES-256	AES-256	AES-256
Modo espejo sin versionado	Sí, sync	No	No
Prueba de restauración automatizada	Sí, desde la 2.4.1.0	No	No

Instalar Duplicati en Linux

Los paquetes oficiales cubren las tres familias que existen: .deb para Debian, Ubuntu y Mint, .rpm para Fedora, RHEL y SUSE, y .zip para todo lo demás. La 2.4.1.0 viene en tres variantes por arquitectura: gui (con icono de bandeja), cli (solo línea de comandos) y agent (el servicio sin interfaz).

# Descargar el paquete CLI de la versión estable actual
wget https://github.com/duplicati/duplicati/releases/download/v2.4.1.0_stable_2026-10-29/duplicati-2.4.1.0_stable_2026-10-29-linux-x64-cli.deb
# Instalar y revisar que el servicio quedó activo
sudo apt install ./duplicati-2.4.1.0_stable_2026-10-29-linux-x64-cli.deb
systemctl status duplicati --no-pager

El servicio se llama duplicati y arranca con /usr/bin/duplicati-server $DAEMON_OPTS. Si la instalación quedó bien, en el log del servicio vas a ver que el servidor escucha en el puerto 8200. Si el puerto está ocupado por otra cosa, no falla: Duplicati prueba el siguiente y lo dice en el log.

El systemctl status también es el primer lugar donde mirar cuando algo no arranca. El caso clásico es un servicio que sale de inmediato porque la carpeta de datos tiene permisos laxos, tema que veremos en detalle más adelante porque es el cambio que más rompe instalaciones al actualizar.

Entender la carpeta de datos antes de tocar nada

Este es el punto donde la mayoría de las guías fallan, así que lo voy a explicar con calma. Duplicati guarda una base de datos local con la configuración de cada backup, el índice de bloques y el historial de versiones. Esa base de datos no viaja al destino remoto: es estado local, y es la razón por la que Duplicati necesita una carpeta de datos propia y persistente.

Por defecto esa carpeta es ~/.config/Duplicati para un usuario normal, y /var/lib/Duplicati o /root/.config/Duplicati cuando corre como servicio, porque el servicio corre como root. Si quieres fijar una ubicación concreta, la bandera es --server-datafolder.

# Ver los permisos reales de la carpeta de datos
sudo stat -c '%A %a %U:%G %n' /var/lib/Duplicati
# Forzar los permisos correctos que Duplicati exige
sudo duplicati-configure secure-datafolder
# Verificar que quedó como debe (700 y solo root)
sudo stat -c '%A %a %U:%G %n' /var/lib/Duplicati

El duplicati-configure secure-datafolder es el comando que conviene tener a mano. Es idempotente: si los permisos ya están bien, no hace nada y no rompe nada.

El cambio que más rompe instalaciones al actualizar

La 2.4.0.0, publicada el 3 de septiembre de 2026, introdujo un breaking change real: Duplicati ahora exige que la carpeta de datos tenga exactamente los permisos esperados y, si no los tiene, se niega a usarla. Antes de esa versión, el programa simplemente endurecía los permisos en silencio la primera vez que arrancaba. Ahora se niega a arrancar.

El mensaje de error en sí es bastante críptico, así que la estrategia correcta es verificar los permisos antes de actualizar, no después. Y hay tres salidas oficiales si tu setup genuinamente no puede cumplir los permisos, por ejemplo en Docker:

1. El flag --allow-insecure-datafolder.
2. La variable de entorno DUPLICATI__ALLOW_INSECURE_DATAFOLDER=true.
3. Un archivo llamado insecure-permissions.txt en la carpeta de instalación, no en la carpeta de datos.

Ese tercer punto es donde se tragan la mitad de las actualizaciones: insecure-permissions.txt antes vivía en la carpeta de datos y ahora ya no se lee ahí. Si lo dejaste ahí creyendo que seguía funcionando, el chequeo sigue aplicando y el servicio no arranca. Mismo caso para preload.json: las rutas /usr/local/share/Duplicati/preload.json y C:ProgramDataDuplicatipreload.json ya no son rutas confiables, porque no se puede garantizar que estén bloqueadas. En su lugar se usan la carpeta de los binarios y la ruta que apunte DUPLICATI_PRELOAD_SETTINGS. Un preload.json dentro de la carpeta de datos sí sigue soportado, siempre que la carpeta pase el chequeo de permisos.

# Revisar ANTES de actualizar: estos son los tres opt-out
sudo grep -rl "allow-insecure-datafolder" /etc/default/duplicati 2>/dev/null
sudo ls -la /etc/default/duplicati
sudo cat /etc/default/duplicati

El archivo /etc/default/duplicati es el lugar oficial para pasar opciones al servicio en Debian, y en RPM es /etc/sysconfig/duplicati. La variable se llama DAEMON_OPTS y es lo que usas para inyectar el opt-out o para fijar la carpeta de datos sin tocar el archivo de servicio, que se sobrescribe en cada actualización del paquete.

# Fijar carpeta de datos y permitir permisos laxos (típico en Docker)
sudo tee /etc/default/duplicati >/dev/null <<'EOF'
DAEMON_OPTS="--server-datafolder=/var/lib/Duplicati --allow-insecure-datafolder"
EOF
sudo systemctl restart duplicati
systemctl status duplicati --no-pager

Configurar un primer destino cifrado en tu NAS

Vamos a hacerlo por línea de comandos primero, porque es la forma más rápida de entender qué está pasando, y después dejamos el servicio tomando el relevo. El destino será tu NAS por SFTP, que es el transporte que mejor se comporta con rutas que contienen espacios y caracteres raros.

# Crear el destino en el NAS por SSH (reemplaza los valores por los tuyos)
mkdir -p /volume1/backups/duplicati
chmod 700 /volume1/backups/duplicati
# Probar conectividad antes de configurar nada
ssh -i /home/TU_USUARIO/.ssh/id_ed25519 TU_USUARIO@TU_NAS "ls -ld /volume1/backups/duplicati"

Con la conectividad confirmada, se crea el backup. El argumento --dbpath le dice a Duplicati qué base de datos local usar, y es obligatorio cuando corres la CLI sin el servidor levantado: sin él, Duplicati adivina qué base de datos usar a partir de la URL del destino y puedes acabar respaldando sobre la configuración equivocada.

# Crear el backup cifrado (el prompt pide la contraseña de cifrado)
duplicati-cli backup 
  "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  "/srv/datos" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --encryption-module=aes

El cifrado por defecto es AES-256 con el formato AESCrypt, y es lo que debes dejar: cada volumen se cifra con una clave de archivo (FEK) distinta y lleva una firma HMAC que evita modificaciones. La alternativa con GPG existe, pero exige que los binarios de GnuPG estén presentes en el sistema y usa CAST-128 por defecto, que es más lento y más frágil de administrar.

La 2.4 puede escribir dos versiones del formato AES Crypt. Sigue escribiendo la versión 2 salvo que pongas --aes-version=3, que usa una derivación de clave más robusta con --aes-v3-iterations (300000 por defecto). Ojo: los volúmenes en versión 3 solo se leen con Duplicati 2.4 o posterior, así que no lo actives si tu plan es hacer downgrade. Duplicati lee ambas versiones de todos modos, así que los volúmenes que ya tienes siguen funcionando.

Para listar qué versiones existen, hay dos comandos que se complementan: list da el historial de operaciones y list-file-versions el detalle por archivo.

# Ver el historial de operaciones del backup
duplicati-cli list "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db
# Ver las versiones disponibles de un archivo concreto
duplicati-cli list-file-versions "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  "/srv/datos/informe.xlsx" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db

Probar que el backup realmente se puede restaurar

Este es el gancho de la 2.4.1.0 y, en mi opinión, la mejora más importante de la línea 2.4. Hasta ahora, la verificación posterior al backup consistía en que Duplicati descargaba unos cuantos volúmenes al azar para confirmar que el destino respondía. Eso te dice que los archivos existen. No te dice que puedas restaurarlos.

La 2.4.1.0 agrega la operación restore-test: toma una muestra de una versión del backup, la restaura en una carpeta temporal usando solo datos remotos, y verifica cada archivo restaurado contra el tamaño y el hash que quedaron registrados en el backup. Si todo cuadra, el backup queda demostrado como restaurable.

# Probar la restaurabilidad con una muestra aleatoria
duplicati-cli restore-test "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --restore-test-mode=Rolling
# Modo agresivo: reconstruir la base de datos desde el destino y verificar todo
duplicati-cli restore-test "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --restore-test-mode=Full 
  --restore-test-recreate-database

El modo Rolling es el que yo dejaría configurado: prefiere archivos que no se hayan verificado recientemente, de forma que cada archivo pasa por la prueba al menos una vez por ventana de rotación. Con --restore-test-recreate-database, la base de datos local se reconstruye desde el destino remoto en un archivo temporal, así que la prueba no depende de nada local: es exactamente el escenario de “la máquina murió y me traje el backup”.

Y lo mejor de todo: se puede encadenar al backup para que corra sola al final de cada ejecución, sin cron ni scripts externos.

# Lanzar la prueba de restauración al final de cada backup
duplicati-cli backup 
  "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  "/srv/datos" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --encryption-module=aes 
  --perform-restore-test-after=1D

El 1D es el intervalo: la prueba se dispara si la anterior tiene más de un día de antigüedad. Si la máquina está conectada a la consola de Duplicati, la consola puede fijar ese intervalo remotamente, y un fallo en la prueba genera su propia notificación, separada del resultado del backup. Esto último es un detalle de diseño que importa: un backup que termina bien pero que no se puede restaurar no es un backup exitoso, y ahora el sistema te lo dice.

Restaurar de verdad, en dos escenarios distintos

Hay dos restauraciones que se confunden todo el tiempo. La primera es la rutinaria: traes una versión concreta de un archivo a una carpeta de trabajo. La segunda es la de emergencia: te traes el backup a una máquina nueva.

# Escenario 1: restaurar una versión puntual a una carpeta de trabajo
duplicati-cli restore "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  "/srv/datos/informe.xlsx" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --version=12 
  --restore-path=/tmp/recuperado
# Escenario 2: restaurar un archivo desde varias versiones a la vez
duplicati-cli restore "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  "/srv/datos" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --restore-all-files 
  --restore-path=/tmp/recuperado

La bandera --restore-all-files es la que permite el segundo escenario, y es nueva en la 2.4.0.0: restaura todos los archivos que cumplan un filtro, tomando de cada uno la versión que corresponda, en vez de una sola versión completa del backup.

Para el escenario de emergencia, la opción que te salva el día es --remote-point-in-time, que llegó a las ramas canary con la 2.4.0.100 y la 2.4.0.105, y permite leer el destino tal como estaba en un momento concreto del pasado usando el versionado del bucket.

# Leer el destino como estaba hace 2 días y 4 horas (el destino queda en solo lectura)
duplicati-cli restore "sftp://TU_USUARIO@TU_NAS/volume1/backups/duplicati" 
  "/srv/datos" 
  --dbpath=/var/lib/Duplicati/SQLite/backup-001.db 
  --remote-point-in-time=2D4h

Mientras la opción está activa, el destino queda en solo lectura. Sirve para el caso en que el destino versionado está dañado o alguien manipuló una versión: lees el estado histórico, no el actual. Acepta también una fecha absoluta en lugar del valor relativo.

El modo sync: cuando no quieres versionado

Desde la 2.4.0.0 existe un modo sync que se comporta al revés de un backup. En vez de deduplicar, comprimir, cifrar y versionar, copia los archivos tal cual. Es lo que quieres cuando el destino es un espejo, no un archivo de historial.

# Sincronizar el contenido, sin cifrado ni deduplicación
duplicati-cli sync "sftp://TU_USUARIO@TU_NAS/volume1/mirror" 
  "/srv/datos" 
  --dbpath=/var/lib/Duplicati/SQLite/sync-001.db 
  --no-encryption=true
# Además, borrar en el destino lo que ya no existe en el origen
duplicati-cli sync "sftp://TU_USUARIO@TU_NAS/volume1/mirror" 
  "/srv/datos" 
  --dbpath=/var/lib/Duplicati/SQLite/sync-001.db 
  --no-encryption=true 
  --sync-then-delete

La primera advertencia es de sintaxis: el modo sync rechaza el cifrado y lanza un error si no lo desactivas explícitamente con --no-encryption=true. No es opcional, no es un valor por defecto y no lo deduce del hecho de que el espejo no lleve versión.

Las otras dos advertencias son de fondo. Primera: el borrado en el destino con --sync-then-delete es irreversible, así que no lo actives hasta estar seguro de que el origen es la fuente de verdad. Segunda: el destino queda de solo lectura en la parte de versionado, pero en modo sync se puede borrar; una carpeta de destino mal configurada es un rm -rf esperando. Tercera: un trabajo de backup y un trabajo de sync no son compatibles, porque usan lógicas de almacenamiento completamente distintas, y el modo no se puede cambiar después de crear el trabajo: hay que crear uno nuevo.

El parámetro --sync-remote-state controla cómo Duplicati sabe qué hay que subir. Por defecto vale UseRemoteState, que lista el destino y deduce qué falta. Con UseLocalState usa una base de datos local, igual que un backup, y hace menos listados remotos. Con BlindlyUpload sube todo sin preguntar, que es lo más rápido y lo más peligroso: en este modo los borrados se omiten con una advertencia.

Administrar la base de datos local

La 2.4.1.0 actualiza la base de datos local del esquema 19 al 22, y la base de datos de sync a la versión 1. La 2.4.0.1 no puede abrir las bases nuevas, así que si tienes que volver atrás, el orden es obligatorio: primero bajas de esquema, después bajas la versión del programa.

# Listar las bases de datos conocidas y su estado (Found/Missing/Orphaned)
duplicati-database-tool verify --datafolder=/var/lib/Duplicati
# Bajar el esquema ANTES de reinstalar una versión vieja de Duplicati
duplicati-database-tool downgrade --server-datafolder=/var/lib/Duplicati

El manual es explícito: la herramienta de base de datos debe estar en la versión más reciente para que el downgrade funcione, o sea que corres el downgrade antes de desinstalar la versión nueva. La 2.4.0.0 también agregó los comandos verify, cleanup y wipe-encryption al mismo tool, que es lo que usarías para recuperar una base cifrada de la que perdiste la contraseña.

Los defaults de la herramienta apuntan a las versiones de la release estable más reciente, así que en el caso normal no hace falta pasar --server-version, --local-version ni --sync-version. Si necesitas control fino, esos flags existen.

Docker: cuando los permisos no se pueden cumplir

Este es el escenario que más te va a doler si no lo anticipas. En Docker, el contenedor corre con un usuario que muchas veces no puede hacer chmod sobre la carpeta montada, y Duplicati se niega a arrancar. La salida oficial es la variable de entorno en la imagen.

# Levantar Duplicati en Docker permitiendo permisos laxos
docker run -d 
  --name duplicati 
  --restart unless-stopped 
  -p 8200:8200 
  -e DUPLICATI__ALLOW_INSECURE_DATAFOLDER=true 
  -v /mnt/datos:/source:ro 
  -v /mnt/duplicati-data:/home/duplicati 
  -v /mnt/duplicati-config:/home/duplicati/.config/Duplicati 
  lscr.io/linuxserver/duplicati:2.4.1

La imagen de LinuxServer sigue la 2.4.1.0 con el tag 2.4.1. Si prefieres la imagen oficial de Duplicati, el tag 2.4.1.0 existe en Docker Hub y es la opción más directa. El propio README de Duplicati trae el ejemplo con la variable de entorno del opt-out, que es exactamente el escenario que se describe arriba.

Lo que no debes hacer es montar el /home/duplicati de un contenedor a otro, porque la base de datos local es específica de la máquina que la creó: los identificadores de máquina y de instalación se derivan de ella y moverla entre hosts produce duplicación de volúmenes o corrupción silenciosa.

Duplicati Storage y la consola de Duplicati

La 2.4.0.0 incluyó el backend de Duplicati Storage, integrado con la consola de Duplicati. Cuando una máquina se conecta a la consola, puede usar las asignaciones de almacenamiento de la cuenta sin configuración: no hay que crear buckets ni claves de API a mano. La 2.4.1.0 le agrega poder usarlo como destino secundario y soporte de object locking.

La URL de destino tiene este formato, con los valores que te entrega la consola:

# Formato de la URL de destino de Duplicati Storage
duplicati://?duplicati-auth-apikey=TU_CLAVE&duplicati-auth-apiid=TU_ORGANIZACION&duplicati-endpoint=TU_ENDPOINT

Si la máquina que hizo el backup se perdió, la consola puede emitir una clave temporal de solo lectura que se pega como URL de destino en cualquier otra instalación para restaurar. Es el mecanismo de recuperación de desastre que más uso de la consola.

Cuándo Duplicati no es la mejor opción

Sin rodeos: si ya tienes un cron bien armado con restic, restic es mejor opción que Duplicati. Es más rápido, más transparente, la base de datos es un archivo que puedes copiar, y el comportamiento de borrado lo controlas tú. Cambiar a Duplicati es trabajo sin retorno claro si nadie más va a operar ese respaldo.

Duplicati gana cuando el volumen de datos es heterogéneo y las fuentes son múltiples, cuando hay varias personas o máquinas que necesitan compartir la misma política de respaldo, o cuando el requisito de “alguien que no es sysadmin tiene que poder restaurar esto” pesa más que la simplicidad del código. El planificador integrado y la interfaz web son la razón real de su existencia.

Un riesgo que conviene decir en voz alta: el servicio corre como root y guarda la contraseña de cifrado de forma que el sistema puede recuperarla. Si alguien con acceso root a la máquina quiere descifrar tus backups, puede. El cifrado protege contra el NAS comprometido o contra alguien que solo tenga los datos remotos, no contra un atacante con acceso al servidor.

Y el detalle que más me importa a mí: un backup cifrado del que nunca probaste una restauración no es un backup, es una esperanza con cifrado. La 2.4.1.0 con --perform-restore-test-after es la primera versión que te obliga, de forma automatizada, a convertir esa esperanza en evidencia.

Preguntas frecuentes

Lee también

• Restic vs Borg vs Kopia: comparativa honesta de backups cifrados en 2026
• Backups, snapshots y restauración en Proxmox sin perder datos
• OpenMediaVault 8: NAS Linux serio paso a paso