could be related to some of the temporary files from around that time, such as these:
It’s a guess what files are, but ones near 50 MiB (52428800) are likely future dblock files.
The last few may be smaller. Near end of backup, change data ends and gets collected.
There can be parallel processes early on, and a SpillCollectorProcess after those finish.
Leftover blocks are assigned to a different volume, e.g. your log logged 58634 to 58636.
Backup hangs at the end of Backup_ProcessingFiles points to code I think is doing that.
It’s too bad the live log doesn’t show seconds (unlike the log-file version) to clarify order.
For example, are the short files the leftovers being collected or results of the collection?
One thing you could do is to try opening the last few temporary files with a .zip program.
A dblock file will have small (default 100 KiB) files, each a block, and named by its hash.
How the backup process works explains these rather low-level (sorry) details I’m giving.
Another is to see if SFTP server has any logs. If not logs, files should have some dates.
Duplicati not doing retries means it’s not seeing errors, but fast flow of data is unknown.
The Duplicati log would also show data, but the server might be a nice one-stop history.
DB Browser for SQLite to look in database is an option. It’s just tables, and I’d guide you.
Creating a bug report can be done, but not in middle of backup. How do you stop these?
Ideal is easily reproducible steps that developers can dig into, but that’s often hard to get.
Was this backup always a problem, or did it start at some point. Any clues besides size?
We could attempt to work around it by changing things, but it’d be even nicer to look well.
Depends a lot on what you’re up for, but solutions are difficult without someone looking…