This is a very small backup set (about 120 MB). Here is the commandline and the results:
mono /usr/lib/duplicati/Duplicati.CommandLine.exe restore file:///media/nc-data/e/db C:\ProgramData\Duplicati\data\YHNDBKYESM.sqlite --passphrase=xx --restore-path=/media/nc-data/e/db
Restore started at 2/6/2021 11:21:44 PM
Listing remote folder …
Downloading file (1021 bytes) …
Downloading file (45.01 KB) …
Downloading file (65.18 KB) …
Checking remote backup …
Listing remote folder …
Checking existing target files …
Scanning local files for needed data …
Verifying restored files …
Restore completed without errors but no files were restored
Restored 0 (0 bytes) files to /media/nc-data/e/db
Duration of restore: 00:00:00
and yes I’m trying to restore and unrelated DB
I’ve tried various iterations of this, plus trying the find command. No errors are thrown in any of these cases, but no files or lists are returned either. (A ‘list’ command shows just one fileset numbered 0).
There is no dbpath - my understanding is that for restores, all you need is the URL (local in this case) and the files (including wildcards) you want to restore.
I feel like this should be an easy solution - but I’ve been staring at it for so long, I’m sure I just need another set of eyes looking at it.
Some of this looks like bugs. Cross-OS (backup on Windows, restore on Linux) might not be done much.
I’ve led people through the GUI. Trick is to use Pick location, because Original location doesn’t fit.
Your restore-path seems the CLI equivalent. Restoring a DB to backup folder is unusual but might be OK.
Got a link? This surprised me, but seems to sort of work. It might be recreating a local database for you in
My usual advice for trying to match a GUI job in true CLI is to edit from an Export As Command-line which will use the same DB and options (and help to avoid some quoting problems, or omitted relevant options).
This gets deeper than I can go. I don’t know if any current developers know the area well, but you can try.
How about filing an issue with full steps? This one seems easy compared to the Nextcloud strangeness.
My guess at giant “HUH”? is below. I guess adding ‘*’ anywhere (even end works) switches to Wildcard.
which then switches code below
where a profiling log in the wildcard case does the expected replacement of my what’s-the-point * to %.
2021-02-08 21:07:16 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: INSERT INTO “Filenames-8CEC364060063A4B87C668B2A9BA88FE” SELECT DISTINCT “Path” FROM “File” WHERE “Path” LIKE “C:\Program Files\AESCrypt\aescrypt.exe%”
Without the *, I get a substitution that I can’t track down, but weirdness at start may explain the non-find.
2021-02-08 21:04:15 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: INSERT INTO “Filenames-2CC2F50D7E4D654AAFDE2B387080CD44” SELECT DISTINCT “Path” FROM “File” WHERE “Path” LIKE “%/C:\Program Files\AESCrypt\aescrypt.exe”
A percent symbol ("%") in the LIKE pattern matches any sequence of zero or more characters in the string.
which is what a ‘*’ often means (thus the replacement with ‘%’), but why is it added, and what’s with ‘/’?
Windows running a find without the cross-platform complication didn’t even pattern-match. I think it did
2021-02-08 22:11:06 -05 - [Profiling-Timer.Begin-Duplicati.Library.Main.Database.ExtensionMethods-ExecuteNonQuery]: Starting - ExecuteNonQuery: INSERT INTO “Filenames-8C5EFEF21748C747A1F886925DB155E8” SELECT DISTINCT “Path” FROM “File” WHERE “Path” = “C:\Program Files\AESCrypt”
but I think a developer on Linux with at least the right tools and ideally right knowledge should investigate.
Can you write a good step-by-step that such a developer can do, and get it in the line as a GitHub issue?
I completely agree that trying to force the square-peg-of-windows command parsing into the round-hole-of-linux may be a fool’s errand and I’m sure that in some bash manual I’ve long ago forgotten about, these differences were explained. But I’ll see what I can piece together and submit to github issues.
This whole exercise has been trying to do a full verify from my local server, rather than over the network. I have it mostly figured out.
When the ‘test’ command goes and grabs a random database: I think I’ve tracked that back to when I first started using duplicati and was NOT using the server install. When I transitioned over to server with the help of some excellent articles (Migrating from User to Service install on Windows)
the database moved from c:\users\xyz\appdata\local\duplicati\ to \programdata\duplicati\data
However, what got left behind was the duplicati-server.sqlite in the old appdata location. For some reason the ‘test’ CLI command accesses that old location for a dbpath (maybe the default built-in to the code?), hence the error. Running ‘test’ from the GUI does not make the same mistake.
How did this divert to the ‘test’ command? There were many pieces above, but I don’t see that one there.
From CLI, the ‘test’ command (and probably any command) allocates a per-destination database for you.
The database for a given destination URL is noted in the dbconfig.json file, which can be edited if needed.
The true CLI (as opposed to GUI Commandline) is independent from the server, and should match server options, e.g. by using Export As Command-line as described earlier, unless CLI goal is to be independent.
The CLI DB path, while set and remembered for convenience, can be overridden using –dbpath if you like.
So is there a comment on the find command and other issues? This is more than just a DB-finding thing.