Switch in progress
Cancelling the switch
As you may know, Bvckup 2 can run in a so-called
which keeps the backups running even if the program itself is not started or when no one is logged in at the computer.
The program can be switched between the service and desktop modes on the fly and this functionality has been improved for both speed and robustness in the upcoming
The program can now automatically recover from any issues stemming from being foricibly closed/killed midway through the mode switch process.
This is different from before where any such recovery, while still always possible, needed to be done manually.
Switching back to the desktop mode now displays a % done for the
of the process (
The slow part itself was reworked for speed and it was also fully parallelized. The more CPU cores you have, the faster it goes. It can still be slow, mind you, but it is less so now.
Finally, it's now possible to cancel the switch if desired.
The slow part
Under the hood Bvckup 2 is essentially
a pair of programs
sharing a single executable.
One is the
, which is a module that handles scheduling and execution of backup jobs, tracking of storage devices, dispatching of email alerts, etc.
Another is the
module - it talks to the engine, retrieves and displays a list of jobs and allows controlling and configuring them by sending requests to the engine.
Both modules operate independently from each other and communicate through a formal messaging protocol. Similarly their configuration data is also not mixed, with each module using their own directory to store all its data.
When the program is switched to the service mode, the engine module is simply shut down and re-launched as a system service.
Switching back to the desktop mode reverses that - it stops the service and starts the engine inside the UI process. Easy.
there is one nuance. There always is...
When running as a service, the engine runs under a
dedicated user account
. This account is a member of the Local Admins group, so it has no problem accessing engine's config files even though they were created under a desktop user account.
However, any files it
are owned by the Local Admins and they are
fully accessible by the original (desktop) process.
So, going back to the desktop mode requires another step - we need to
reset the owner
on all engine config files.
This issue is further compounded by the fact that the number of files in the engine config can be really quite large.
This is because the engine config is where settings for all backup jobs are kept, and this includes the blockhash data of files copied using the
The more files are delta-copied, the larger the engine config will be and the longer it will take for the owner reset to complete.
is the slow part.
*/ ?> /* ?>