Un mensaje de Duplicati que indica que falta un .dblock.zip.aes que falte el archivo parece corrupción de la copia de seguridad, pero el hilo original muestra por qué la reparación destructiva no debe ser la primera reacción. El destino de la copia de seguridad existía en el host de ZimaOS y era visible mediante Samba, pero el contenedor de Duplicati no podía ver realmente ese HDD a través de sus asignaciones de volúmenes de Docker.
Una vez que el usuario asignó el HDD real del host al contenedor y seleccionó el nuevo destino del lado del contenedor, respondió que parecía funcionar. Por tanto, la fuente terminó confirmando una solución de asignación de rutas de Docker, no una purga confirmada de una copia de seguridad dañada.
El error inicial parecía indicar que el repositorio de Duplicati estaba dañado
Duplicati informó que la reparación había fallado porque faltaba un archivo cifrado específico dblock archivo. El mensaje ofrecía dos vías de recuperación: reconstruir los archivos de bloques que faltaban a partir de los datos de origen locales o purgar las entradas de copia de seguridad que ya no se podían restaurar.
Esas opciones son funciones reales de Duplicati, pero solo tienen sentido después de verificar que el destino de copia de seguridad que se está inspeccionando es el destino correcto y completo.
El usuario estaba haciendo una copia de seguridad de un disco local en otro
La distribución prevista era:
- datos de origen en un SSD local;
- destino de copia de seguridad en un HDD independiente;
- Duplicati se instaló desde la tienda de aplicaciones de ZimaOS y, por tanto, se ejecutaba en Docker.
El usuario seleccionó las rutas mediante el selector de carpetas de la aplicación y supuso que eso significaba que el contenedor podía ver el mismo almacenamiento del host.
Una ruta del host de ZimaOS y una ruta del contenedor de Duplicati no son lo mismo
Una aplicación Docker solo ve las carpetas del host que se han montado en el contenedor. ZimaOS puede acceder a un disco mediante Archivos o Samba, mientras que Duplicati no ve nada si ese disco no está incluido en la configuración de volúmenes de la aplicación.
Por eso una prueba de conexión por sí sola puede inducir a error: el tipo de destino puede ser válido, mientras que el contenido de la carpeta prevista no es realmente visible en el espacio de nombres del contenedor.
La prueba con un archivo temporal reveló el problema real
El usuario creó un temp.txt archivo en la carpeta de destino. Era visible mediante Samba, pero no desde el explorador de archivos de Duplicati. Eso era una prueba contundente de que Duplicati no estaba viendo el contenido real del HDD del host.
En ese momento, el usuario que respondió en la comunidad cambió explícitamente de enfoque y recomendó no ejecutar todavía la purga ni la reconstrucción.
La solución funcional fue asignar el HDD al contenedor
El usuario que respondió indicó que se abrieran los ajustes de la aplicación ZimaOS, se añadiera el HDD como volumen del host y se asignara a una ruta sencilla del contenedor, como /backup, reinicia el contenedor y luego elige un destino dentro de esa ruta del contenedor.
El autor original respondió: «Parece que ahora funciona.»
Eso confirmó que la asignación del volumen era la solución práctica.
Las unidades de origen adicionales necesitan sus propias asignaciones
Después, el usuario preguntó si un solo trabajo de Duplicati podía contener varias carpetas de origen. La respuesta de la comunidad fue que sí, siempre que cada ruta de origen también sea visible dentro del contenedor.
Si un segundo disco no está expuesto mediante los volúmenes Docker de la aplicación, no aparecerá correctamente en Duplicati, por válida que sea la ruta del host.
Usa la asignación actual de volúmenes de aplicaciones de ZimaOS en lugar de adivinar rutas sin procesar
ZimaOS muestra las rutas del host y del contenedor en la configuración de las aplicaciones y documenta cómo se asigna el almacenamiento persistente a las aplicaciones Docker.
Usa el modelo actual de rutas de Docker de ZimaOS al añadir orígenes o destinos de copia de seguridad.
Cuándo es apropiado usar Duplicati Repair
La documentación actual de la línea de comandos de Duplicati indica que Repair puede reconstruir la base de datos local a partir del almacenamiento remoto o intentar reconstruir los datos remotos faltantes cuando el contenido local de origen necesario aún está disponible.
La opción avanzada --rebuild-missing-dblock-files la opción intenta específicamente recrear los archivos de bloques faltantes a partir de los datos locales de origen, pero Duplicati advierte que los datos pueden haber cambiado y que la recuperación puede ser incompleta o lenta.
purge-broken-files es destructivo para el historial de restauración
La documentación actual de Duplicati indica que purge-broken-files elimina archivos de las versiones de copia de seguridad que ya no se pueden restaurar para que el conjunto de copias de seguridad pueda continuar. Solo debe usarse cuando los datos remotos faltantes no puedan recuperarse.
Antes de purgar, consulta los comandos de recuperación actuales de Duplicati y sus consecuencias. Una ejecución de prueba o un listado de archivos dañados es más seguro que eliminar el historial de copias de seguridad a ciegas.
El mensaje de error era real, pero el destino subyacente era incorrecto
Duplicati informaba correctamente de que la vista del repositorio que podía ver no contenía los archivos esperados. Lo engañoso fue asumir que esa vista del repositorio representaba el disco duro real. La asignación de rutas de Docker había dirigido la aplicación a una vista incompleta o diferente del sistema de archivos.
Preguntas frecuentes sobre dblock de Duplicati
¿Se demostró que el repositorio de copias de seguridad de origen estaba dañado?
No. El problema del origen se resolvió después de corregir la asignación del volumen de Docker.
¿Debería purge-broken-files ser el primer paso?
No. Verifica que el destino completo correcto esté montado y visible antes de realizar cualquier reparación destructiva.
¿Puede un trabajo de Duplicati hacer copias de seguridad de varias unidades de ZimaOS?
Sí, pero cada unidad de origen debe estar asignada al contenedor de Duplicati.
