Built-in Auto Backup in Web App

[tajamalqaiser]

Hey Vaultwarden team!

First off, big thanks to the maintainers for all the work you do! I’ve been exploring the repo and community discussions, and I keep seeing how important frequent backups are to prevent data loss. That got me thinking—wouldn't it be great if the Vaultwarden web app itself had a built-in option for automated backups?

Idea 💡

A simple feature in the web app settings that lets users:

• Automatically send pre-encrypted backups to a pre-set email address.
• Auto-save pre-encrypted backups to a linked cloud storage (like Google Drive).

The encryption would be pre-configured within Vaultwarden to ensure backups are always secure before they leave the server.

Why This Would Be Cool 🚀

• No need for manual backups—just set it and forget it.
• Security-first: Since encryption is handled before sending, data stays safe even if email or cloud storage is compromised.
• Makes Vaultwarden even more reliable, on par with premium password managers.
• Super useful for users who aren’t comfortable setting up external scripts.

I know there are ways to back up data manually, but having this built into the web app UI with built-in encryption would make it way more convenient and secure. Would love to hear what the maintainers and community think!

[BlackDex]

Not sure what you expect? Vaultwarden can't decrypt the data and export a special encrypted version.

Best would be to just backup the database and be done with it i think.

[mttkrb]

Maybe extend backup section in admin console of adding a cron pattern and number how much backups should be stored?

[pamperer562580892423]

Probably relevant: https://github.com/dani-garcia/vaultwarden/wiki/FAQs#i-have-a-feature-request-for-the-web-vault-or-any-other-client

[mttkrb]

not really. because it's only on admin panel and should not affect bitwarden compability in any way

[pamperer562580892423]

That idea here has "in web app" in the title. That is the web vault. @BlackDex just yesterday wrote here "This project does not develop the web-vault, [...] and the web-vault is also a client [...]."

[BlackDex]

The backend admin is Vaultwarden specific, and detached from the web-vault.
Though, adding an auto-backup feature is kinda tricky from my point of view.

What should we backup? Technically you should also backup all the sends and attachments, but how, where should it be encrypted (Even though it's already encrypted at rest). All this stuff does kinda make users/container users a bit lazy, and just assume it's all done and working, nothing to care about afterwards.

Also, if those backups are then still inside the same directory as to which Vaultwarden has access, it isn't really a backup of course. It should be synced off-site and even better to a different geological region.

[pamperer562580892423]

Ah, Sorry, then I misinterpreted the title.

[brandon1024]

Speaking to the feature request from @tajamalqaiser, if you want to forward a backup to other systems, that should be plumbed yourself. Vaultwarden can't be reasonably expected to support every backup backend under the sun, nor should it. Maintainers have better things to focus their energy on.

As of Vaultwarden 1.32.1, a new backup subcommand was added which can be used to generate a backup of the (sqlite) database. It's pretty easy to use this to take regular snapshots for backup and recovery. I've had this in place for some time, and attempted a recovery from backup just the other day to validate the process and it worked nicely.

@mttkrb's comment is pretty interesting. This is something I'd love to see in Vaultwarden too, and it's exactly what other self-hosted apps do (Immich, for example, generates nightly database dumps, and so does Photoprism). Backups are trivial then; here's my nightly backup service for immich, for example:

[Unit]
Description=Daily Immich Backup
AssertPathIsDirectory={{ immich_server_library_path }}
AssertPathIsDirectory={{ immich_backup_path }}

[Service]
# first, backup the database exports (and clean up old ones)
ExecStart=/usr/bin/rsync -aW --delete {{ immich_server_library_path }}/backups {{ immich_backup_path }}/
# finally, backup the media files
ExecStart=/usr/bin/rsync -aW {{ immich_server_library_path }}/ {{ immich_backup_path }}/
Type=oneshot

[Install]
WantedBy=default.target

Automatic nightly backups would simplify my backup process. Right now, I need to cleanup old backups, exec into the container to trigger the backup, then copy db/sends/attachments to the backup location. If backups were automatic, I just need filesystem access.

@BlackDex what are your thoughts on supporting nightly sqlite backups? I could stake a stab at this, but I'm not a Rust developer and could be take a bit of effort. The first iteration could be dead simple:

• Keep last 14 backups. The number of backups could be made configurable later.
• Backup daily at 00:00. The frequency/time of backups could be made configurable later.

[BlackDex]

Well, it isn't that hard, but the problem i see is that there is more then just the database.
And providing a way to let users enable an auto-backup feature kinda implies a full backup of everything.

So, i think users should manage this them self. That we provide an easy solution to trigger a backup of the SQLite database is just a convenience.

[brandon1024]

Agreed, you're right. I don't think it's totally necessary for Vaultwarden to handle the backup of sends/attachments/etc though. What I'm proposing here is to extend the SQLite backup convenience a little to reduce a bit of friction on the backup automation.

[BlackDex]

Yes, and my point is, that providing such a solution might let users think it's all-in-one, done and fixed.
Therefor providing such a feature seems dangerous from my point of view. Users will assume it will fix everything, therefor, I'm not for adding such a feature.

[mttkrb]

Ok. I understand. Currently I do a period backup of mapped /data. With manual backups by web interface I hope it's enough ;-)
I'll check a desaster recovery later.

[brandon1024]

Understood, thanks for your input @BlackDex!