Having Duplicati back up its own databases is tricky because they can be either locked (which –snapshot-policy can help) or not yet done (which --snapshot-policy can’t fix but having jobs back each other up can).
The SYSTEM profile is a bit more secure against users (but not Microsoft). It protects Duplicati better (the passwords, for example), but my databases are under ProgramData, with Security set to my liking (open)
Migrating from User to Service install on Windows is my input to a similar discussion to change the default rather than have Duplicati get wiped away twice a year. I’m not sure if it’s controversial, or just not yet done.
This isn’t a “fix” of course (remember, this is working as designed so it’s not a bug) but one option would be to use portable mode.
--portable-mode
Activates portable mode where the database is placed below the program executable.
And of course specifying the database folders would probably get the same result:
--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.
Note that while I’ve used these in the past I didn’t verify it resulted in nothing going to the system folder so YMMV.
I completely agree - and there’s nothing to say Microsoft won’t go and start fiddling with ProgramData in their next release so it’s definitely worth addressing if possible.
I guess I was just trying to point out that a “oh,b it’s not supposed to do that” bug is likely to get higher priority than a “that’s s known side effect of our design choice” issue.
I know there’s a long discussion about this elsewhere (night even be the link you provided) that had some reasons for not using ProgramData. Though if I recall correctly they were painful than this issue happening now.
I assume Linux based installs don’t run into a similar issue because Duplicati is running on a sensibly designed OS.
Is this fixed in newer versions of duplicati?
I see @kees-z is saying this is a Microsoft problem and they should fix it, but this problem still happens when windows updates in 2020.
Duplicati’s behavior has not changed yet. The recommendation for now is to make sure you store your data outside of C:\Windows if you opt to run as a service tied to the LocalSystem account.
A future version of Duplicati should hopefully default somewhere else, probably C:\ProgramData.
For the time being, you can avoid this by supplying --portable-mode to Duplicati.Server.exe or Duplicati.WindowsService.exe. This will store all data (job definitions, local databases) outside the LocalSystem profile folder. A subfolder data of the Duplicati program folder is used instead, leaving the Windows folder untouched.
We can work around this. In most cases, including in particular when Duplicati runs as SYSTEM, it can configure custom directory permissions. For example, it can change permissions such that ordinary users cannot access its directory. Microsoft SQL Server does this to prevent users from accessing database files directly (see File System Permissions Granted to SQL Server Per-service SIDs or Local Windows Groups).
