Welcome to the forum @adamlove
The easy slow way is to just run again. Any file whose content is already correct won’t need a patch.
This should reduce the amount of downloading. What storage type is the Destination, and how fast?
There’s a nice CLI example of the download reduction on second try to the same restore folder here.
looks like it broke a file. Maybe that file had content common to all of the files that couldn’t be rebuilt.
Disaster Recovery talks about this, e.g. the affected command which you could run in Commandline.
You can also inspect duplicati-bcdf22a29adb8413fa810d73aa043f1e6.dblock.zip.aes for an unexpectedly new timestamp, check its size, try decrypt with AES Crypt or Duplicati SharpAESCrypt.
Destination dblock files contain blocks from source files. Ideally you can find a good one. Long shot?
Implementing the feature to restore any version of a single file might help with that. Not released yet.
Restoring files from a backup will let you pick any backup date to look (or search) for a file of interest.
It’s kind of awkward. Looking in a copy of the database with DB Browser for SQLite in File view can easily let you filter any Path of interest. If only one row shows up, there’s only one version of that file.
If you’re nervous about these experiments, you can do test restores into a different folder one by one.
This might take less machine time at the expense of more of your time leading the experimentation…
Probably once, but it did it on lots of files. If disk activity hurts file reading that badly, that’s a big issue.
I’m confused. Didn’t you post the list? Whether GUI or CLI, a human-driven retry attempt needs the list.
--version=<int>
Restore files from a specific backup.
If no
<filename>is specified, a list of all available backups is shown.
(version number is on the left, just like it is on the GUI Restore selector.
If entire path is specified, all available versions of the file are listed.
--all-versions=<boolean>
Searches in all backup sets, instead of just searching the latest.
actually might be a way to see which file versions had a path of interest, without looking inside the DB.
You probably wouldn’t be able to recognize actual different versions of the file, just versions that had it.
One can also use the search box to help with finding a file if it happens to be deep in a folder structure.
Most or all of the posted errors are in D:\iTunes\iTunes Media\Music though. Just open that folder.
You can try the files one at a time or check all the ones that you want to try from that particular version.