What's the best upgrade path for duplicati 2.2.0.3_stable to 2.3.0.4_stable running as Win\service as SYSTEM?

Support
1

Hello, running Duplicati as windows service on Windows 11 Pro machines with this install command:

.\Duplicati.WindowsService.exe install-only --server-datafolder="C:\ProgramData\Duplicati\database" --webservice-interface="{ip}" --webservice-sslcertificatefile="C:\ProgramData\Duplicati\Cert4Duplicati.pfx" --webservice-sslcertificatepassword="{pfw.pw}" --webservice-allowed-hostnames="backup.example.com;{machine}.{tailnet-domain}" --log-file="C:\ProgramData\Duplicati\logs.txt" --log-level=Error --windows-eventlog=true --windows-eventlog-level=Information

The back-up service needed to be working without the user logging into their account, hence using the windows service installation path. Also, Duplicati needed to backup folders of different windows users crossing the single user context, hence going with SYSTEM. This was set-up in the duplicati 1.x days years ago.

In the newer duplicati versions, I gathered that automatic database encryption will be applied and - in this case - stored in the SYSTEM’s windows credential manager. It seems very hard for an admin user to retrieve the credential saved by the SYSTEM as there is no normal interface access.

If the database is encrypted, I would like to backup the secret.

What would be the recommended upgrade path going forward in this situation? (xOR)

  1. Should I just add the -disable-db-encryption=true to the service’s launch command?
  2. Should I create a special windows user with admin rights and update all related folder’s security setting to allow the read/write operations required for backup, then log into that account as windows user and extract the password from its Windows credential manager and save it as backup?
  3. Should I change topology and pick a main user, and run the service under their account and simply update folders rights across user account boundaries? (Though frowned upon years ago, nowadays machines in this context have become less shared and perception might have changed, so perhaps it has become acceptable.)
  4. {Other existing upgrade paths.}
  • Please let me know how you would handle this. (Not limited to options 1 to 3.)
  • Please warn me if there are other changes since 2.2.0.3 that require attention and threaten duplicati uptime. (FYI: Backup are saved to other hard drive and synced by other tool.)
2

Yes, that part is a bit of a pain. No standard tools will allow you to read the value. You can use something like psexec to run as SYSTEM and then use a custom powershell or similar to show the value.

You can certainly do this. It will essentially revert back to the way Duplicati has been working so far. The downside is that the credentials in the database will be stored in plain on the disk.

If you can use something like psexec or the “scheduled task” method, you can run a command as the SYSTEM user. You can use this to pre-seed the WCM with your chosen encryption key. If the key is already present, Duplicati will just use it and not generate a new key.

For psexec it looks like this:

psexec.exe -s "C:\Program Files\Duplicati 2\Duplicati.CommandLine.SecretTool.exe" wincred:// set duplicati-server-encryption-key

The scheduled task way is a bit more involved:

# 1. Create the task to run as SYSTEM
schtasks /create /tn "TempDuplicatiKeyTask" /tr "\"C:\Program Files\Duplicati 2\Duplicati.CommandLine.SecretTool.exe\" wincred:// set duplicati-server-encryption-key <key>" /sc ONCE /st 00:00 /ru "NT AUTHORITY\SYSTEM" /f

# 2. Execute the task immediately
schtasks /run /tn "TempDuplicatiKeyTask"

# 3. Delete the single-use task
schtasks /delete /tn "TempDuplicatiKeyTask" /f

To check if the database is encrypted, go to “About Duplicati” → “Server settings”, and then look for:

"encrypted-fields": "False",

Where “False” indicates no encryption and “True” indicates the database is encrypted.

If your database was encrypted before you managed to set a known encryption key, you can do the following:

  1. Start with --disable-db-encryption-true
  2. Verify that "encrypted-fields": "False" is in server settings (important!)
  3. Run commands similar to the above but include --overwrite to replace the value
  4. Restart without --disable-db-encryption=true
  5. Verify that "encrypted-fields": "True" is in server settings

The reason step 2 is important is that step 3 will wipe the encryption key, and after this there is no way to get it back, and it is not possible to get a backup of the value.

I think going forward we should add a “change-database-encryption-key” command to the WindowsService tool, such that it is simpler to rotate the key to a known value.