garethgeorge
Support running as a service on Windows
I currently use Duplicati to back up a couple of Windows servers and for a variety of reasons have been looking for a different solution. Restic seems to be a favorite in "self-hosted" online communities and Backrest appears to be a very nice UI for Restic, but while there are documented paths for installing as a service on Linux or Mac OS there does not seem to be the same for Windows, it only runs after an interactive login under whatever user profile it's installed from.
For a server that is supposed to run unattended that is a major problem, if the machine gets rebooted it's likely that no one will be logged in for some time, especially not a privileged admin user so backups simply would not run until the user account Backrest was installed under gets logged in. It is technically possible to configure Windows to automatically log in a user on boot but automatically logging in a privileged user on boot is obviously far from ideal for security reasons.
Aside from unattended servers it would also be helpful for multi-user computer use cases such as the one described here: https://github.com/garethgeorge/backrest/discussions/623
Hi, there's some discussion of this in https://github.com/garethgeorge/backrest/issues/549#issuecomment-2568330964 . At the time there were some security concerns around running as a service and possible incompatibility with some features (e.g. NAS shares mounted under specific users are unavailable to services).
The usecase e.g. with windows server you point out is interesting however. At the moment you can likely download the raw windows executable and try to configure it to launch at startup (it will download it's dependencies if needed) manually as a workaround.
One workaround for this situation could be using Task Scheduler with the option "Run whether user is logged on or not". Windows will prompt you to enter the user's password. You would also want to delete the shortcut from shell:startup to avoid duplicate Backrest instances when that user logs in interactively.
Ultimately though, there is no way around having Backrest run as a service if the desire is to back up data from other users' directories. The Task Scheduler approach is more of a hack/workaround.
The security concerns I raised previously are inherent to any web-based software running with admin/root privileges whether it's Windows or Linux. Backrest by default listens on 127.0.0.1 which limits exposure just to local users. It also provides a way to protect the Web UI with a password. I think this is the best one can get for a web-based application. On that note, running non-elevated as a regular user still exposes user's files to other local users if Web UI is not protected. It's just the nature of local network ports being accessible to all local users.
Not that Backrest needs to replicate other software behavior, but since Duplicati was mentioned here, I will just say it is in exactly the same boat. It does provide an option to install as service that runs elevated as Local System account, and the documentation recommends to protect the Web UI. See https://docs.duplicati.com/community-docs/community-docs-installation
I found it interesting that it uses a separate binary agent that runs as a service and controls the main binary: https://docs.duplicati.com/duplicati-programs/service. Maybe Backrest could have the same approach without cluttering the main executable code. It would be similar to what it already does with the Windows-specific systray executable. Effectively, it's the same approach as using a service wrapper, and if going down that path, maybe it's easier just to use a prebuilt solution - unless writing something like this in Go is easy enough. I listed a few third-party options in https://github.com/garethgeorge/backrest/issues/549#issuecomment-2567960637 and came to conclusion that https://github.com/birkett/srvany-ng might be the best fit. Since the last post I also found a similar project https://github.com/namecoin/winsvcwrap.
From the security point of view, probably the best that could be done is around these things:
- Add a warning in the installer when users selects service installation type.
- Add a warning in the Web UI initial setup page, urging to set up a password and explain the risks in not having one.
- Use either a custom or a trusted (from AV perspective) stable third-party service wrapper. Or add support for Windows service mode to the main binary.
I'm willing to work on the Windows installer to add this support when you decide on the service approach.
Hi, there's some discussion of this in #549 (comment) . At the time there were some security concerns around running as a service and possible incompatibility with some features (e.g. NAS shares mounted under specific users are unavailable to services).
As far as security goes I more or less agree with @homandr that the same concerns apply to anything privileged that does the "local web UI" thing and that putting a warning in the installer if installation as a service is requested and maybe making authentication mandatory instead of optional when running as a service would be good ideas.
I would also note that the same concerns of who can access the web interface apply to Linux or Mac installations as a service, or even user-level installs on shared computers where multiple users might be trading off access and leaving their accounts logged in but "locked" in the background.
As for the user-level drive mounts, I think most people who would prefer a service installation either don't care about being able to access user-level mounts or know enough to understand why a service not running as that user wouldn't see those mounts. It's not like the Windows UAC situation where an elevated application that the user still sees as running as "them" suddenly can't see mounts that other applications on the same desktop see.
For what it's worth, the way Duplicati deals with this is to support both modes running at the same time. Even if it's installed as a service, it still can also be run as a user at the same time with independent settings. The service starts first so it grabs the default port and then any instances launched after that count up by 100 each time. Their helper app that handles the desktop icon and systray widget automagically deals with this so the user doesn't need to think about it. Each user instance is independent of the others and of the service. I don't see any obvious reason Backrest couldn't do the same thing and allow users to manage their own backups with their own mounts in their own instance while a system service instance lives in the background dealing with data that doesn't belong to a particular user.
The usecase e.g. with windows server you point out is interesting however. At the moment you can likely download the raw windows executable and try to configure it to launch at startup (it will download it's dependencies if needed) manually as a workaround.
The trick without being a service is making that unattended launch at startup work without saving privileged credentials somewhere. Both Task Scheduler's "run whether user is logged on or not" and the classic "enable auto-login at boot and then auto-lock" hack require the user's credentials be saved on the system somewhere that they could potentially be retrieved by malware or a malicious user.
I'm going to give srvany-ng a shot and see how it does for now, it seems like it'd solve my "make it run on boot without saving creds" problem without much effort.
I was able to set and run Backrest as local admin account service using third party tool called NSSM, tested with version 2.24 (a bit old release version), cause featured pre-relese version 2.24-101 had issues with antivirus software that I had on my computer. Everything works just fine on Windows 10, but on Windows Server 2016 I got issues with .bat script that I use as hook command - for unknown reason system just ignores it (or better to say - I've got message that execution finished OK - but in reality nothing done at all). But general files backup (scheduled or manual) works just fine. Probably this issue related to Windows Server 2016 itself and not Backrest.
P.S. Just found that newer version of NSSM manager exists 2.25 - but I haven't tried it yet.
+1 to finding a way to launch automatically whilst allowing Backrest to leverage VSS.
I've tried the scheduled task method others have mentioned, and whilst it claims to be running elevated the VSS fails.
I did wonder whether it's worth creating an account to add to the Backup Operators group, or some other way to leverage that group for permissions - will need to do some more research. Keen to hear other's views if someone knows more already!
