Mysql database wiped everytime I update bitwarden_rs docker #435

New Issue

OVERLORD · 2026-02-04T20:30:31+03:00

OVERLORD commented

2026-02-04 20:30:31 +03:00

Originally created by @ghostbitmeta on GitHub (Oct 4, 2019).

Hi,

Every time I update my bitwarden_rs docker, my login doesn't work and I have to create a new account again. Luckily I am able to export the database from my old client and restore it. But this gets annoying to do every time.

Is there a way to prevent this?

Originally created by @ghostbitmeta on GitHub (Oct 4, 2019). Hi, Every time I update my bitwarden_rs docker, my login doesn't work and I have to create a new account again. Luckily I am able to export the database from my old client and restore it. But this gets annoying to do every time. Is there a way to prevent this?

OVERLORD closed this issue

2026-02-04 20:30:32 +03:00

OVERLORD commented

2026-02-04 20:30:36 +03:00

@mprasil commented on GitHub (Oct 4, 2019):

What image are you using? Which version?

@mprasil commented on GitHub (Oct 4, 2019): What image are you using? Which version?

OVERLORD commented

2026-02-04 20:30:41 +03:00

@targodan commented on GitHub (Oct 6, 2019):

What commands are you using to manage your docker container? Pure docker? docker-compose?

Please show us your commands and your compose file in case you use docker compose.

My guess is: You have not configured your docker-volumes properly, which are the only persistence layer of docker. Without those every restart of a container clears all data. (This includes updating the image)

@targodan commented on GitHub (Oct 6, 2019): What commands are you using to manage your docker container? Pure docker? docker-compose? Please show us your commands and your compose file in case you use docker compose. My guess is: You have not configured your docker-volumes properly, which are the only persistence layer of docker. Without those every restart of a container clears all data. (This includes updating the image)

OVERLORD commented

2026-02-04 20:30:45 +03:00

@ghostbitmeta commented on GitHub (Oct 6, 2019):

Image: bitwardenrs/server:latest
Just updated to Version 1.10.0-e7b8602e , but it has happened previous times.

Pure docker. Managing through portainer. Using watchtower for upgrades.

Env:
"DATABASE_URL=mysql://bitwarden:xxxxx@sql.xxxxx.com/bitwarden", "ENABLE_DB_WAL=false", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "ROCKET_ENV=staging", "ROCKET_PORT=80", "ROCKET_WORKERS=10"

Volumes:
{ "Type": "bind", "Source": "/docker/bwdata", "Destination": "/data", "Mode": "", "RW": true, "Propagation": "rprivate" }

No issues when I restart bitwarden. Only migrations.

@ghostbitmeta commented on GitHub (Oct 6, 2019): Image: `bitwardenrs/server:latest` Just updated to `Version 1.10.0-e7b8602e` , but it has happened previous times. Pure docker. Managing through portainer. Using watchtower for upgrades. Env: ` "DATABASE_URL=mysql://bitwarden:xxxxx@sql.xxxxx.com/bitwarden", "ENABLE_DB_WAL=false", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "ROCKET_ENV=staging", "ROCKET_PORT=80", "ROCKET_WORKERS=10"` Volumes: ` { "Type": "bind", "Source": "/docker/bwdata", "Destination": "/data", "Mode": "", "RW": true, "Propagation": "rprivate" } ` No issues when I restart bitwarden. Only migrations.

OVERLORD commented

2026-02-04 20:30:48 +03:00

@targodan commented on GitHub (Oct 6, 2019):

Afaik the bitwardenrs/server:latest does not support the mysql backend. That would be the bitwardenrs/server-mysql:latest image. (Haven't used that one before)

I'm guessing that is your problem. I assume the image you are using is quietly ignoring the database configuration and just quietly uses sqlite instead. The sqlite db would then end up in /data/db.sqlite3 inside the docker-volume. Not sure why that volume does not survive the update but I neither have experience in watchtower nor in portainer.

The solution to your problem is likely to be: Use the bitwardenrs/server-mysql image. If you need to recover any data, take a look at the sqlite db I mentioned, inside the volumes of your old containers (if they still exist and haven't been pruned)

@targodan commented on GitHub (Oct 6, 2019): Afaik the `bitwardenrs/server:latest` does not support the mysql backend. That would be the `bitwardenrs/server-mysql:latest` image. (Haven't used that one before) I'm guessing that is your problem. I assume the image you are using is quietly ignoring the database configuration and just quietly uses sqlite instead. The sqlite db would then end up in `/data/db.sqlite3` inside the docker-volume. Not sure why that volume does not survive the update but I neither have experience in watchtower nor in portainer. The solution to your problem is likely to be: Use the `bitwardenrs/server-mysql` image. If you need to recover any data, take a look at the sqlite db I mentioned, inside the volumes of your old containers (if they still exist and haven't been pruned)

OVERLORD commented

2026-02-04 20:30:54 +03:00

@ghostbitmeta commented on GitHub (Oct 6, 2019):

Thanks! I thought it might be on the sqlite db- but I had accidentally been backing it up and the md5sum had not changed in a while. So it didn't seem to store it there either.

I will try with the server-mysql image and see if it survives a future migration.

@ghostbitmeta commented on GitHub (Oct 6, 2019): Thanks! I thought it might be on the sqlite db- but I had accidentally been backing it up and the md5sum had not changed in a while. So it didn't seem to store it there either. I will try with the server-mysql image and see if it survives a future migration.

OVERLORD commented

2026-02-04 20:30:57 +03:00

@mprasil commented on GitHub (Oct 8, 2019):

So this is interesting issue and I think I might know what happened. The thing is, that DATABASE_URL is setting that's also used in the sqlite image and it defaults to /data/db.sqlite3. But I assume you had DATABASE_URL set to something like:

mysql://user:pass@mysql/bitwarden

Which is actually also a valid file path. I think this led to creating a sqlite db somewhere in:

# Added extra spaces bellow to clearly separate individual path components:
mysql: / user:pass@mysql / bitwarden

So it wouldn't be under /data/ but actually somewhere under /mysql: (yes colon is a valid character in path) and I doubt you had that path backed up. So very likely every time you restarted container, this path was gone and hence database lost.

@mprasil commented on GitHub (Oct 8, 2019): So this is interesting issue and I think I might know what happened. The thing is, that `DATABASE_URL` is setting that's also used in the sqlite image and it [defaults to `/data/db.sqlite3`](https://github.com/dani-garcia/bitwarden_rs/blob/99a635d327dc7a7123c6f0036999597342e96542/src/config.rs#L206). But I assume you had `DATABASE_URL` set to something like: ``` mysql://user:pass@mysql/bitwarden ``` Which is actually also a valid file path. I think this led to creating a sqlite db somewhere in: ``` # Added extra spaces bellow to clearly separate individual path components: mysql: / user:pass@mysql / bitwarden ``` So it wouldn't be under `/data/` but actually somewhere under `/mysql:` (yes colon is a valid character in path) and I doubt you had that path backed up. So very likely every time you restarted container, this path was gone and hence database lost.

OVERLORD commented

2026-02-04 20:31:01 +03:00

@dani-garcia commented on GitHub (Oct 8, 2019):

@mprasil's explanation makes sense to me, and also makes me think we should handle this case ourselves:

We should make sure that when using either MySQL or Posgres the URL starts with mysql: and posgres: respectively.
Also make sure that when using SQLite, the address DOESN'T start with those two prefixes.

That way it would make the error more obvious.

@dani-garcia commented on GitHub (Oct 8, 2019): @mprasil's explanation makes sense to me, and also makes me think we should handle this case ourselves: - We should make sure that when using either MySQL or Posgres the URL starts with mysql: and posgres: respectively. - Also make sure that when using SQLite, the address DOESN'T start with those two prefixes. That way it would make the error more obvious.

OVERLORD commented

2026-02-04 20:31:14 +03:00

@dani-garcia commented on GitHub (Oct 8, 2019):

Okay added it in 881c1978eb, after the 1.11 release, just in case it breaks something.

@dani-garcia commented on GitHub (Oct 8, 2019): Okay added it in https://github.com/dani-garcia/bitwarden_rs/commit/881c1978eb8e2eaea2467e6b3bf79d2d91196ec1, after the 1.11 release, just in case it breaks something.

OVERLORD commented

2026-02-04 20:31:24 +03:00

@mprasil commented on GitHub (Oct 15, 2019):

Closing this as it seems to be resolved. Feel free to reopen if there's anything more we can do regarding this.

@mprasil commented on GitHub (Oct 15, 2019): Closing this as it seems to be resolved. Feel free to reopen if there's anything more we can do regarding this.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#435