As you may know, Bvckup 2 can run in a so-called service mode 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 79.23 release.


1.  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.

2.  Switching back to the desktop mode now displays a % done for the slow part of the process ( see below ).

3.  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.

4.  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 backup engine, which is a module that handles scheduling and execution of backup jobs, tracking of storage devices, dispatching of email alerts, etc.

Another is the user interface 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.

But 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 creates are owned by the Local Admins and they are not 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 delta copier.

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. So that is the slow part.
Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms