So destination error on a List. One thing that might help (although it may increase risk of a stuck system) is using an NFS hard mount instead of soft mount. Instead of returning an error to the process, it keeps trying.
These options are valid to use with any NFS version.
soft / hard
Determines the recovery behavior of the NFS client after an NFS request times out. If neither option is specified (or if the hard option is specified), NFS requests are retried indefinitely. If the soft option is specified, then the NFS client fails an NFS request after retrans retransmissions have been sent, causing the NFS client to return an error to the calling application.
While looking into this, I also found an example of someone using strace to see what got an EIO error.
Problem with using “hard” which I did consider is that if the share is not available for any reason during boot it will get held up and I could find no way to set a timeout for it. Maybe I’m mistaken and missing something.
Also, the mount doesn’t disappear for anything else that I can detect, only Duplicati seems to complain and there is nothing in the main system logs that I can find, which makes it all the more mysterious.
So I noticed that like the other Linux backups this one takes some files from the same NFS share and then adds them to the Duplicati backup. The difference being that the other machines just saves a few KB of data whereas this one with the issue it’s a few GBs. So I rethought that and made sure all the data to back up was on the machine itself and then gets transferred to the NFS share by Duplicati.
The usual happened, the next manual backup was fine, the subsequent scheduled one failed - well at least it’s a lot faster now.
So I have gone ahead and added the umount/mount of the NFS share to the start backup script, tested and now wait to see how the scheduled ones go.