This would just create smaller zip files. In your case I think you’re using a 250MB dblock / Upload volume size. Since Duplicati defaults to queuing up 4 of those files for upload you’d be using about 1TB of temp space.
Changing to a smaller size is just an easy way to see if things start working again (suggesting it’s s temp space issue). It won’t do anything to already backed up data - those files will still stay at the old setting (250MB in your case) UNTIL they get cleaned up as part of the normal compacting process (assuming you’re not using “Keep all versions”). That’s the process that finds small or partially used zip files and re-compresses them into new full-sized / fully utilized ones (then deletes the old ones).
You can safely changing dblock size pretty much any time you want.
This could be caused by things including:
a side effect of whatever is causing the “Previous volume not finished” issue (that’s my guess)
an intermittent communications issue causing the wrong size to be stored in the database
a destination bug such that the size was incorrectly reported
a destination timing issue such that Duplicati requested the file size BEFORE the file was done being written by the destination (since the file couldn’t be opened to get the size, 0 is returned)
an actual bug in the Duplicati SQL (though this is unlikely as it would probably appear much more frequently)
If you have the space, I’d suggest testing a new backup before nuking the old one. Even though you’re having issues adding to the existing backup it should still be able to be used for restoring purposes.
I’m going to flag @kenkendk and @Pectojin here just in case they have any input because I know this has been an open (but infrequent) issue for a while now and even if we can’t pinpoint the cause, having a method of resolving it would be nice.
