4 ms·
If you care enough to run a personal Vaultwarden, you should care enough to back it up too. If you don't want to back it up, you probably shouldn't run it local
by alyandon 2y ago
If you care enough to run a personal Vaultwarden, you should care enough to back it up too. If you don't want to back it up, you probably shouldn't run it locally and just use the service.
Exactly right. I have a script that briefly stops my Vaultwarden container and creates a .tgz of the contents of the data volume before restarting the container. The .tgz file gets copied off-site so I always have an accessible backup should my main host disappear.
- tvshtr 2y agoThis is kinda unnecessary, each of DB has a tool which can safely backup it online.
- jerf 2y agoI do the same thing across my (meagre) docker infrastructure, and the reason is simple: If the code isn't running, I know I can just do a disk backup of the target system. Docker is also helpful because I can know beyond a shadow of a doubt that the things that can change are on the mounted volumes and it is not possible for something important that I should be backing up to be hiding out in some directory I didn't realize it was using. So even in my modest environment, you're asking me to write special support for backing up a MySQL DB, the SQLite DB used by vaultwarden, and I don't even know what that mess in the Plex directory is. Or I can just write the same "shut it down, back it up, bring it back up" for every service, regardless of what database it currently has, what it may change to in the future, or what other databases some other service might decide it wants. It's an easy choice.
- alyandon 2y agoYou hit the nail on the head and that is exactly why I do it that way. I don't have to worry about all the different ways different databases need to be backed up if they are running and the outage window is measured in seconds in the middle of the night.