Duplicati.Commandline.exe B2 - unable to restore

Hi,
Restoring via graphival interface works.
The same through commandline fails:

Duplicati.CommandLine.exe restore b2://actual_bucket_name --b2-accountid "ActualMasterApplicationKeyID" --b2-applicationkey "actual_applicationKey" --restore-path "."

Firstly, it prompts for encryption password (however there is none in that case).
I can go forward replying anything for password (e.g. “-”) but than I get some errors:

ErrorID: B2MissingUserID
No "B2 Cloud Storage Account ID" given

Pls. help

Welcome to the forum @petardo

Duplicati.CommandLine.exe needs far more parameters than you gave it. Unlike the Commandline built into the web UI (which is a good place to see what sort of parameters are expected), it’s independent of things done in the web UI, except it may share the Database for the backup, so maybe pick an idle time.

Export As Command-line is the easiest way to get a backup command with all your needed parameters, then you would convert that to a restore command. Are you just testing this, do you prefer CLI, or what?

Thanks.
Actually just the --noencrypt=true option and equal sign between the further options an the parameters were missing . It’s working now.
I need the CLI primary in order to be on the safe side - preparing myself to the case if/when duplicati development stops and webserver is not available anymore.
I wonder if it is safe enough to use it in production environment. I know there has been a thread about it in the forum, but that is rather old and a new version (however still beta) has been released meanwhile. In the thread it was mentioned that there were problems with backups in case the computer has rebooted during the backup process. Is this still an issue? Should I consider using a payed sw?
I have read in the thread that CloudBerry would be an other alternative, but the free version - even the pro version - is not supporting Windows Server OS.
Any suggestion would be highly appreciated.

But it possibly it did a lot of extra downloads to build a database because it wasn’t given old –dbpath.

I’m not following that concern. The webserver is on your system, as is the CLI. All is on GitHub to get.

The risk with several backends is OAuth, which relies on a remote server, but B2 does not use OAuth.

Independent restore program was the plan for Restore without any other Duplicati code being needed, however by one report it was not working. I suspect it’s caught in the progressing Python 3 transition…

Duplicati is still possibly sensitive to OS crashes and reboots underneath it, however the new Beta will probably do better than 2.0.4.23 did. There is a fix in the upcoming Canary to improve handling of one variety of hard stop. If using the Stop button, use “Stop after current file” (new feature) not “Stop now”.

Stop now results in “Detected non-empty blocksets with no associated blocks!” #4037

There are also reports of SQLite being damaged by hard stops, but that’s not fixable in Duplicati code, and those who say to use another database haven’t given evidence that a different one will break less.

Best practice for backups that really count is generally multiple backups, done using different software. Good luck finding any paid backup whose legal terms (not their sales pitch) will promise all is perfect…

Duplicati is still Beta, is not perfect, is possibly less perfect than average paid product, but is improving. People with less critical needs may find it fine. Those being careful might use it as a secondary backup.

Don’t use it as an archiver, e.g. intentionally deleting source files to save space. Use it as backup copy. Sometimes the easy way to fix a problem is to start backup again. That’s hard if it has your one copy…

A webserver is more os dependent as command line - in my opinion.

For sure.
Thanks for reply.

Duplicati.CommandLine.RecoveryTool.exe is another one to add to command line tools collection, however it’s usually only used if GUI or Duplicati.CommandLine.exe won’t fly. It’s more forgiving…