Índice del diarioDockup / nota de campo
Note / self-host-duplicati

Cómo autoalojar Duplicati en 2026: copias de seguridad cifradas, montajes y pruebas de restauración

Guía práctica para autoalojar Duplicati con Docker, puertos, datos persistentes, TLS, seguridad, copias de seguridad y los fallos que impiden usarlo en producción. En 2026.

Si ya has intentado autoalojar Duplicati, probablemente te resulte familiar esta situación frustrante: la interfaz aparece, pero el contenedor ve una ruta vacía porque los orígenes del host se montaron en otro sitio. Recrear el contenedor rara vez resuelve un desacuerdo entre las URL, el estado y las dependencias.

Este recorrido utiliza un único criterio concreto de finalización: hacer una copia de seguridad de un directorio de prueba en el destino elegido, eliminar un archivo de origen y restaurarlo en una ruta alternativa limpia. Cada decisión de configuración se evalúa según ese criterio, no según una insignia verde del contenedor.

Puertos, procesos y servicios privados

Un diagrama útil de Duplicati muestra la ruta pública, el puerto privado 8200, el límite del estado y todos los requisitos de soporte. Marca qué flechas transportan credenciales y cuáles corresponden al tráfico normal de los usuarios. El contrato de red de Duplicati consiste en montajes de origen de solo lectura y almacenamiento de destino de copias de seguridad accesible. Mantén los endpoints privados en el DNS interno, permite únicamente las llamadas salientes necesarias y asigna a Duplicati una credencial de servicio con permisos limitados.

Demuestra el diagrama con una acción real: haz una copia de seguridad de un directorio de prueba en el destino elegido, elimina un archivo de origen y restáuralo en una ruta alternativa limpia. La presión más probable procede del número de archivos de origen, la compresión, el cifrado, la latencia del destino y el solapamiento entre trabajos programados; supervisa esa ruta en lugar de tratar todas las solicitudes HTTP como equivalentes.

Diagnosticar un Duplicati que parece estar sano

Crea dashboards en torno al número de archivos de origen, la compresión, el cifrado, la latencia del destino y el solapamiento entre trabajos programados. Un gráfico de CPU sin el contexto de esa carga de trabajo no puede explicar por qué Duplicati funciona lentamente. Añade una comprobación sintética o programada que intente hacer una copia de seguridad de un directorio de prueba en el destino elegido, eliminar un archivo de origen y restaurarlo en una ruta alternativa limpia usando datos de prueba inocuos.

Antes de actualizar, ten en cuenta este riesgo específico de la aplicación: los cambios en la base de datos de configuración y en el formato de las copias de seguridad de Duplicati deben probarse sin sobrescribir el único conjunto de copias de seguridad remoto. Restaura una copia de seguridad reciente en un despliegue aislado, ejecuta allí las migraciones y compara el comportamiento. Si el contenedor ve una ruta vacía porque los orígenes del host se montaron en otro sitio, inspecciona el límite implicado —origen público, almacenamiento o dependencia— antes de modificar ajustes no relacionados.

Qué debe pasar antes de que lleguen datos reales de Duplicati

El registro de lanzamiento de Duplicati necesita datos concretos, no un “parece correcto”. Guarda el digest de la imagen seleccionada, la suma de comprobación de la configuración, el hostname público y el resultado con marca de tiempo de esta operación: hacer una copia de seguridad de un directorio de prueba en el destino elegido, eliminar un archivo de origen y restaurarlo en una ruta alternativa limpia. Utiliza datos de muestra que no sean de producción para que la comprobación pueda ejecutarse después de cada despliegue.

Demuestra por separado dos eventos del ciclo de vida. La sustitución de un contenedor debe conservar el funcionamiento normal; una recuperación limpia debe demostrar que una instancia nueva de Duplicati puede importar la configuración y restaurar los archivos seleccionados con hashes verificados. Mientras se ejecutan las comprobaciones, mide el número de archivos de origen, la compresión, el cifrado, la latencia del destino y el solapamiento entre trabajos programados, y conserva el resultado como el rango esperado para esta versión.

Prueba también una condición denegada o no válida: deniega temporalmente a la identidad de prueba el acceso a los montajes de origen de solo lectura y al almacenamiento de destino de copias de seguridad accesible. Duplicati debe fallar de forma diagnosticable y no debe sobrescribir un estado correcto. Restablece la condición válida, vuelve a ejecutar la muestra y adjunta los logs relevantes con la información confidencial redactada. Estos artefactos aportan evidencias concretas para una futura decisión de rollback.

Convertir el comando local en un servicio inspeccionable

El siguiente comando hace visible el límite del contenedor sin pretender aprovisionar todos los servicios externos.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Antes de abrir el acceso entrante, inspecciona el entorno resuelto, los montajes y el listener. Añade los ajustes de conexión revisados para los montajes de origen de solo lectura y el almacenamiento de destino de copias de seguridad accesible; utiliza nombres privados para los servicios privados. Un lanzamiento correcto termina cuando puedes hacer una copia de seguridad de un directorio de prueba en el destino elegido, eliminar un archivo de origen y restaurarlo en una ruta alternativa limpia, no cuando docker ps muestra Up.

Hacer medible la recuperación de Duplicati

Enumera el estado antes de crear el primer registro real: la base de datos de configuración de Duplicati y los conjuntos de copias de seguridad verificados por separado. Monta /config antes del bootstrap, escribe datos de muestra inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Confirma el montaje escribiendo datos inocuos, sustituyendo Duplicati y volviendo a leerlos.

Las snapshots son valiosas para hacer rollback rápidamente, pero necesitas una copia de seguridad independiente cuando el host o el volumen desaparecen. Restaura en un entorno vacío con la imagen fijada y verifica que una instancia nueva de Duplicati puede importar la configuración y restaurar los archivos seleccionados con hashes verificados. Usa la guía sobre volúmenes persistentes y snapshots para mantener diferenciados estos dos mecanismos de recuperación.

TLS es sencillo; las URL generadas no

Expón un único hostname HTTPS para Duplicati y mantén privado el puerto 8200 sin proxy. Mantén la interfaz de gestión privada o protegida con una autenticación sólida detrás de HTTPS. Así evitarás que los navegadores y los clientes de API conozcan dos direcciones en conflicto.

Desde un cliente limpio, ejecuta la transacción conocida como correcta e inspecciona la primera solicitud que falle. Usa la guía de dominios personalizados cuando el DNS o TLS no sean correctos. Trata “el contenedor ve una ruta vacía porque los orígenes del host se montaron en otro sitio” como un diagnóstico independiente de la aplicación una vez validada la ruta.

Proteger Duplicati después del bootstrap

Las credenciales de bootstrap son temporales; el modelo de confianza es permanente. Con Duplicati, presta atención a no montar los orígenes de las copias de seguridad con permisos de escritura y a no perder la passphrase de cifrado; monta los orígenes en modo de solo lectura, mantén privada la interfaz de gestión y guarda la passphrase de la copia de seguridad fuera del servidor.

Genera SETTINGS_ENCRYPTION_KEY una sola vez, no lo guardes en Git y consérvalo junto al manifiesto de recuperación, porque cambiarlo puede invalidar el estado cifrado o firmado de la aplicación. Ejecuta la imagen sin capacidades de Linux innecesarias y expón únicamente la ruta pública de la aplicación. Mantén visible la actividad de los administradores sin registrar valores secretos.

Usar Dockup para la capa de plataforma

Para Duplicati, Dockup puede crear la ruta y el certificado TLS, conservar los montajes, entregar secretos y situar los montajes de origen de solo lectura y el almacenamiento de destino de copias de seguridad accesible en una red privada, tanto al realizar el despliegue en Dockup como en servidores conectados.

El criterio de lanzamiento sigue siendo la transacción concreta de Duplicati: hacer una copia de seguridad de un directorio de prueba en el destino elegido, eliminar un archivo de origen y restaurarlo en una ruta alternativa limpia. Verifica también la condición de restauración: una instancia nueva de Duplicati puede importar la configuración y restaurar los archivos seleccionados con hashes verificados. Estas dos comprobaciones muestran si el despliegue funciona y si puede recuperarse.

Preguntas frecuentes

¿Qué necesita Duplicati para un despliegue en producción?

Enruta el contenedor de Duplicati en el puerto 8200 a través de un único origen HTTPS. El requisito de red de soporte consiste en montajes de origen de solo lectura y almacenamiento de destino de copias de seguridad accesible. No des por listo Duplicati hasta que puedas hacer una copia de seguridad de un directorio de prueba en el destino elegido, eliminar un archivo de origen y restaurarlo en una ruta alternativa limpia.

¿Qué datos de Duplicati deben incluirse en una copia de seguridad?

Haz persistente /config e incluye la base de datos de configuración de Duplicati y los conjuntos de copias de seguridad verificados por separado en el mismo manifiesto de recuperación. Una restauración limpia de Duplicati solo se completa cuando una instancia nueva de Duplicati puede importar la configuración y restaurar los archivos seleccionados con hashes verificados.

¿Es necesario HTTPS para Duplicati detrás de un reverse proxy?

Usa HTTPS para el origen público de Duplicati y mantén el puerto 8200 en la ruta interna. Aplica correctamente el ajuste de Duplicati: mantén la interfaz de gestión privada o protegida con una autenticación sólida detrás de HTTPS. En Duplicati, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento de los clientes sensible al origen.

¿Cómo debe probarse una actualización de Duplicati?

Restaura el estado actual de Duplicati en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque los cambios en la base de datos de configuración y en el formato de las copias de seguridad de Duplicati deben probarse sin sobrescribir el único conjunto de copias de seguridad remoto. Conserva la imagen anterior de Duplicati hasta comprender los límites de migración de datos y rollback.