The clean affected run adds confidence that there are just some extra dindex files citing useless dblocks. Although I think that’s fairly reliable, more certainty could be achieved by browsing DB or supplying report.
The backup databases don’t have any recent dates, so there probably isn’t a relevant database any more.
Remote backup task quit working : constraint failed UNIQUE constraint failed: Remotevolume.Name, Remotevolume.State was the most recent chase for that, aided by a database bug report. With logs and database gone here, such an investigation can’t be attempted, but even the other one wasn’t very certain.
What type of Destination is this? Some have duplicate-filename capabilities that permit special problems.
The rename error likely followed an upload error. The retry gets a new name, but a conflict isn’t expected.
Sockets are a network connection. Networks glitch, and retry is needed. This error worries me the least.
Retries of uploads and downloads are also kind of expected, and tolerated unless they get too extensive.
You got one on the DB recreate. The default number-of-retries is 5, but it and other things are adjustable.
You seem to be 2 hours ahead of UTC. A dlist time uses UTC. The rename error had 20221005T060230 meaning 8:02 AM on Oct 5, 2022 after time zone adjustment. If there’s still a backup there, it might merit special attention. Regardless, if you keep using the backup, be sure to run at least some Restore testing.
Do you know how much storage your backup takes? DB recreate downloaded 870701977 bytes, which (unless you have a very small backup) might just be dlist and dindex files. Dblock download is a bad sign
which happens from 70% to 100% on the progress bar. About → Show log → Live → Retry also shows.
Verbose level says even more. The dblock searching is seeking data blocks that weren’t in any index file.