Welcome to the forum @Coises
Ordinarily missing file checks are frequent and rely on database records. In the case you are testing, you have none because you have left regular database on the original system (e.g. testing disaster recovery).
Error messages in the ordinary case are quite explicit when destination files do not match database data.
It looks like that’s the case. The first download is to populate the restore selector with specific information about what backup versions were found, including whether they are full or partial (stopped early) backups.
The second set of downloads announces itself (I believe) as building a partial temporary database, which only gets used for that particular direct restore. For a full restore, the bulk of the download will be blocks in dblock files. It is best to make a “direct restore” worth the setup overhead (mostly in dlist and dindex files).
Other ways to reduce setup time include keeping versions trimmed with a suitable retention option, which can even “thin” out versions as they age. For larger backups (maybe above 100 GB), consider raising the blocksize to reduce the amount of block tracking that is done. Rough target limit might be 1 million blocks. Unfortunately it’s not possible to change blocksize on an existing backup. A fresh start would be required.
number-of-retries and retry-delay can help survive short drops in ordinary backups, but “direct restore” is more work to set up because it’s based on manual entry of information, and there’s not a nice option GUI. Many things that one might put on backup (e.g. blocksize) are gotten automatically, but retry config is not.
Regardless, safely saving an Export of the backup configuration will ease restoring config in DR scenario.