Unable to restore with no-local-db set

I’m trying to do a full restore to validate my backup since I’m getting verification errors when backing up to my NAS using sftp.

The description of the no-local-db option says: “When listing contents or when restoring files, the local database can be skipped. This is usually slower, but can be used to verify the actual contents of the remote store.”

This seems to indicate that I should be able to do a restore with this option set, albeit slower than if I were to use the local db.

Since I want to verify the integrity of my backup as much as possible, I’m trying to restore with both no-local-db and no-local-blocks set.

When I try to run the restore, I get a dialog box stating “Failed to fetch path information: Listing prefixes is not supported without a local database, consider using the “repair” option to rebuild the database.” Additionally, I get a red error message stating “Listing prefixes is not supported without a local database, consider using the “repair” option to rebuild the database.”

Is this a bug, or is it a sign that my backup data is broken? If it’s a bug, does anyone know if it’s recent, such that I can run my test with an not too much older version, or has this been hanging around for a while?

Thanks in advance for your assistance.

Might be old bug with no prior reports. You can file an issue with steps to reproduce if you want it tracked.

On 2.0.4.22 canary and 2.0.4.5 beta, turning on those options on the Advanced options screen of the job, Restore button gives me error instead of the tree view I want on “Select files” screen. Is this your usage?

One of the restore paths that seems to do what you want is direct restore with --no-local-blocks manually typed in on the second screen (Encryption) Advanced options section. You can see it displaying “Creating partial temporary database” so I don’t think the usual database is accessed. You can move it to be certain.

Turning on logging (or maybe using live log) at verbose level should confirm that you’re using remote data:

2019-08-20 09:23:49 -04 - [Verbose-Duplicati.Library.Main.Operation.RestoreHandler-PatchingFile]: Patching file with remote data: c:\restore here\length1.txt

as opposed to

2019-08-20 09:19:01 -04 - [Verbose-Duplicati.Library.Main.Operation.RestoreHandler-FilePatchedWithLocal]: Target file is patched with some local data: c:\restore here\length1.txt

which is what happens if you put the option on screen 1 instead of screen 2. The UI here could use work.