Error: The socket has been shut down

storedlist is straightforward from record of what’s in the version. It’s shown as the expected count.
The one-less from found is computed based on what appears to be internal pieces actually available.
You might have had something go missing, but the history is missing unless you set up a profiling log.

If you can post a link to a database bug report that you store somewhere, maybe there will be clues…
Having you type in database queries that I suggest is possible, but is probably a more difficult method.

FWIW I’m backing up to Backblaze B2 just fine, but possibly your issues are due to network problems.
Export As Command-line, edit URL to an empty folder for Duplicati.CommandLine.BackendTester.exe
would be one test. Or see if any backup that works winds up with Complete log with “RetryAttempts”.
You can also try restarting any WiFi, routing, or other network equipment to see whether that will help.

Network errors that outlast number-of-retries sometimes cause issues, and some spots are more likely.
Compacting files at the backend has issues on interruption, but there may be other sensitive spots too.

The verification stops on an error. It’s the first one found. Sometimes deleting that version will help, but sometimes another version pops up as broken instead. This is because deduplication means a version shares identical blocks with other versions. It shares other things too. Versions are not full file copies… Advantage is a huge space saving. Disadvantage is that damage to shared items shares that damage.

Although SQL doesn’t guarantee it, I think verification is usually in increasing date. How many backups happened 5/18 and after? I’m a little concerned if this is a daily, as that means a lot of later ones at risk.