I like to run Dupicati as a service in Windows, and after having to deal with the problems that happen after a Windows feature update, I had the idea of running the service under the built-in Administrator account.
The Duplicati configuration files and database are now in “C:\Users\Administrator\AppData\Local\Duplicati” instead of “C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati”, so they don’t get moved to “C:\Windows.old” (and deleted after a month) anymore after a feature update.
The Administrator account seems to be able access the other user’s files without any problem, and the only future issue I can think of is the possibility of a future feature update disabling the built-in Administrator account (I’ve seen this before), but then the solution would be much easier.
That should work, but for security reasons disabling the built-in Administrator account is strongly recommended.
The trick I use is running Duplicati in portable mode by supplying option --portable-mode to Duplicati.Server.exe or Duplicati.WindowsService.exe. This will place all configuration files and local databases in a subfolder Data under the Duplicati program folder, leaving the Local System Profile folder unused.
I have my “localsystem” install of Duplicati storing its data under “C:\ProgramData\Duplicati” which is really where it should be (hint). Within the “systemprofile” folder I simply replace the Duplicati folder with a hardlink to the one “ProgramData”.
Whenever there’s a major Windows update all I need to do is recreate the hardlink and it’s back to as it was.
Thank you for the information, I’ll use your directions.
By the way: the cool part of watching the video for me was to find out that I can include the service options during the installation, instead of installing the service and then going to the registry editor!
Now another question that is related to moving the config and database folder to another location: when running a backup after I move this data folder I always get the following error: “Found 264 remote files that are not recorded in local storage, please run repair”. Is there a way to avoiding it?
Did you immediately disable the original backup? If you put two computers to same destination, they step on each other’s backups. Moving config and database should be noise-free, if database and destination match.
If it was truly a move, not a copy, that should have stopped the Duplicati Windows service running as SYSTEM from backing up to the same destination. If you stopped the Windows service to change its account to Administrator instead of SYSTEM, moved its configuration and database, restarted, good.
If you somehow had Duplicati started as Administrator at the same time as SYSTEM may run it, bad.
I’m not familiar with how this account runs, however for a normal account, Duplicati may run at login, possibly conflicting with a Window service running as the same user. Installing Duplicati on Windows shows what to uncheck in the installer,when planning in advance for Duplicati to be Windows service.
If you have access to the file dates at the destination, you can see if any showed up at a time not seen when looking at your job logs. Another test is to see how many versions the Restore dropdown shows.
That should equal the number of destination files with dlist in their name. Are there any extra dlist?
I stopped the Duplicati system before making the changes (before making it run under the Administrator account).
I really don’t know how to answer your other questions. But it’s not a real issue for me, I just ran repair and it worked again, and now I learned about the Windows Update issues and am going to install Duplicati service in portabe mode.