Allow users to easily check if a backup of their db is needed.

[dennismarwood]

See - https://vaultwarden.discourse.group/t/checking-for-changes-to-db-before-backing-up/2432

But, in a nutshell, a backup of the db is really only needed if data such as passwords (ciphers) are altered. Data about users logging in and out does not really meet the threshold of a meaningful change to the db warranting a backup. Most days the tables "__diesel_schema_migrations" "twofactor_incomplete" "event" and "devices" are altered as vw is used. While days or weeks can go by where the other tables don't change.

A new table could be added to the db that tracks meta data about the db. One of the columns could store a unixepoch value. When a change in a table worthy of making a backup occurs (most tables would meet this criteria) their triggers would update the unixepoch value.

A user could then know when they should perform a backup just by comparing the time of their last backup and the current value in the new column.

[Masgalor]

I am a little confused by your backup-strategy.
So your desired workflow would be to check the timestamp of the last db-change, compare it to the timestamp of your last backup and manually trigger a new backup if necessary.

Isn't this a really error prone process?
The burden to check the timestamps is on you, if you forget to do it or you don't have access to your server for some time there will be no backups. Also if the function that updates the timestamps isn't working as intended you might miss the notice to trigger your backup.

I think most people would agree that backups should be fully automated and run on a fixed schedule rather than checking to see if the backup is really necessary.

Just for example my own backup strategy
Interval 1h (keep 24 iterations) - Backup process data to harddisk to recover from software crashes/errors
Interval 24h (keep 7 iterations) - Backup all data to dedicated backup-server to recover from hardware errors
Interval 1 week (keep 3 iterations) - Copy the last daily backup to another storage in another building

[BlackDex]

I totally agree. But that is what I also mentioned on the Forum. If you want to check for changes check the updated_at timestamps in the database. I'm against adding extra columns just for some strange error prone way to backup a database.

A backup needs to be a full backup, doesn't matter what changed in my opinion. Because, if someone changes there name or mail address, that might be unimportant to you, but might be for someone else. Same goes for adding a new table or column.

[RealOrangeOne]

Backups should be as simple as possible. Just always back up your database. If storage is a concern, use something which will deduplicate the storage instead.

[dennismarwood]

The server hosting vw performs a cron job to see when it last backed up. It just looks at the name of the last backup which has it date in the name and does a comparison. So I wouldn't consider it a burden any more than any other automated backup system. The idea of this enhancement was to make it dead simple for someone to know when a change has occurred that should be backed up. Triggers and a db entry that tracked changes seemed like an easy way to do that. You could even have your job run at much tighter intervals and get your backup just a minute or two after a change happened.

Just to be reiterate... it is a full backup of the db. But that full backup should only be needed when an important change happens. I agree that someone changing their name or email is enough to be worth a backup. In fact any change that a user makes would probably be worth a backup. But the typical interaction that changes the db of users logging in and out is not worth a backup. This enhancement would make it easy to know when something worth backing up has occurred.

Adding this enhancement could also open the door to a future enhancement of vw itself generating the "material" backups as needed for the user automatically.

[pluim003]

That is a good thing indeed. With my local setup I backup the /data-directory once a day which in case of problems would mean that users would lose maximum a day of changed/added/removed passwords. As for a consistent backup of the whole directory I shut down the docker-container sometime during the night when the least change is that there is someone actively connected. :-)