Notifications

QUMBU only sends notifications by email. To configure the email settings for backup status notification (Figure 3), you first have to specify an SMTP server, which QUMBU uses to dispatch email. After that, you specify parameters for backup notification, such as deciding on the events about which you want to be notified. What is missing at this point are alternative notification paths, such as a webhook, which you could use to integrate Slack, for example.

Figure 3: The email notification informs you of the success or failure of a task.

In the last window, you define the schedule for the backup (Figure 4). In addition to choosing daily, weekly, or monthly backups, you have options for specifications such as the day of the week, time, and the start and end dates. Configuring a backup for individual databases was identical, except for the option to select one or more databases at the beginning instead of just the SQL server.

Figure 4: The schedule configuration is identical for each task and covers all reasonable possibilities.

One very helpful feature is backing up by pattern matching (i.e., performing an action against all databases that match a certain filter). This option can be helpful if, for example, all databases for production operations start with Prod and databases for development start with Dev . Perhaps you don't want to back up the Dev databases daily, but you do want to for the production databases. In this scenario, you would filter by database name, starting with Prod . This option is especially useful where databases are added or deleted dynamically and a server has large numbers of databases.

You also need a function to restore a backed up database to the same or another Microsoft SQL Server. The Restore task in QUMBU does this for you. As options, the developers implemented recovery from the backup history, which is only possible on the same server, and recovery from a file, which lets you recover the database on another SQL server. For both options, the configuration dialog for the task is just as simple as the backup task: Right-click and select Add to open the dialog; then, select the server and the database if you are restoring from the history. In the next window, the program shows you the history, from which you then select the desired restore start time. After that, check the expert and email settings for further tweaks. The schedule configuration dialog lets you specify when you want the restore to take place. Daily, weekly, and monthly intervals are also possible.

When restoring from a file, the task definition differs only in terms of the first dialog, in which you select the backup file and specify the SQL server and target database for the restore. The remainder of the configuration process is exactly the same as restoring from the history. To clone a database from one server to another, the vendor uses sequential backup and restore tasks. One use case for this example is regularly replicating a database to another server.

Simple Recovery

To check the consistency of a backup that you created, you have the option of simulating a restore. In this case, QUMBU reads and processes the data exactly as if the real restore were taking place, the only difference being that the software does not write any data at the end. In this way, you can check whether the backup from another database server is compatible with the target server if the two SQL servers are running different versions. The tasks for the simulated restore are identical to the processes of the actual restore described earlier.

In addition to the main tasks of backing up and restoring databases, the developers also offer the ability to perform some maintenance tasks, including consistency checks, index maintenance, finding unused indexes, and checking for free hard disk capacity.

Here, too, I liked the identical process of creating tasks as was used in previously described procedures. I added a new task from the context menu and made the task-specific settings. For the consistency check, I selected the server and the database. In the expert settings, I determined the database console command (DBCC) I wanted to run for the check. In addition to the familiar email notification, I also specified the schedule for the check.

For regular index maintenance, I again created a task for which I selected the server and the database. In the expert settings this time, I was able to set the thresholds for the reorganization and rebuild as percentages. The developers also include an option for the minimum number of index pages. According to the manufacturer, however, index maintenance only makes sense after seven days of operation, because no reliable statements about outdated or unused indexes can be made before that. However, if necessary, you can adjust this time in the configuration.

To make sure the database server has enough disk space, you need to set up the appropriate check. In the configuration dialog, select the SQL server and chose the drives you want to monitor from the list of available drives, setting the threshold values in gigabytes for warnings and notifications in case of errors individually for each drive.

The subsequent configuration for the email notification and the process of creating the schedule are familiar. For this task, however, you do not select one-off execution per day, weekday, or month but specify a daily check in a given time frame and a certain interval. In the test, this was the weekday test, without weekends, during production hours from 8am to 10pm with an interval of 15 minutes. This was a way of ensuring no downtime because of a lack of hard disk space, especially during peak hours when the database is in use.

User Management

It is worth mentioning that QUMBU has no user management with regard to the operation of the software. The target group of users is limited to the administrator, who is allowed to do everything, or users who just have read-only rights. These settings also showed up in the list of users under the Settings function. Here, QUMBU outputs all the users that have been saved for access to the databases. An additional read-only checkbox restricts their authorizations.

To round off the feature set, the manufacturer integrated – again, as a task – a reporting function, which made it possible to receive a weekly report by email (e.g., that clearly shows the results of the defined tasks). In addition to selecting the server and the possible tasks, you can also set the reporting period.