Apologies for the confusion earlier. It turns out the pre-script, which stops my container and performs a software update, was running so quickly (likely because no update was necessary) that it immediately started the backup process. After some trial and error, everything now appears to be working perfectly as expected.
To improve stability, I added set -eo pipefail at the top of my scripts. This ensures that any errors in the script cause it to exit immediately and avoids unintended behavior.
For anyone encountering a similar issue in the future, here’s an important note about Docker setups, especially when dealing with Docker-in-Docker configurations:
Key Issue:
You cannot mount relative paths inside a Docker-in-Docker setup. For example, if you mount a directory like this:
"./data:/data/"
It will work fine on your host system—for instance, it will resolve to something like:
/home/user/your_server/data:/data/.
However, if you then mount /home/user/your_server/ to /source/ in your Duplicati container, and later attempt to restart the container using docker-compose, your host system will interpret this mount as:
/source/data:/data/.
This will break the expected behavior because the relative paths within the Duplicati container won’t resolve correctly to the host system’s absolute paths. But your docker is executed on your host system.
Solution:
To fix this issue, always mount your server directories to the same absolute path in the Duplicati container. For example:
/home/user/my_server:/home/user/my_server
By doing this, any relative paths inside the Duplicati container will correctly map to the corresponding absolute paths on your host system. This ensures consistency and prevents path resolution issues.
I hope this explanation helps anyone facing a similar problem! Let me know if you have further questions or need clarification.
