Directory of C:\Users
12/07/2019 04:30 AM <SYMLINKD> All Users [C:\ProgramData]
12/07/2019 04:30 AM <JUNCTION> Default User [C:\Users\Default]
which explains why “All Users” looks like “ProgramData”. But what used “Data” subfolder?
It looks almost like old runs had --server-datafolder or DUPLICATI_HOME set to that.
--server-datafolder
Duplicati needs to store a small database with all settings. Use this option to choose where the settings are stored. This option can also be set with the environment variable DUPLICATI_HOME.
What’s the significance of 01:19 AM, which is time on a job database and server database?
If that is the time of a run from 2.0.7.103, then that solidifies the idea of that being the folder.
You could try a manual copy of C:\ProgramData\Duplicati\Data\Duplicati-server.sqlite to be safer, and see if service install with --server-datafolder=C:\ProgramData\Duplicati\Data helps.
DB Browser for SQLite can sometimes look in database, if you like. Old server DB defaults to an encryption of Duplicati-server.sqlite that it can’t read, but that means you found an old server DB.
Job database (the bigger ones with the random names) can be opened, e.g. to Browse Data to LogData table where you can read the actual job logs instead of just some timestamps on files…
Another method is to make a dummy Duplicati job and point its Database screen to a copy of file.
This is only for looking at logs (assuming you know history of backups) to see if this was your job.
Copied the C:\ProgramData\Duplicati\Data
cd C:\Program Files\Duplicati 2
stopped the service using service manager
Duplicati.WindowsService.exe uninstall
Duplicati.WindowsService.exe install --server-datafolder=C:\ProgramData\Duplicati\Data
started the service using service manager
And now my backup job is present!
Status:
The localhost:8200 instance is accepting my password
it is running Duplicati - 2.0.9.108_canary_2024-10-03
it is saying Update 2.0.7.103 is available.
Next steps?
Sometime I will need to try a backup to confirm it is working. If I don’t take any action, this will happen at 1am EST
If this isn’t the proper location for the database I am happy to move it.
At some point I would like it to understand that old updates are not available
I noticed that somewhere along the line I had set an option to force SSL3 - I changed that back to System Default
saved
Everything else look fine.
Verify Files
No database encryption key was found. The database will be stored
unencrypted. Supply an encryption key via the environment variable
SETTINGS_ENCRYPTION_KEY or disable database encryption with the option
--disable-db-encryption
yet the verify succeeded!
Tried again - it still shows the old update.
While everything looks good at this point, I am going to turn tonight’s backup off pending any comments and/or suggested actions.
SSL 3 has been deprecated for nine years due to an attack found ten years ago. Why force it?
The notice is informational on database use and has nothing to do with the result of verification.
Current situation with encryption is in flux since encryption for each specific computer hit snags.
Maybe the developer will comment, as the shown workaround looks a little awkward to me, and maybe even less safe than it was before, when Windows DB had a default key for its protection.
--server-encryption-key
This option sets the encryption key used to scramble the local settings database. This option can also be set with the environment variable DUPLICATI_DB_KEY. Use the option --unencrypted-database to disable the database scrambling.
It would have been set a while back to work around a problem (and might not have been needed even there). Long enough ago that I don’t even remember setting it.
So for now I ignore the message about database encryption. I probably only saw it because I was watching the live log in verbose mode.
And I ignore the update message. Or should I rename the “updates” folder now that we are on the correct version?
cd "C:\Program Files\Duplicati 2"
stop the service using Service Manager
Duplicati.WindowsService.exe uninstall
Duplicati.WindowsService.exe install --server-datafolder=C:\ProgramData\Duplicati\Data
start the service using Service Manager
Note that the path is where my database was located. Other systems may have it in a different location.
At one point Duplicati was not accepting the password I had set prior to the upgrade. This was corrected by:
cd "C:\Program Files\Duplicati 2"
Duplicati.CommandLine.ServerUtil.exe change-password --server-datafolder "C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati"
However, this may have been when Duplicati was using the wrong database.
Renamed C:\ProgramData\Duplicati\Data\updates
This corrected the problem where it was offerring a down-rev “upgrade”.
Since the root of the issue seems to have been the database for the system service being located somewhere where the upgrade process wasn’t expecting, should I move it to the expected location? I.e., if I am understanding things, I would move the contents of C:\ProgramData\Duplicati\Data to
C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati ?
The Duplicati-server.sqlite database contains paths to job databases, but those can be moved.
I tried to survey (in Google) whether Windows 11 does the same annoying deletion of this area. Result leans towards “it’s fixed” but aren’t conclusive. Old forum posts were worrying about this:
Duplicati cannot be secure when the attacker is its own OS that comes along to delete its config. Exporting a backup job configuration and keeping it in a safe and secure place would add safety.