means that Database screen should show the same thing. That’s your dbpath.
Deleting the dbpath from Commandline screen or CLI will assign one based on
target URL, and record assign in a dbconfig.json file in its user’s profile area.
If a DB assignment already exists, it continues to be used, providing continuity.
Assignment does not create the DB, but an operation, e.g. a backup, may do it.
If UserName is SYSTEM on Windows, your dbconfig.json will be in the folder C:\WINDOWS\system32\config\systemprofile\AppData\Local\Duplicati
but you will need to run with Admin privileges to know what files are in the folder.
For example, you can have Start menu find cmd.exe then run it as administrator.
but this is a mess: the first entry is a backup test I created some times ago in order to use it like “sandbox” for some tests. Today I delete this backup job.
In addition I have a dbconfig file in
C:\Program Files\Duplicati 2\Data\
According to other test I perform any time I launch purge command (I suppose any time I launch any command: purge,delete…) C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati\dbconfig.json is create or updated with an entry related to the db which one use the command line. If the entry is yet here the command use related data (and I have wrong data - probabily an heritage, when I install duplicati for my first time.
In my head I suppose duplicati command line use data stored in Duplicati-server.sqlite…
Now my question is: it’s possible to modify the path when duplicati.commandline.exe store the dbconfig.json file? I wish save it NOT in ```
C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati
I’m not sure how you migrated to a service install but it seems like a step may have been missed, I’ll address this in a minute.
For now the dbconfig.json. The dbconfig.json gets created in the current users local app data folder, so in my case "C:\Users\Jimbo\AppData\Local\Duplicati". FYI: None of the database entries in the dbconfig.json file I have match up to any of the database names I currently have.
I don’t know what the dbconfig.json does but I’m pretty confident you don’t need to worry about it either.
My databases are held in "C:\ProgramData\Duplicati\Data" which contains three databases (I only have 3 jobs setup), EBTCIBJAKH.sqlite, MFSTBPUEDJ.sqlite and UEVBRQUEKO.sqlite which matches up to the WebGUI when I select a backup job and click on “Database…” I see the same database name.
As for Duplicati being setup to run as a service in Windows, I would suggest trying to follow this guide. If everything goes as planed your databases will then be located in "C:\ProgramData\Duplicati\Data" and if you check your services you should have a Duplicati service running and the “Path to executable” in that services properties should read "C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe" "--server-datafolder=C:\programdata\Duplicati\Data"
The "C:\Windows\System32\Config\SystemProfile\AppData\Local\Duplicati" folder should have been removed when you migrated to a service install. Also I have a post a further down in that thread explaining to add the --no-hosted-server option to all of the shortcuts that launch Duplicati along with adjusting the source selections so they are system based and not user based.
Once you know for sure what databases you’re using things should be much easier to diagnose. Let me know if you have any questions.
I perform another service installation. all work fine but duplicati command line still create dbconfig.json in C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati when I run commands from web_ui command line.
Without that switch, Duplicati will be running as the tray service and will then use C:\Windows\System32\config\Systemprofile\AppData\Local\Duplicati\ as it’s path.
I don’t think dbconfig.json can know when you no longer plan to use some destination, so can’t clean up.
I see your second entry is the mysterious XHEWXHIATP.sqlite. That’s probably from not supplying dbpath, thereby forcing Duplicati to invent a path for a database for SYSTEM user. If normal run mode is from GUI, never delete dbpath from either Commandline or Export As Command-line, or you won’t get to GUI’s DB.
How? Deleting in GUI will clean up GUI’s Duplicati-server.sqlite, but CLI jobs are independent of the GUI.
Where? GUI jobs have nothing to do with a dbconfig.json which only apply to CLI or CLI in Commandline.
Only if dbpath is NOT given is this file used, as far as I know. If absolutely necessary, I can test that some.
What you should do is NOT delete dbpath, then it will never need to be saved anywhere. You had written:
and by leaving the dbpath that GUI gave you, you avoid having anything to do with that dbconfig.json file.
I dusted off an old service installation to verify it only does this if I delete dbpath. Don’t do that, and it works.
Delete needed information, and it gets a new pathname for database, but it’s not there yet. Test command:
Running commandline entry
Finished!
ErrorID: DatabaseDoesNotExist
Database file does not exist: C:\Windows\system32\config\systemprofile\AppData\Local\Duplicati\OneDrive test.sqlite
Return code: 100
Folder before and after failing run:
C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati>dir
Volume in drive C has no label.
Volume Serial Number is E471-3EE4
Directory of C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati
12/03/2022 10:19 AM <DIR> .
12/03/2022 10:19 AM <DIR> ..
12/03/2022 10:17 AM <DIR> control_dir_v2
12/03/2022 10:18 AM 57,344 Duplicati-server.sqlite
12/03/2022 10:19 AM 204,800 RDHUQJBGHZ.sqlite
2 File(s) 262,144 bytes
3 Dir(s) 57,438,646,272 bytes free
C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati>dir
Volume in drive C has no label.
Volume Serial Number is E471-3EE4
Directory of C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati
12/03/2022 10:21 AM <DIR> .
12/03/2022 10:21 AM <DIR> ..
12/03/2022 10:17 AM <DIR> control_dir_v2
12/03/2022 10:21 AM 315 dbconfig.json
12/03/2022 10:18 AM 57,344 Duplicati-server.sqlite
12/03/2022 10:19 AM 204,800 RDHUQJBGHZ.sqlite
3 File(s) 262,459 bytes
3 Dir(s) 57,438,371,840 bytes free
C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati>type dbconfig.json
[
{
"Type": "ftp",
"Server": "localhost",
"Path": "OneDrive test",
"Prefix": "duplicati",
"Username": "duplicati",
"Port": -1,
"Databasepath": "C:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\\Duplicati\\OneDrive test.sqlite",
"ParameterFile": null
}
]
You can see that a proper run (without deleting dbpath) uses no dbconfig.json, but deleting dbpath makes a dbconfig.json (whose timestamp in this case was time of improper run) that contains dbpath of destination.
It might not matter. What matters is the user of the Duplicati doing the actual work, and here it’s SYSTEM. Perhaps there’s no Tray Icon anywhere. It mostly adds UI conveniences, but main UI is alway via browser.
[quote=“ts678, post:27, topic:15399, full:true”]That’s probably from not supplying dbpath, thereby forcing Duplicati to invent a path for a database for SYSTEM user.
[/quote]
I agree with you but IMHO this is a questionable behaviour. A error message like “dbpath not provided” will be more reasonable.
yes of course.
I delete it via web UI. I know very well the separion between command line tools and web UI
I have 6 jobs in web UI, and I suppose the information related to these jobs are stored in Duplicati-server.sqlite
Ok I realize this and in the future I pay more attention but I suprise the behavior of duplicati: If a bad dbpath passed by options duplicati should return an error, not stuck for 40 minutes - the first time I run purge command I accidentally refresh the browser so the form with output of command line disappear.
I suppose my dbconfig.json was created when I try to play with duplicati 2 or 3 years ago
It’s not technically an error. Especially for true CLI, it’s a completely proper way to do things.
GUI perhaps merits a warning, but there’s lots of other essential stuff one could also delete.
Picking CLI options is just tough, which is why starting with Export As Command-line helps.
Maybe someday someone will write a proper purge GUI interface. It would also seem safer.
Right now there are few volunteers for most areas. The manual could also mention the risk.
Yes, that’s where job definitions and statistics which you see on the home screen are kept. Option table exists too, but here destination and DB are together, as with dbconfig.json.
Having full DBPath here is actually good to know. Moving this DB doesn’t move any job DB.
… can you re-read please.
