I’m using Duplicati BETA 188.8.131.52 on host A and Duplicati BETA 184.108.40.206_2021-06-17 on host B. I had planned to put (file server) host A out of service and move the disk “exactly as is” to host B and taking duplicati (and existing DB + backup sets) along. I expected my backup job execution on hostB to run through (with almost no Kilobytes changed) within the normally logged job duration of about 8 minutes. BUT: It took about 5 hours.
- Does Duplicati detect a host change, e.g. when the hostname changes from hostA to hostB?
- Does it trigger a full re-read and re-calculation of file checksums by itself?
– Under which preconditions?
So I did the following:
- stopped all services on host A ( ISCSI /datapool , duplicati BETA 220.127.116.11 )
- unmounted the /datapool so nothing got changed since this moment
- installed fresh services on host B ( ISCSI /datapool , duplicati BETA 18.104.22.168 )
- mounted /datapool to host B (exactly with the same options host A mounted it before)
- ensured the fresh duplicati install on host B is stopped (it was after install)
- moved duplicati service config files from host A to host B (/etc/default/duplicati, /etc/systemd/system/duplicati.service.d/override.conf )
- I did not have to move my duplicati .config dir because it’s part of “/datapool0/.config/Duplicati”
- host A “systemctl daemon-reload; systemctl enable duplicati; systemctl start duplicati”
- Duplicati started fine, showed all my existing configuration and jobs
What Duplicati did:
- It saw a (major file server “all files”) backup job was due to execute and it executed it by itself.
- The job ran successfully through, but took very much longer than normal. After the /datapool was accessible again for users, only 2 files (some Kilobytes) were changed before the job executed.
Here is my log of the last backup execution on hostA (“before moving disk + duplicati to hostB”):
Here is my log of the first backup execution on hostB (notice the changed: 5.75 KB):
Here is a log of the next regularly scheduled backup job execution on hostB which took the expected backup duration again:
Summary: I observe a backup job taking very long, re-reading all data with (from admin perspective) no obvious reason and then making “fast differential” scan+backup again as normally expected.
Can this behaviour be fixed or is it intended to recheck everything on “host change”? I again checked twice and my mount point chown/chmod/getfacl of /datapool0 was not modified during “the move”. I also use Syncthing which itself keeps a database with file permissions and checksums and it didn’t report any single changed/re-read file after starting it back up with the existing database of hostA on hostB.
Thanks for your answer.