A Duplicati message saying that a .dblock.zip.aes file is missing sounds like backup corruption, but the source thread shows why destructive repair should not be the first reaction. The backup destination existed on the ZimaOS host and was visible over Samba, yet Duplicati's container could not actually see that HDD through its Docker volume mappings.
Once the user mapped the real host HDD into the container and selected the new container-side destination, they replied that it seemed to work. The source therefore ended as a confirmed Docker path-mapping fix, not a confirmed broken-backup purge.
The Initial Error Looked Like a Damaged Duplicati Repository
Duplicati reported that Repair had failed because the backup storage destination was missing a specific encrypted dblock file. The message offered two recovery directions: rebuilding missing block files from local source data or purging backup entries that could no longer be restored.
Those options are real Duplicati features, but they make sense only after verifying that the backup destination being inspected is the correct and complete destination.
The User Was Backing Up One Local Disk to Another
The intended layout was:
- source data on a local SSD;
- backup destination on a separate HDD;
- Duplicati installed from the ZimaOS App Store and therefore running in Docker.
The user selected paths through the application's folder picker and assumed that meant the container could see the same host storage.
A ZimaOS Host Path and a Duplicati Container Path Are Not the Same Thing
A Docker app only sees host folders that have been mounted into the container. ZimaOS can access a disk through Files or Samba while Duplicati sees nothing if that disk is absent from the app's volume configuration.
This is why a connection test alone can be misleading: the destination type may be valid while the intended folder contents are not actually visible in the container namespace.
The Temporary File Test Exposed the Real Problem
The user created a temp.txt file in the destination folder. It was visible over Samba but not from Duplicati's file browser. That was strong evidence that Duplicati was not seeing the actual host HDD contents.
At that point the community responder explicitly changed course and advised not to run purge or rebuild yet.
The Working Fix Was to Map the HDD into the Container
The responder instructed the user to open ZimaOS app settings, add the HDD as a host volume, map it to a simple container path such as /backup, restart the container, and then choose a destination beneath that container path.
The original poster replied: “It seems to work now.”
That confirmed the volume mapping as the practical resolution.
Additional Source Drives Need Their Own Mappings
The user then asked whether one Duplicati job could contain multiple source folders. The community answer was yes, provided every source path is also visible inside the container.
If a second disk is not exposed through the app's Docker volumes, it will not appear correctly in Duplicati no matter how valid the host path is.
Use Current ZimaOS App Volume Mapping Instead of Guessing Raw Paths
Current ZimaOS exposes host and container paths in application settings and documents how persistent storage is mapped into Docker apps.
Use the current ZimaOS Docker path model when adding backup sources or destinations.
When Duplicati Repair Is Appropriate
Duplicati's current command-line documentation says Repair can rebuild the local database from remote storage or attempt to reconstruct missing remote data when the required local source content is still available.
The advanced --rebuild-missing-dblock-files option specifically attempts to recreate missing block files from local source data, but Duplicati warns that the data may have changed and recovery may be incomplete or slow.
purge-broken-files Is Destructive to Restore History
Current Duplicati documentation says purge-broken-files removes files from backup versions that are no longer restorable so the backup set can continue. It should be used only when missing remote data cannot be recovered.
Before purging, check the current Duplicati recovery commands and consequences. A dry run or broken-file listing is safer than deleting backup history blindly.
The Error Message Was Real, but the Underlying Destination Was Wrong
Duplicati was correctly reporting that the repository view it could see lacked expected files. The misleading part was assuming that repository view represented the real HDD. Docker path mapping had pointed the application at an incomplete or different filesystem view.
Duplicati dblock FAQ
Was the source backup repository proven corrupt?
No. The source case was resolved after fixing the Docker volume mapping.
Should purge-broken-files be the first step?
No. Verify that the correct complete destination is mounted and visible before any destructive repair.
Can one Duplicati job back up multiple ZimaOS drives?
Yes, but every source drive must be mapped into the Duplicati container.
