I am running duplicati in a docker on unraid server and I have been having this chronic issue. After successfully doing a complete back up of all my files, I run a new back and after backing up six or seven files, duplicati crashes and the “cannot connect….” message appears.
Eventually the docker just remains in this frozen state. I cannot connect to it, I cannot stop the docker, nothing.
I will wait overnight check the next morning and the docker is still frozen.
The only solution I have found is to disconnect the mounted drives its backing up to, put the back server to sleep, then try to stop the docker and eventually (hours later), it will stop.
Nope. The docker container is using the existing databases. I took care to make sure the original paths that were being backed up are available to the container in the same locations. So…Duplicati should speed through this first backup as a docker container without knowing any different.
I got busy earlier but am now testing to see if the timestamps are exactly the same. They should be, they are the same underlying files after all!
20190727T1327009416Z - timestamp of file
20190727T1327000000Z - timestamp in database
Question is…how did this happen. Maybe Duplicati running directly on Synology could only get truncated filetime resolution… and now running in a docker container it somehow has access to higher resolution timestamps? Who knows.
I guess I have a couple options - let it reprocess all the data, or adjust the code to dismiss differences in sub-second timestamp variations…