If you mean 14 on home screen, that’s only updated when backup completes. Might that be the issue?
Restore screen goes directly into a different (and now recreated) job database, so I would trust it more.
If you want to look at the destination and count remaining (undeleted) files with names duplicati-<date> which would also contain dlist in the name (so they’re known as dlist files), they are backup versions. That’s the maximum number of versions left, and if some of the dlist files are bad, there might be fewer.
“Simple” is fresh start. “Faster, but less simple” is trying to reattach current files to the uploaded blocks.
One thing that’s different from previous ideas such as summarized here at bottom is you already ran a Recreate, so you might already have populated the database with whatever blocks were still surviving. Possibly your download speed is faster than upload, so the big transfer you ran wasn’t quite as awful?
was from an actual run of the reattach-blocks plan. There were some miscues in the action above that.
For your case, we’re trying to invent a variation which might start with setting no-auto-compact to make sure that doesn’t run and discard our blocks (and hope it hasn’t already…), then solve the dlist mystery.
If you truly only have one destination dlist file, its name should match the Restore date except it’s UTC. Download the file for backup, and because it may be used later Then set allow-full-removal so you can delete the version on the Restore dropdown. You said there’s one. The number on the left should be 0.
Use the delete command in GUI Commandline to delete --version=0 (set Commandline arguments).
You should now have a database of a bunch of old blocks, with no source files recorded as using them.
I’m not sure if we’ll need the empty dummy dlist file, because your Recreate had an actual one, so just running a backup might look at its old blocks and reattach what it needs. If this plan is simple enough, I could probably test some. Unknowns include whether remaining wasted (unused) blocks at destination would get cleaned up eventually, and whether lost dindex files will ever come back. I suspect they don’t which would mean your next Recreate or Restoring files if your Duplicati installation is lost may be slow.
If this has appeal, I can test it more, but there are other things that might be “off” due to current damage.
Fresh start is definitely a more certain process, and if you like you might be able to do it in chosen folder order at first, so that it goes in small increments with the most important folders first. GUI can deselect a folder that is currently selected by clicking on it. Sometime later, you can undo it to get folder backed up.