My guess is it’s more likely a destination path issue than a timeout as timeouts usually through a timeout error.
I’d suggest double checking that your destination path correctly aligns with where your WebDAV connection is dropping you.
Note that there has been some discussion of large file list issues including this one that talks about a POTENTIAL subfolder system to better support many destination files:
Until something like that makes it into the codebase some things you could consider include:
-
use a larger
--dblock-size. For example the default is 50MB is if you only doubled it to 100MB you’d HALF the destination files (at the expense of more time/bandwidth consumed during the post-backup validation stage). Note that change in dblock size of an existing backup will only apply to NEW archive files - it won’t affect the old sized files until they become ready for “cleanup”, so in your current situation you’d have to start fresh to get this benefit -
break your source up into multiple jobs each with it’s own destination. You’d lose a bit of deduplication benefit and you’d probably have to bring your USB drive back local to implement the change, but you wouldn’t lose any of your existing history. Here’s a topic about somebody else to did this