HI,
I am using a gpg encryption with public/private key. Restoring works OK from within the GUI where the backup is running. However, when doing the restore via commandline, it stops at the first file trying to download.
Anyone has an idea what is wrong with this command?
mono Duplicati.CommandLine.exe restore "remote-url" file_to_restore --passphrase="*********" --encryption-module=gpg --compression-module=zip --gpg-decryption-command=--decrypt --gpg-encryption-switches="--recipient user@host.com" --restore-path=/path/to/restore
In the log, I get the following feedback:
Rebuild database started, downloading 7 filelists
Downloading file (1.61 KB) ...
After which I receive no further feedback.
Thanks,
WIm
I don’t know about the gpg side of things, but on the Duplicati side when a restore is done it needs to know which archives contain the blocks needed to restore the specified file_to_restore.
When running from the GUI Duplicati uses the --dbpath to read the local database to know which archives contain all the blocks for file_to_restore.
However, when running from the command line if the --dbpath parameter is not used then Duplicati must download all the dindex files one by one to rebulid the database until it’s identified all the needed archives containing the file_to_restore blocks.
So one longer-than-necessary explanation later, try adding the --dbpath=\<path to your job's database file> parameter to your mono Duplicati.CommandLine.exe restore command line. 
Thanks @JonMikelV. However, I want to try to restore without the db… That is possible but isn’t working for some reason.
Ah, I didn’t realize that.
From what I see you’re doing everything correctly…my guess is it’s taking a long time to rebuild the database enough for the restore. Do you have an overly large dblock (“Upload volume size”) setting?
You might also try adding parameters such as:
--verbose=true (shows more status info)--log-level=profiling (shows process details)--log-file=\<path> (writes everything to a file at <path>)
Since you have it working via the GUI and are trying the command line anyway am I correct in assuming you’re trying to automate some sort of test restore?
Profiling was already active. Will see what the verbose gives.
I’m just testing the restore without db in case I need it. Don’t understand why it stalls… Nothing more. No automation.
In that case you might be interested in some of the parameters below as well. 
Unfortunately, I also don’t know why it stalls. I suspect it’s just being REALLY slow, but am not sure how to confirm or disprove that guess.
--full-result (default: false)
Use this option to increase the amount of output generated as the result of the operation, including all filenames.
--no-local-blocks (default: false)
Duplicati will attempt to use data from source files to minimize the amount of downloaded data. Use this option to skip this optimization and only use remote data.
--no-local-db (default: false)
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
--patch-with-local-blocks (default: false)
Enable this option to look into other files on this machine to find existing blocks. This is a fairly slow operation but can limit the size of downloads.
Strange it works OK on a different client. Will try on the other client later this weekend.
probably related to gpg version… When running on windows & gpg2, and explicitly referring to the gpg program path, there was a gpg pop-up to unlock the private key. I believe my gpg version on synology is v1.
Probably something similar on the linux client (ubuntu on windows) - need to check further…
But, no duplicati issue as far as I can tell…
Good detective work! Looking forward to more checking results… 