[jerf]

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.

I'm somewhat less crazy-eyes about the importance of backing things up properly than some people on HN can get. A lot of personal content I can honestly just accept the risk of losing it. However, if there is an exception to that, your password vault is it. It is possible to get yourself into a situation where you are completely locked out of things and the more systems go to harder authentication that you can't even store in your head like TOTP and hardware tokens the easier it gets to be in a world where if you lose your vault you can't recover because you can't even log in to the email account you'd use to recover.

[alyandon]

  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]

This is kinda unnecessary, each of DB has a tool which can safely backup it online.

[jerf]

I 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]

You 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.