Databases are the tech heart of the enterprise. If they stop beating, the entire work process usually grinds to a standstill, which is why it is so important constantly to maintain and secure your databases. I took a look at how this can be done with QUMBU [1] – new software by WSW Software for creating backups and maintaining the SQL Server database management system (Table 1) – and discovered that the developers have put a great deal of thought into ease of use and a planned approach. In the lab, I checked whether the software can measure up to the claim that these processes can be organized in an effortless and secure way.

For this example, the tool was installed on Windows Server 2019; it will run on Windows 7 or Windows Server 2012 with a .NET Framework. As the SQL server, the QUMBU developers assume version 2008 R2 or newer. The lab had SQL server 2019 in place. The well-structured instructions will also help administrators get through the installation and familiarization process, even if you do not work with SQL servers on a daily basis.

The setup wizard gives you the option of installing a single QUMBU client, the QUMBU server, or both components together. Therefore, the server component and the client can be installed separately (e.g., on the server and an administrative desktop computer). For this example, the full install was chosen. The QUMBU server runs in the background as a Windows service; it requires a logged in user account to run, which you specify during the installation.

After the software is installed, the wizard expects you to enter a QUMBU account name, which is the user who has access to all SQL Server instances and can be a user who authenticates locally on Windows; in other words, you do not need a domain controller. This process is simple; you can view all the potential users and select the one you want from a list. After entering the password, you can then complete the installation. Note that you do need admin privileges for the installation; otherwise, the required services will not start.

During the installation on Windows Server 2019, I initially had problems because the QUMBU service failed to launch. The manufacturer's support team then analyzed the problem and determined that – contrary to the stated system requirements – .NET Framework 3.5 was required. After installing it, the setup completed successfully.

No Connection to Azure Database

After the launch, an uncluttered window came up; this is the QUMBU cockpit. Next to the toolbar is an area for displaying the servers, the tasks, and the task details and notifications. To begin, add a Microsoft SQL server. To do so, right-click in the Servers area and select the Connect to Server entry. In the dialog that follows, enter the server name and your login details.

After connecting, you will see that the device has been added to the Servers area. Additional servers can also be entered at this point, but they must be accessible on the network. Connections with a virtual private network (VPN) are also possible, as are publicly accessible servers, which is already an advantage over Microsoft SQL Server Management Studio. QUMBU also lets you include and manage multiple servers. However, QUMBU refused to connect to an SQL database I was running in Azure, saying that the server did not run on a Windows operating system. The requirement is that you run the SQL server on a dedicated Windows server – physical or virtual – for QUMBU to be able to handle it.

The license model also reflects this requirement. The manufacturer only requires one license per physical or virtual server. The license is then valid for managing any number of database instances and users. The properties of the server instance and database can be seen in the context menu. For example, you can see whether the server version and the user used for the connection had full authorization. For the database, QUMBU shows the current status as well as the created on and last backup dates.

Cross-Server Tasks

Once the server is set up, you can turn your attention to the central task area. After selecting a server in the corresponding area, you can proceed to configure it and then select All Servers in the top level of the tree structure (Figure 1) to apply the task you defined to all servers. The Job details area displays the history of executed tasks in a table, where you can filter for specific servers or tasks. Without this restriction, QUMBU shows all tasks for all SQL servers. The lower window shows the current system health notifications that relate to individual tasks or individual SQL server instances. I liked the fact that I could also see the urgency level (i.e., whether the message was just a notification or a warning that needed a response).

Figure 1: The QUMBU client has a state-of-the-art, clear-cut interface.

Tasks Everywhere

No matter what you want to do with QUMBU, the developers packaged all the functions into tasks. Both backing up and restoring a database are tasks, as are the various maintenance functions.

To begin, create a database backup task by selecting the Backup icon in the toolbar, which reveals options to Backup All databases, Backup Selected databases, or Backup by Pattern databases that match a search pattern. Clicking on the respective entry takes you to the corresponding task configuration. The operation is always the same: Right-click in the resulting dialog to open the context menu and select Add . The configuration dialog prompts you for parameters relating to the task. To back up all the databases, you just need to assign a name to the task and select the SQL server to be backed up.

On the next page of the dialog, you define the path, file name, and description (Figure 2). QUMBU also gives you variables for the server name, database, and backup date. The Expert tab has a variety of options regarding the backup itself. For example, you can specify the compression ratio and decide whether you want a differential backup or a full copy. The optional encryption is yet another level of protection for your data. Other options included the number of buffers, the maximum transfer rate, and the block size setting.

Figure 2: Variables can be used in the specifications for the path and file name of a backup.