ABP versus DB_Backup

Another Backup Plugin (ABP) was developed as an alternative¹ to DB_Backup, the original backup plugin developed by Mátyás Bene. Readers of this page are assumed to be familiar with the previous pages related to Configuring ABP, Using ABP, Atypical Actions, and Backup versus Checkpoint.

Summary

Comparison Date: This page compares ABP with DB_Backup as they existed on 19May2006, the date ABP was first released. The following table shows historical information about the two plugins:

Feature Comparison: Many users may prefer DB_Backup to ABP. DB_Backup has many features; ABP has few. ABP is a much simpler plugin than DB_Backup. The fundamental difference between DB_Backup and ABP is that DB_Backup stores configuration information in KeePass.ini, and ABP does not. The following table highlights the feature differences between DB_Backup and ABP. Therefore, similar features are not shown. In the author's view, the only comparison which is unfavorable to ABP is its lack of national language support (shown in red).

Author's View of DB_Backup: The author's view of DB_Backup is a matter of public record. Although many users may find DB_Backup suitable for their purposes, this author has found it unsuitable as a backup facility for the following reasons:

1. DB_Backup is both too aggressive and insufficiently aggressive in backing up the database file.
2. DB_Backup functionality seems more focused on checkpoint than on backup.
3. DB_Backup configuration features are better provided by shortcuts and batch files.
4. DB_Backup user interface is both too powerful and insufficiently powerful.

DB_Backup has two separate configuration schemes – KeePass.ini and command line arguments – which don't play nicely together. Command line arguments are clearly an afterthought – not an integral part of the design, and are not well integrated into the total system. DB_Backup's environment-variable-related features are redundant when batch files and/or shortcuts are used, as they often would be even without a backup plugin. DB_Backup's user interface does not gracefully support command line arguments. All of these assertions are explained below in detail.

DB_Backup Backs Up Too Aggressively

Actions Can Cause Covert Destruction: With DB_Backup, certain user actions can inadvertently cause password database backups to be overwritten – and therefore destroyed – by backups of other databases. This destruction occurs silently, without any warning before or after the event. A user can think his database is backed up, when it really isn't.

DB_Backup Backs Up Any Database: The reason this can occur is that DB_Backup backs up too aggressively: Not only does it back up the initial database, but it backs up any database that's opened and then saved in any session. It even backs up upon “Save As…”. So if a user opens and saves Important\Database.kdb, and then later (perhaps even in a different session) opens and saves Junk\Database.kdb, the second save action can overwrite her important database backup with junk. The same thing happens if the user opens Important\Database.kdb, deletes most of its entries, and then uses “Save As…” to save it in Junk\Database.kdb.

Destruction May Be Postponed: If the number of backup versions is set to 1 (the default), the overwrite and destruction occurs the first time the user saves Junk\Database.kdb. If the number of backup versions is set to n, the overwrite occurs after n saves. It could be argued that the problem of overwriting backups can be alleviated by setting the number of backup versions to a big number. Then it will take many saves before the important database backup is destroyed. But doing so simply postpones the problem without solving it. And in any case, DB_Backup is limited to 999 backup versions.

Uniqueness of Backups: A second problem with backups that are too aggressive is that the backup file names do not uniquely identify which database they are backing up. Is Backup_of_Database.kdb-0 a backup of Important\Database.kdb, or of Junk\Database.kdb? There is no obvious way to know.

ABP avoids these problems by backing up only the initial database.

DB_Backup Does Not Back Up Aggressively Enough

Backup Copy May Be Missing or Out-of-Date: With DB_Backup, there is no check when KeePass starts up to determine whether a backup may be out of date. A user can think his backup is present or is up-to-date, when it really isn't.

Update From Different PC: Suppose the password database lives on a USB flash drive, and is mainly used on one PC, where it is backed up. Assume the user makes updates to the database only infrequently. But one day, the user takes the USB flash drive to a second PC, where she adds a new password entry. She then brings the USB flash drive back to the original PC. No matter how often she uses it there without making an additional update, the new password entry will not be backed up.

Reconfiguring Backup Folders: Suppose the backup folder locations are reconfigured. No matter how often the user reads her password database without updating it, the database will not be backed up to the new locations.

Manual Remedy Needed: To remedy either problem, the end user must understand (and remember) to manually back up her password database at the appropriate time, using DB_Backup's “Backup DB NOW!” menu item. This is not the automatic backup functionality one would like.

ABP avoids these problems by backing up the initial database as needed when KeePass starts up.

DB_Backup Focuses On Checkpoint

Previous Versions Maintained: When DB_Backup copies Database.kdb, it names the copies Backup_of_Database.kdb-0, Backup_of_Database.kdb-1, Backup_of_Database.kdb-2, ..., up to n-1, where n is a configuration parameter. Thus, DB_Backup maintains not only the latest version of the password database, but also n-1 previous versions corresponding to previous save actions. This preservation of out-of-date versions seems an attempt to provide checkpointing capability, rather than backup capability. See Backup versus Checkpoint for the differences between the two. In this respect, DB_Backup functionality seems more focused on checkpoint than on backup.

Automatic Checkpointing Ineffective: In my view, the additional complexity of automatically maintaining out-of-date versions is not especially useful for checkpointing. Most database copies that DB_Backup makes would never be used for roll-back. It is not obvious which versions would be useful to roll back to, because the file names are not especially meaningful, and because these names change anyway after each save action. Furthermore, since checkpoint copies are destroyed after n save actions, the existence of a desired checkpoint copy depends on the amount of recent save activity. It becomes a matter of luck if a desired checkpoint copy is still around when you need it. Thus, you may think that you have useful checkpoint copies, when you really don't.

Prefer Manual Checkpoints: As I see it, it would be more effective for checkpoint copies to be made at explicit user request, named by the user in a meaningful way, and not automatically destroyed without warning. KeePass already provides this feature in the “Save As…” menu item.

ABP avoids providing a complex and ineffective checkpoint capability.

DB_Backup Ignores Shortcuts and Batch Files

KeePass.ini Is Primary Configuration Repository: With DB_Backup, an apparent design assumption is that neither shortcuts nor batch files are to be used to store configuration information, except as an override to KeePass.ini, where configuration information is preferentially stored. DB_Backup's use of KeePass.ini to store configuration information was established with its initial release, and is at the root of a series of subsequent enhancements which attempt to overcome various limitations of this approach. The end result is a plugin with relatively complex functionality. The following paragraphs discuss these subsequent enhancements, including destinations dialog, environment variables, “semi-environment” variables, and command line arguments.

Environment Variables: A feature to interpret environment variables in backup paths was added to DB_Backup in Version 1.0. Without this feature, a KeePass.ini file located on a USB flash drive cannot configure different backup paths on different PC hosts. At the time this feature was introduced, DB_Backup did not yet use command line arguments, which, in conjunction with either shortcuts or a batch file, could have allowed each PC to have its own backup paths.

Environment Variables Are Complicated: DB_Backup's support for environment variables encourages an unnecessarily complex approach for configuring backups on multiple machines. One could use this feature with predefined environment variables such as USERPROFILE to gain some degree of customization to multiple PCs. However, in order to specify arbitrary backup paths, it is necessary for the user to define her own global environment variables. There are two problems with doing this:

1. Defining your own global environment variables is an advanced option of the Windows® operating system. For example, in Windows XP®, the environment variables dialog opens through the “Advanced” tab in the “System Properties” settings. Users of a simple application like KeePass should not need to perform advanced operating system configuration.
2. Global environment variables pollute the environment variable namespace of the host PC with variables intended for only one application (KeePass). The also leave additional traces of KeePass, which are likely to remain after KeePass is no longer used on that PC.

Command Line Arguments: The use of command line arguments was not introduced into DB_Backup until Version 1.1. However, configuration information in KeePass.ini is still used, when not overridden by a command line argument.

Is DB_Backup's Environment Variable Feature Redundant? Once command line arguments were introduced in DB_Backup, environment variables could be defined locally in batch files, thereby avoiding the complexity problems described above. However, if one assumes the use of batch files, then these batch files can also be used to interpret environment variables, apparently making the DB_Backup environment variable interpretation feature redundant.

“Semi-Environment” Variables: A feature to interpret “semi-environment” variables %KEEPASSDIR% and %DBDIR% was added to DB_Backup in Version 1.5.0.1. The %KEEPASSDIR% variable seems similar in function to the %~dp0 batch parameter available in batch files. The %DBDIR% variable is related to the path of the initial database, except that it applies to whatever database is currently open in KeePass.

A Study in Contrasts: In my view, the most fundamental difference between DB_Backup and ABP is that DB_Backup maintains configuration information in KeePass.ini, and ABP does not. This initial conceptual difference drives numerous subsequent design decisions, resulting in starkly contrasting feature sets between the two backup plugins.

ABP avoids using KeePass.ini, interpreting environment variables, and interpreting “semi-environment” variables. ABP assumes that shortcuts and/or batch files are already in place, or can be put in place, since they are useful for KeePass even without any backup plugin.

DB_Backup User Interface Issues

DB_Backup User Interface Is Too Powerful: With DB_Backup, the end user can manually enable and disable backups through the “Automatically Backup DBs” menu item. This powerful feature, which may have been added to circumvent the problem of too-aggressive backups, works against the objective of automatically backing up the database – the main purpose of a backup plugin. The DB_Backup user must think about manually disabling and enabling backups when needed. She must keep this issue in mind across all sessions, always making sure to disable backups when they would be damaging, and enabling them when the database is to be backed up. If she forgets to manually disable backups, she risks overwriting her primary database; if she forgets to manually enable backups, she risks not having a backup of the latest changes. In the author's view, the need for constant attention to this issue by the end user diminishes the value of the “automatic” backup capability.

ABP avoids this problem by narrowly defining when backups can be expected to occur, and then by automatically disabling itself so that backups do not occur at any other time.

DB_Backup User Interface Is Not Powerful Enough: A dialog window for “destinations” (backup paths) was added to DB_Backup in Version 1.2 to allow non-geeks to view and change the DB_Backup configuration parameters stored in KeePass.ini. This dialog is considerably more complex than the ABP status window, which does not allow changing the configuration parameters – just viewing them. But in spite of this complexity, the destinations dialog is not coordinated with the command line arguments. When the destinations dialog opens in the presence of DB_Backup command line arguments, a special message box appears first, informing the user that, “Some parameters can not be altered because of command line parameters. Only preview is available.” After selecting OK, the message box is replaced by the dialog window, with some functions disabled. If both KeePass.ini and command arguments contain backup paths, only the path(s) in KeePass.ini are displayed, even though only the command argument paths are in effect. In this case the user interface is not powerful enough to show the backup paths in effect.

ABP avoids these problems by having one simple scheme for specifying configuration – command line arguments – and a simple user interface which fully supports it.

¹ Perhaps someone, finding ABP to be as unsatisfactory as DB_Backup, develops a third alternative. I suggest it be called “Yet Another Backup Plugin”, or YABP. Well, I had to include a footnote somewhere.