that’s not very good unless you deliberately choosed to keep only one version. Something to look out for the future otherwise.
About your failing job, I’d say that using the command line for restoring is very underrated in comparison to the rather awkward UI.
I have tried it today and I find it vastly easier to handle.
And for the most important task you have to do with a backup, it’s certainly worth it to test it to get the syntax right on some paper saved in a safe place, available when you have a problem and you need to start the restore immediately without having to search memory and/or documentation.
And using the command line makes it easy to test the restore to an alternate path so you can check your backups without having to do any copy to another computer (provided the disk space is enough but it’s often doable to add an USB hard drive), given that there are sadly some limits in the current state of Duplicati to the usability of auto tests.
a few examples (the options order seems to matter)
mono Duplicati.CommandLine.exe restore "ssh://ftp.example.com:822//files/test1?auth-username=test&auth-password=xyz" --passphrase=badsecret --restore-path=/home/gp/testAAA --ssh-accept-any-fingerprints
mono Duplicati.CommandLine.exe restore "ssh://ftp.example.com:822//files/test2?auth-username=test&auth-password=xyz" --restore-path=/home/gp/testBBB --no-encryption=true --ssh-accept-any-fingerprints
the cherry on the cake IMO is that you can easily add a higher log level and see what happens in real time without having to guess.
mono Duplicati.CommandLine.exe restore --log-level=verbose "ssh://ftp.example.com:822//files/test2?auth-username=test&auth-password=xyz" --no-encryption=true --restore-path=/home/gp/testBBB --ssh-accept-any-fingerprints
to check that a restore succeeds or not in the same conditions than a recovery backup, it’s needed to stop Duplicati to scan for data in the local directories.
If not, when there is an error in a remote file, it will be displayed by the commands given above, BUT the concerned files will not be displayed and will in fact be ‘magically’ restored. A way could be to rename or move the concerned files, but it is assuming they are known, and it may be very annoying to manage.
A better option is to add the --no-local-blocks=true flag and then the failed files will be displayed to explain what could be missed from a blank state restore. As there is no free lunch, the restore will be longer (in fact it will be about as fast as a real recovery from scratch)