Desktop mode and Service mode
Jul 18, 2016
Bvckup 2 can be run in one of two principal modes.
In desktop mode, which is the default, program's user interface and its backup engine share the same process, so you see a single instance of bvckup2.exe on your Task Manager list. Exiting the program stops both the engine and the UI, meaning that you need to be logged into Windows *and* to be running the program for the backups to run.
In service mode, the program splits the engine and user interface into two separate processes. The backup engine is installed as a Windows system service and it in the background, at all times. The user interface continues to run as a regular desktop program and it can be started and stopped at will. In this mode, logging out of Windows closes the user interface, but leaved the engine running, so Bvckup2 continues to make backups even if no one is logged in.
Jul 18, 2016
Service mode caveats
Keep in mind that in a service mode the engine part runs under a different user account and as such it will not generally have the access to any shares that might be accessible to the (desktop) user account.
It will also most certainly will not have the access to any of the user's mapped network drives as these are a per-account property.
First, if you are backing up to- or from a remote share, you *must* use explicit network paths, such as \\server\share\path...
Second, if said remote share requires authentication, then you have two options:
⦁ Configure share access credentials in Bvckup 2 itself
⦁ Create a separate user account for the "bvckup2" service.
Switch service to run under this account, using Service Manager.
Add this new account to the Backup Operators group.
Grant this account required access rights on the share end.
The benefit of the second option is that the share access password is not getting stored in Bvckup 2 configuration, so it provides for a better security if one is required.
Jul 18, 2016
Switching the mode
1. Menu > Options > Preferences, check "Show 'Switch mode' option"
2. Menu > Options > Switch mode
You can tell Bvckup 2 to open a log window that shows the switching process by holding Ctrl button down when clicking on Apply in the "Switch mode" window.
The same log is also always written into the following file:
Jul 18, 2016
Switching the mode from command-line
As of Release 76 it's also possible to switch the mode from command line using the following command:
bvckup2.exe --set-mode <service|desktop> <config-path>
whereby <config-path> points at app's configuration directory in desktop mode. On Vista+ it will be:
The app must NOT be running when the switch is made to the service mode. To ensure this you can shut down the app from the command line using "terminate" command. See the following topic for details - https://bvckup2.com/support/forum/topic/411
Several additional parameters are supported by --set-mode command:
--console - opens the log console
--log <file> - redirects the log into <file>
--force - forces skipping over certain errors
--atomically - limits the switch to atomic NTFS move only
Also, when switching to the service mode:
--service-only - installs bvckup2 service, but skips the config move
which is meant for switching newly installed app instances that haven't been run yet.
The result of the switch is indicated with a process exit code. 0 is for OK, non-zero is for failure. Exact failure codes are TBD, please get in touch if you need help interpreting them.
Jul 18, 2016
What happens during the switch
Switching to the service mode does the following:
⦁ Creates %ProgramData%\Bvckup2 folder.
⦁ Moves or copies %ConfigPath%\engine to %ProgramData%\Bvckup2
⦁ Copies %ConfigPath%\bvckup2-service.log to
⦁ Creates bvckup2 service entry
⦁ Starts the bvckup2 service
Switching to the desktop mode does the following:
⦁ Stops the bvckup2 service
⦁ Moves or copies %ProgramData%\Bvckup2\engine to %ConfigPath%
⦁ Resets security information on %ConfigPath%\engine, recursively
⦁ Copies %ProgramData%\Bvckup2\bvckup2.log to
⦁ Removes bvckup2 service
%ConfigPath% here is the parameter from the command line.
When moving engine folder, the app first attempts to actually *move* it using transactional NTFS rename operation. If this fails (which happens when some app holds a reference to any part of the engine folder), the app falls back to copying folder, file by file. The copying fallback can be suppressed with --atomically parameter.
When creating/moving/copying folders - if there's an existing copy of the folder already in place, the app will try moving it out of the way by renaming into "%FolderName%_xxx (backup)", whereby xxx is current timestamp in NTFS time units.
The configuration folder move can be disabled altogether with --service-only parameter.
Finally, when some part of the switch sequence fails, the app undoes all changes already made and reports a failure.
Topic is locked.