When dbBackup.plgx fails, it fails silently
A lightweight and easy-to-use password manager
Brought to you by:
dreichl
Menu
▾
▴
A while back, I did a little rearranging on my file server, which included changing the name of one of the parent folders in the path to the folder I had been using for .kdbx backups. Unfortunately, it didn't dawn on me to reconfigure dbBackup.plgx accordingly, so it turns out that for the past few weeks dbBackup.plgx has been essentially accomplishing nothing - and, more importantly, it never bothered to inform me in that time that it's been repeatedly unable to accomplish its assigned task. Luckily, I haven't had any reason to use the backups it was supposed to be making for me during this time, but still, if backups aren't being made, I ought to be told about it.
Last edit: T. Bug Reporter 2014-06-01
This can be done by starting a program from DB_Backup which checks your backup was successful.
cheers, Paul
Paul -can you elaborate on your comment ?
When I click
"tools" "db backup plug-in"
I get three options:
- backup DB now!
- automatically backup db
- configure
the first two items have no iterface its click and be done.
the last has a configuration panel and nothing here indicates the ability to run a program.
for what its worth I don't believe the silent failure is a bug but rather an interface mistake.
I have backups configured to network devices but my laptop is not always on network.
in this event I'm ok with backups not occuring as target is expected to not exist.
there probably should be a check box in the interface to complain (or not) if target folder does not exist that way those that always expect backups to occur because everything is expected to be live/available 100% of time will get notices and those configurations where the target folder routinely will not exist can continue to not needlessly notified that targert does not exist.
to T. Bug Reporter:
an addtional action you can perform is to create autosync trigger
with this trigger each time you OPEN your real/live .kdbx file
it performs a 2 way record level sync with the remote/other file.
this will give you a backup. Depending on how you configure the trigger you can have it complain if the sync (backup) fails.
A common usage of a sync trigger is to sync with a file that dropbox copies to cloud
and/or sync with a keychain usb device which you then walk around with.
With either method the remote file might routinely endure valid dataentry on some remote pc
during this time the original/main file might get valid data entry.
The sync trigger will do a 2 way record level sync so each file is brought current with the other so at the end of the sync the files are identical.
In your case the remote file will never receive data entry so effectively its simplky another backup you have created.
In the example below the "contions_tab" has a check to only proceed with the sync if the remote file exists. This is what people what when using keychain device as the keychain device is expected to routinely be NOT be attached when the main .kdbx is opened.
In this typical situation the trigger exits gracefully (no dialog box).
In your case if you leave the contitions tab blank then the sync would always occur.
So long as your network is up you would always get a backup.
if they sync failed for any reason then a error dialog box would appear giving you a clue that your sync/backup didn't work.
the filenames of the local / remote file being sync do NOT need to match however both files need to use the same master key.
example of a sync trigger:
tools triggers add
Properties_TAB
name: autosync x enabled x initially on
Events_TAB
opened database file = [fully qualified filename of live .kdbx]
Conditions_TAB
file exists = [fully qualified filename of backup .kdbx]
Actions
Activate database [fully qualified filename of live .kdbx]
synchronize active database with file = [fully qualified filename of BACKUP .kdbx]
Activate database [fully qualified filename of live .kdbx]
Last edit: develop1 2014-06-01
I happened to run KeePass from a different machine, and found that dbBackup.plgx was no longer configured any more. After doing some more digging, I found that despite using the portable version of KeePass from a network location, the dbBackup.plgx configuration is stored on the local drive, and thus has to be separately configured on every machine I use - which is very inconvenient, and not a good fit for how I use KeePass. It may be that for me, dbBackup.plgx will be more trouble than it's worth; the alternatives seem even more complicated to configure, but hopefully I can find one that'll stay configured the way I want it once I configure it.
Last edit: T. Bug Reporter 2014-06-01
develop1, you can set an external command to run in the ini file or from the command line (DB_Backup.ExtPrgPath | -db_backup.prog:)
See the readme file.
TBR, as you keep the database on a network drive, why not allow the network machine to manage the backups? If it's a Windows machine use "Previous Versions" to capture changes. What ever machine it is you can run a regular backup using your normal backup software.
cheers, Paul
It just dawned on me... if the KeePass.config.xml in the network location where I keep KeePass.exe says
<PreferUserConfiguration>false</PreferUserConfiguration>
, why am I still getting files stored in "~/AppData"? Is this a bug in KeePass, a bug in dbBackup.plgx, or a misunderstanding on my part about how KeePass works?
I'll start with an apology, I've not been looking at the correct plug-in - my bad. Please ignore my previous comments.
There is a log file written after every backup. Look in the folder with the backup for a file called "Database"_log.
I can't find where the configuration is saved. It doesn't appear to be in KeePass.config.xml.
cheers, Paul
It isn't. On my PCs, it's at "C:\Users\{me}\AppData\Local\Dominik_Reichl\KeePass.exe_StrongName_xzynbbjhsmtgnkfkag4h4gilrsbrudqj\2.26.0.16582\user.config" - which leads me to believe that the plugin may be buggy (or rather, not designed to take the other KeePass settings into consideration when deciding where to store its own settings).
BTW: That "xzy" stuff in the path isn't some random string chosen on the fly. I've looked at several computers, and this string is identical on all of them - but then again, I'm using the same network installation of KeePass on all of them, so maybe it's trying to generate a random string, but coming up with the same answer every time.
BTW2: Which plugin were you looking at? Maybe I should try that one.
Yep, I get the same folder name.
The plug-in I was looking at was only for V1.
I would use a trigger and batch file for backup rather than a plug-in. Then you can control exactly what you get - I do.
cheers, Paul
My reason for using the plugin (and, I imagine, most everyone else's, too) is to lower the learning curve for these advanced features - as I've also been griping about in this unrelated thread. Yes, triggers and batch files seem more than capable of handling these tasks, but that's the point - they're more than capable. As with most things about KeePass, it seems like whenever I attempt to swat a fly, KeePass gives me an excellent selection of sledgehammers to do it with.
Getting back to my original reason for creating this thread, I just found that my copy of the DataBaseBackup plugin has stopped working again. The plugin's config file still exists at "C:\Users\{me}\AppData\Local\Dominik_Reichl\KeePass.exe_StrongName_xzynbbjhsmtgnkfkag4h4gilrsbrudqj\2.26.0.16582\user.config", and hasn't changed from when I started this thread (I made a backup at that time), but when I look at the plugin's config from within KeePass, the dialog box is empty. The plugins page says that the author of this plugin is Francis Noël; does anyone know how to contact this person?
UPDATE: After further investigation, I found that a new config file for this plugin was created at "C:\Users\{me}\AppData\Local\Dominik_Reichl\KeePass.exe_StrongName_sz40gteh1cob2dkgg2ctymdxrarj0anj\2.26.0.25257\user.config". So, not only does this plugin save its configuration in the user AppData folder (ignoring the user's wishes to keep their installation portable), but it also stores this configuration in a location that is keyed to the version of KeePass that is being used, thus ensuring that the plugin's configuration is forgotten whenever KeePass itself gets updated - and that the former configuration file is also forgotten about and never gets cleaned up.
In other words, this plugin is horribly broken and probably should be pulled from distribution until somebody can fix it. While the source code is also available here, it's not clear whether someone else can make the fix, because there's no mention of licensing - unless it's in the source code itself (which I've downloaded, but not taken the time to read yet).
Last edit: T. Bug Reporter 2014-06-28
Francis is a SourceForge member - assuming he gets mail you can try his user email.
https://sourceforge.net/p/keepass/discussion/329221/thread/7d80667f/
cheers, Paul
FYI: Francis did reply to my eMail last month, and sent me a link to a fixed version of his plugin, which I've had absolutely no trouble with since then. However, he apparently hasn't forwarded a copy of the fix to Dominik to post on keepass.info - or else one or both of them are working on other mods (possibly including high DPI support) and they don't want to post an interim version.
More FYI: If there was an official announcement, I must've missed it, but the plugins page now shows 2.0.8.6 as the current available version of this plugin. The version that was being distributed when I started this topic was 2.08.4 (and yes, the numbering scheme has apparently changed slightly in the interim).
BTW: Is there a simple way to examine a .plgx file to obtain its version number, similar to the way the property sheets for an .exe or .dll show them?
BTW2: I still don't know if the original issue that caused me to start this topic (silent failure) still exists - because I haven't rearranged my hard drive again since then; but I suspect that if I did, the plugin would still fail (silently or not, I don't know), because the backup locations are still stored as absolute paths.
BTW3: What's the point of allowing the user to specify multiple backup locations in this plugin, anyway?
btw3: backups are cool rarely is one enough.
The more variety of different devices, spindles, servers you can put one on the better the chance a crash, flood, theft, fire will still leave you with a backup. Also a great idea to maintain x version of historical backups as well that way if you wish to go back xx days to before a virus/brain fart you can.
I use the pluggin in question to put copies out on local HD devices, network device and a dropbox device for cloud storage maintaining at least 20 versions of history.
I think I found what may be another bug in this plugin. Today, I opened two databases at once, made changes to one of them, switched to the second one to look up some other passwords, and then shut down KeePass. Afterward, I found an unnecessary copy of the second database in my backup folder, but no recent copy of the database that actually got changed. Apparently, this plugin confuses "current database" with "triggering database" - a mistake that I recall other plugin writers also having made before.
(I'm posting this here rather than starting a new topic in the hope that the author of this plugin is still monitoring posts to this topic, since there still isn't any separate forum for this plugin.)
T.Bug - what you describe seems like a bug.
regardless of author fixing pluggin or not a workaround action that we can do is to define an "AutoSave" trigger wherein the "ok" button of the edit panel triggers the save action (assuming unsaved changed exist to be saved).
Workaround results in multiple advantages: it makes current database and triggering database one in the same therein avoiding the bug. It also guarantees that all data entry is written to disk (and backed up) the soonest instant possible with zero possibility of losing data entry.
My entire reason for installing this plugin was to avoid having to learn the complexities of the trigger system - however, I think I know enough about it to know that I wouldn't like this "save as you go" behavior; that would be like Microsoft Word saving each and every character you type to disk the instant you type it.
On a related topic, I've sent another eMail to the author of this plugin to try to call his attention back here, since there's been no evidence that he has noticed these latest posts.