Add option to also backup current database file on save

[cgku]

Summary

The current option to 'Backup database file before saving' is not truly a backup, but appears to act as a restore point for the "as-was" state of the database before changes were saved. This is perfect if the recent changes need to be rolled back for some reason. However, if something happens to the current database, this backup copy will not have any of the changes just saved, so data loss is guaranteed. The current workaround is to manually make another copy after each database save, or use another tool to create additional copies.

Suggestion

Change the backup process to create and sustain at least two, but possibly more, backup files. The first would be an identical copy of the current database state. The other file(s) would be the previous X versions, where X is a user-configured setting.

Context

This removes the need for a manual copy, or external solution, to create an identical copy of the currently saved database.

[droidmonkey]

Technically, the "backup" created is a direct copy of a known working database. To make another copy of the current database doesn't really make sense based on what we are trying to protect against. The point of corruption is on writing, not when stored (unless you use a USB thumb drive, don't do that)

I do agree that if you are looking to store a copy backup to a different location, on save, then we don't have that capability.

[agowa]

Currently the "backup database file before saving" option also accepts a backup destination. It could as well be on a different mount.

For me for example the main database is on a share from my NAS. The backup copy could be local or vice verse.

And just a reminder the original keepass (don't know about KeepassXC) supports (and often is also used that way) being accessed by multiple people simultaneously and then causes this ugly "do you want to discard, overwrite or merge your changes" dialog which probably not just for me but also for a lot of others caused significant data loss by accidentally overwriting changes of others. So that may also be a reason for why a true backup of the file as it exists in the location before it was saved may be a desired feature (and having a backup copy with the latest changes at the backup location is basically solving the same issue by allowing to go back and recover the entries you just overwrote even days or weeks later, as the last save before you saved and overwrote would have created a timestamped backup copy that you can then just open and copy the entries back in...).

Ok admittedly for that concurrent access use case a better solution then the current dialog should be implemented but just having the backup feature is probably way easier than dealing with merge conflicts esp. if we consider that there almost certainly is always at leas one user in a team that may not be able to (not care, or just had a bad day and accidentally made the wrong decision when trying to) resolve them correctly...