[GH-ISSUE #1656] Command not found: sqlite3 #1028

New issue

Closed

opened 2026-03-03 02:05:39 +03:00 by kerem · 6 comments

kerem commented 2026-03-03 02:05:39 +03:00

Owner

Copy link

Originally created by @alexpovel on GitHub (May 2, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1656

Subject of the issue

The docs for backing up Vaultwarden still mention SQLite and its corresponding sqlite3 binary. Back when I first started using Bitwarden_RS, I had written a backup script around that (requires rsync):

Click to expand

#!/bin/sh

# Custom script to backup a Bitwarden installation.
# This requires getting a database dump and rsyncing that dump and
# the attachment directory over to a mounted backup destination.
# The script is agnostic to what the backup destination actually is.

# See also:
# https://github.com/dani-garcia/bitwarden_rs/wiki/Backing-up-your-vault

# Options for this script:
# x: Show debugging
# e: Exit immediately if a command exits with a non-zero status.
# u: Treat unset variables as an error when substituting.
set -eux

echo "Running $(basename "$0") as $(id)."

# Dot is important as an anchor for rsync and its --relative option.
# Trailing slash is also required for rsync to work correctly.
TMP_DATABASE_DUMP_DIR=/backup/./db/
TMP_DATABASE_DUMP_FILE=bitwarden.sql.bak

# For rsync, the trailing slash is important
BACKUP_DIR=/mnt/backup/

ATTACHMENTS_DIR=${DATA_FOLDER}/./attachments/

cleanup() {
    # Collect cleanup operations here; guarantees these are run when trapped
    rm -r "$TMP_DATABASE_DUMP_DIR"
}

# On script EXIT, run command
trap "cleanup" EXIT

mkdir -p "$TMP_DATABASE_DUMP_DIR"

echo "Getting database dump"

sqlite3 "$DATA_FOLDER"/db.sqlite3 ".backup '${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}'"

echo "Got database dump, wrote to ${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}"

echo "Starting rsync for all data"
# For rsync options, see its help and also
# https://gist.github.com/KartikTalwar/4393116
# The destination is backed up and versioned *in itself*. We therefore only copy stuff
# over in the simple-most way, without dates in filenames and such.
# Multiple inputs paths are possible; all but the last are sources, last is destination.
rsync \
    --acls \
    --archive \
    --delete \
    --human-readable \
    --info=NAME1,DEL1,SKIP1,STATS3 \
    --relative \
    --xattrs \
    "$ATTACHMENTS_DIR" \
    "$TMP_DATABASE_DUMP_DIR" \
    "$BACKUP_DIR"

echo "Finished rsync, exiting"

It has been working just fine but recently broke. I feel like I missed something because there isn't an open issue on this yet, but the docs linked above seem reasonably up to date (mention sends directory), so I'm hoping the sqlite3 part is still relevant.

I have looked in different locations for help but wasn't succesful:

• https://github.com/dani-garcia/vaultwarden/releases/tag/1.17.0 is a minor release with lots of DB changes, but was long ago and doesn't make any mention of moving away from sqlite3
• #1492 is about MySQL/MariaDB
• #1646 is an update from 1.16 to 1.21 with lots of DB migration stuff, but I updated from 1.20 to 1.21 and see none of that in my logs
• #1647 mentions "vaultwarden one has no sqlite executable", which I can confirm but doesn't help

Deployment environment

• vaultwarden version:

   $ docker pull vaultwarden/server && docker inspect vaultwarden/server
   Using default tag: latest
   latest: Pulling from vaultwarden/server
   Digest: sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958
   Status: Image is up to date for vaultwarden/server:latest
   docker.io/vaultwarden/server:latest
   [
       {
           "Id": "sha256:ca7d174aef769b69c15e1d9d90900f40cafd927cfdd77397c5d4210a2b79c211",
           "RepoTags": [
               "vaultwarden/server:latest"
           ],
           "RepoDigests": [
               "vaultwarden/server@sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958"
           ],
           "Parent": "",
           "Comment": "",
           "Created": "2021-04-30T15:12:00.890378129Z",
           "Container": "",
           "ContainerConfig": {
               "Hostname": "",
               "Domainname": "",
               "User": "",
               "AttachStdin": false,
               "AttachStdout": false,
               "AttachStderr": false,
               "Tty": false,
               "OpenStdin": false,
               "StdinOnce": false,
               "Env": null,
               "Cmd": null,
               "Image": "",
               "Volumes": null,
               "WorkingDir": "",
               "Entrypoint": null,
               "OnBuild": null,
               "Labels": null
           },
           "DockerVersion": "",
           "Author": "",
           "Config": {
               "Hostname": "",
               "Domainname": "",
               "User": "",
               "AttachStdin": false,
               "AttachStdout": false,
               "AttachStderr": false,
               "ExposedPorts": {
                   "3012/tcp": {},
                   "80/tcp": {}
               },
               "Tty": false,
               "OpenStdin": false,
               "StdinOnce": false,
               "Env": [
                   "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                   "ROCKET_ENV=staging",
                   "ROCKET_PORT=80",
                   "ROCKET_WORKERS=10"
               ],
               "Cmd": [
                   "/start.sh"
               ],
               "Healthcheck": {
                   "Test": [
                       "CMD",
                       "/healthcheck.sh"
                   ],
                   "Interval": 60000000000,
                   "Timeout": 10000000000
               },
               "Image": "",
               "Volumes": {
                   "/data": {}
               },
               "WorkingDir": "/",
               "Entrypoint": [
                   "/usr/bin/dumb-init",
                   "--"
               ],
               "OnBuild": null,
               "Labels": {
                   "org.opencontainers.image.created": "2021-04-30T14:49:52+00:00",
                   "org.opencontainers.image.documentation": "https://github.com/dani-garcia/vaultwarden/wiki",
                   "org.opencontainers.image.licenses": "GPL-3.0-only",
                   "org.opencontainers.image.revision": "1e5306b8203a7ebe24047910e6c690c18c6d827a",
                   "org.opencontainers.image.source": "https://github.com/dani-garcia/vaultwarden",
                   "org.opencontainers.image.url": "https://hub.docker.com/r/vaultwarden/server",
                   "org.opencontainers.image.version": "1.21.0"
               }
           },
           "Architecture": "amd64",
           "Os": "linux",
           "Size": 178520878,
           "VirtualSize": 178520878,
           "GraphDriver": {
               "Data": {
                   "LowerDir": "/var/lib/docker/overlay2/f679b79840ef74c86863b7d979fbe1d8c82924e9bee6a2138cc841a9f61eb09c/diff:/var/lib/docker/overlay2/5a5b76c46e2fbc7132f78c34fa478d3b087b81886a4795312ce365ff1e7cc402/diff:/var/lib/docker/overlay2/a04edbd27432bcfdda8fc3834647e183d8d8da92d1576e661689433659f34c31/diff:/var/lib/docker/overlay2/60beb58637805221040008ca8fe3ad07d89ea3edcc59b39ccdf1fd0a234f4921/diff:/var/lib/docker/overlay2/eb3d200376d6e1c690e253f7649ad761bd3d13d60a0dc5ab1d85ff012c2d3e10/diff:/var/lib/docker/overlay2/76160244325bbfc2a26f784ecd23dfb9dd83a216494ffacee861e7b3638df717/diff:/var/lib/docker/overlay2/6356ca7c6a6df11ea84fbedc18712ed8d5a742d83effb095924b66e6241f9f3e/diff",
                   "MergedDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/merged",
                   "UpperDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/diff",
                   "WorkDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/work"
               },
               "Name": "overlay2"
           },
           "RootFS": {
               "Type": "layers",
               "Layers": [
                   "sha256:7e718b9c0c8c2e6420fe9c4d1d551088e314fe923dce4b2caf75891d82fb227d",
                   "sha256:def104127282fe2861c66c6bdefd58bdfdc09d2d38026e3bb8db6044b040dadd",
                   "sha256:2ab5bbd7df9604b4243d394284025b95fd9d351a530876b2c0552dc0aa38e4f6",
                   "sha256:df9933473761d880d7dedfbaf07450fc2c139017ec2f0212fa904b132b70107c",
                   "sha256:f0ad681d19836cc2514f86f530312d7c14f338b11746b0d408a54a4b52381585",
                   "sha256:62e3cf577e2c8a5b29182de52c1238ee7c122c4324ff32743fe73a624a16a89b",
                   "sha256:b8af4836b9303c3223ff435a5959b4e32daa01ab8a2d4f30d2a27cf5fb284f46",
                   "sha256:8369906ae231db354cb1b9fa742554c16d7538fe782b38fd816899a1de19ceb6"
               ]
           },
           "Metadata": {
               "LastTagTime": "0001-01-01T00:00:00Z"
           }
       }
   ]
  

• Install method: Docker

• MySQL/MariaDB or PostgreSQL version: SQLite!

Steps to reproduce

There's no sqlite3 program anymore in the current Docker image (see above for the exact version):

$ docker run --rm -it --entrypoint=sqlite3 vaultwarden/server --version
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown.

Expected behaviour

sqlite3 to be present so backups succeed as described in the docs.

Its present in 1.20, so one minor version prior (vaultwarden/server isn't available for this one):

$ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.20.0 --version
3.27.2 2019-02-25 16:06:06 bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0alt1
$ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.21.0 --version
docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown.

That tells me the place to look for such a breaking change is the 1.21 changelog, but there's nothing there concerning databases.

Actual behaviour

sqlite3 is not present (apt-get install sqlite3 in a child image fixes this for now).

Originally created by @alexpovel on GitHub (May 2, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1656 <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue <!-- Describe your issue here. --> The [docs](https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#sqlite-database-files) for backing up Vaultwarden still mention SQLite and its corresponding `sqlite3` binary. Back when I first started using Bitwarden_RS, I had written a backup script around that (requires `rsync`): <details> <summary>Click to expand</summary> ```sh #!/bin/sh # Custom script to backup a Bitwarden installation. # This requires getting a database dump and rsyncing that dump and # the attachment directory over to a mounted backup destination. # The script is agnostic to what the backup destination actually is. # See also: # https://github.com/dani-garcia/bitwarden_rs/wiki/Backing-up-your-vault # Options for this script: # x: Show debugging # e: Exit immediately if a command exits with a non-zero status. # u: Treat unset variables as an error when substituting. set -eux echo "Running $(basename "$0") as $(id)." # Dot is important as an anchor for rsync and its --relative option. # Trailing slash is also required for rsync to work correctly. TMP_DATABASE_DUMP_DIR=/backup/./db/ TMP_DATABASE_DUMP_FILE=bitwarden.sql.bak # For rsync, the trailing slash is important BACKUP_DIR=/mnt/backup/ ATTACHMENTS_DIR=${DATA_FOLDER}/./attachments/ cleanup() { # Collect cleanup operations here; guarantees these are run when trapped rm -r "$TMP_DATABASE_DUMP_DIR" } # On script EXIT, run command trap "cleanup" EXIT mkdir -p "$TMP_DATABASE_DUMP_DIR" echo "Getting database dump" sqlite3 "$DATA_FOLDER"/db.sqlite3 ".backup '${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}'" echo "Got database dump, wrote to ${TMP_DATABASE_DUMP_DIR}${TMP_DATABASE_DUMP_FILE}" echo "Starting rsync for all data" # For rsync options, see its help and also # https://gist.github.com/KartikTalwar/4393116 # The destination is backed up and versioned *in itself*. We therefore only copy stuff # over in the simple-most way, without dates in filenames and such. # Multiple inputs paths are possible; all but the last are sources, last is destination. rsync \ --acls \ --archive \ --delete \ --human-readable \ --info=NAME1,DEL1,SKIP1,STATS3 \ --relative \ --xattrs \ "$ATTACHMENTS_DIR" \ "$TMP_DATABASE_DUMP_DIR" \ "$BACKUP_DIR" echo "Finished rsync, exiting" ``` </details> It has been working just fine but recently broke. I feel like I missed something because there isn't an open issue on this yet, but the docs linked above seem reasonably up to date (mention `sends` directory), so I'm hoping the `sqlite3` part is still relevant. I have looked in different locations for help but wasn't succesful: - https://github.com/dani-garcia/vaultwarden/releases/tag/1.17.0 is a minor release with lots of DB changes, but was long ago and doesn't make any mention of moving away from `sqlite3` - #1492 is about MySQL/MariaDB - #1646 is an update from `1.16` to `1.21` with lots of DB migration stuff, but I updated from `1.20` to `1.21` and see none of that in my logs - #1647 mentions "`vaultwarden one has no sqlite executable`", which I can confirm but doesn't help ### Deployment environment <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> <!-- The version number, obtained from the logs (at startup) or the admin diagnostics page --> <!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden --> <!-- Remember to check if your issue exists on the latest version first! --> * vaultwarden version: ```json $ docker pull vaultwarden/server && docker inspect vaultwarden/server Using default tag: latest latest: Pulling from vaultwarden/server Digest: sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958 Status: Image is up to date for vaultwarden/server:latest docker.io/vaultwarden/server:latest [ { "Id": "sha256:ca7d174aef769b69c15e1d9d90900f40cafd927cfdd77397c5d4210a2b79c211", "RepoTags": [ "vaultwarden/server:latest" ], "RepoDigests": [ "vaultwarden/server@sha256:9303a3efb19f002631c7825b8db1eceb4a97bac716d391ac4b434f9aef344958" ], "Parent": "", "Comment": "", "Created": "2021-04-30T15:12:00.890378129Z", "Container": "", "ContainerConfig": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": null, "Cmd": null, "Image": "", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": null }, "DockerVersion": "", "Author": "", "Config": { "Hostname": "", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "ExposedPorts": { "3012/tcp": {}, "80/tcp": {} }, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "ROCKET_ENV=staging", "ROCKET_PORT=80", "ROCKET_WORKERS=10" ], "Cmd": [ "/start.sh" ], "Healthcheck": { "Test": [ "CMD", "/healthcheck.sh" ], "Interval": 60000000000, "Timeout": 10000000000 }, "Image": "", "Volumes": { "/data": {} }, "WorkingDir": "/", "Entrypoint": [ "/usr/bin/dumb-init", "--" ], "OnBuild": null, "Labels": { "org.opencontainers.image.created": "2021-04-30T14:49:52+00:00", "org.opencontainers.image.documentation": "https://github.com/dani-garcia/vaultwarden/wiki", "org.opencontainers.image.licenses": "GPL-3.0-only", "org.opencontainers.image.revision": "1e5306b8203a7ebe24047910e6c690c18c6d827a", "org.opencontainers.image.source": "https://github.com/dani-garcia/vaultwarden", "org.opencontainers.image.url": "https://hub.docker.com/r/vaultwarden/server", "org.opencontainers.image.version": "1.21.0" } }, "Architecture": "amd64", "Os": "linux", "Size": 178520878, "VirtualSize": 178520878, "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/f679b79840ef74c86863b7d979fbe1d8c82924e9bee6a2138cc841a9f61eb09c/diff:/var/lib/docker/overlay2/5a5b76c46e2fbc7132f78c34fa478d3b087b81886a4795312ce365ff1e7cc402/diff:/var/lib/docker/overlay2/a04edbd27432bcfdda8fc3834647e183d8d8da92d1576e661689433659f34c31/diff:/var/lib/docker/overlay2/60beb58637805221040008ca8fe3ad07d89ea3edcc59b39ccdf1fd0a234f4921/diff:/var/lib/docker/overlay2/eb3d200376d6e1c690e253f7649ad761bd3d13d60a0dc5ab1d85ff012c2d3e10/diff:/var/lib/docker/overlay2/76160244325bbfc2a26f784ecd23dfb9dd83a216494ffacee861e7b3638df717/diff:/var/lib/docker/overlay2/6356ca7c6a6df11ea84fbedc18712ed8d5a742d83effb095924b66e6241f9f3e/diff", "MergedDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/merged", "UpperDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/diff", "WorkDir": "/var/lib/docker/overlay2/6fce2a9254633c9bbcdfaeef0c20de936d9a9ff0794c9f7865d1f2ab369f0e24/work" }, "Name": "overlay2" }, "RootFS": { "Type": "layers", "Layers": [ "sha256:7e718b9c0c8c2e6420fe9c4d1d551088e314fe923dce4b2caf75891d82fb227d", "sha256:def104127282fe2861c66c6bdefd58bdfdc09d2d38026e3bb8db6044b040dadd", "sha256:2ab5bbd7df9604b4243d394284025b95fd9d351a530876b2c0552dc0aa38e4f6", "sha256:df9933473761d880d7dedfbaf07450fc2c139017ec2f0212fa904b132b70107c", "sha256:f0ad681d19836cc2514f86f530312d7c14f338b11746b0d408a54a4b52381585", "sha256:62e3cf577e2c8a5b29182de52c1238ee7c122c4324ff32743fe73a624a16a89b", "sha256:b8af4836b9303c3223ff435a5959b4e32daa01ab8a2d4f30d2a27cf5fb284f46", "sha256:8369906ae231db354cb1b9fa742554c16d7538fe782b38fd816899a1de19ceb6" ] }, "Metadata": { "LastTagTime": "0001-01-01T00:00:00Z" } } ] ``` <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: Docker * MySQL/MariaDB or PostgreSQL version: SQLite! ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> **There's no `sqlite3` program anymore** in the current Docker image (see above for the exact version): ```bash $ docker run --rm -it --entrypoint=sqlite3 vaultwarden/server --version docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown. ``` ### Expected behaviour <!-- Tell us what you expected to happen --> `sqlite3` to be present so backups succeed as described in the docs. Its present in `1.20`, so one minor version prior (`vaultwarden/server` isn't available for this one): ```bash $ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.20.0 --version 3.27.2 2019-02-25 16:06:06 bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0alt1 $ docker run --rm -it --entrypoint=sqlite3 bitwardenrs/server:1.21.0 --version docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "sqlite3": executable file not found in $PATH: unknown. ``` That tells me the place to look for such a breaking change is the [1.21 changelog](https://github.com/dani-garcia/vaultwarden/releases/tag/1.21.0), but there's nothing there concerning databases. ### Actual behaviour <!-- Tell us what actually happened --> `sqlite3` is not present (`apt-get install sqlite3` in a child image fixes this for now).

kerem closed this issue 2026-03-03 02:05:39 +03:00

kerem commented 2026-03-03 02:05:39 +03:00

Author

Owner

Copy link

@fdisamuel commented on GitHub (May 2, 2021):

Hi @alexpovel!

I think this commit is related to your problem:
github.com/dani-garcia/vaultwarden@95fc88ae5b

Use VACUUM INTO to create a SQLite backup instead of using the external sqlite3 application.

• This also removes the dependancy of having the sqlite3 packages installed on the final image unnecessary, and thus removed it.

As you can see, local sqlite3 packages has been removed from the image, as they are not needed anymore for the admin panel database backup function.
My workaround for this, that I run my backup script from the host system which has the necessary sqlite3 packages, not inside the container (I use bind mount from the /data directory to my host local /home/user/bwdata folder so I can reach and backup the db.sqlite3 from the host.)

<!-- gh-comment-id:830819758 --> @fdisamuel commented on GitHub (May 2, 2021): Hi @alexpovel! I think this commit is related to your problem: https://github.com/dani-garcia/vaultwarden/commit/95fc88ae5bef5f4d1e9a8da4f5de7c955fb75a19 > Use `VACUUM INTO` to create a SQLite backup instead of using the external sqlite3 application. > - This also removes the dependancy of having the sqlite3 packages installed on the final image unnecessary, and thus removed it. As you can see, local sqlite3 packages has been removed from the image, as they are not needed anymore for the admin panel database backup function. My workaround for this, that I run my backup script from the host system which has the necessary sqlite3 packages, not inside the container (I use bind mount from the `/data` directory to my host local `/home/user/bwdata` folder so I can reach and backup the `db.sqlite3` from the host.)

kerem commented 2026-03-03 02:05:40 +03:00

Author

Owner

Copy link

@dani-garcia commented on GitHub (May 2, 2021):

Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted.

If you still want to run it from inside the container, mounting a shell script into /etc/vaultwarden.sh or /etc/vaultwarden.d/*.sh inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time.

<!-- gh-comment-id:830826646 --> @dani-garcia commented on GitHub (May 2, 2021): Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted. If you still want to run it from inside the container, mounting a shell script into `/etc/vaultwarden.sh` or `/etc/vaultwarden.d/*.sh` inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time.

kerem commented 2026-03-03 02:05:40 +03:00

Author

Owner

Copy link

@alexpovel commented on GitHub (May 2, 2021):

@fdisamuel excellent, thanks for pointing out the exact commit. I have built multipe services around the idea of backing up from within containers:

• each container that is to be backed up gets the following:
  • a bind mount into the container at /mnt/backup (using Docker's built-in NFS driver, so the backups go directly to the correct destination)
  • a script at /etc/backup.sh; these are tailor-made for each application, like the one in the OP for vaultwarden
  • a container label like backup.enabled
• the host has a systemd timer and simply gets all containers with the above label, and runs docker exec <id> /etc/backup.sh, where those shell scripts write to /mnt/backup

Anyway... that's why running everything from within the containers is my chosen course of action. After all, these containers already ship with everything required, might as well use them. (Sometimes we need to be in the container anyway, like to enable maintenance mode for Nextcloud) It only sucks for scheduling, so that's done on the host.

---

Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted.

Ah okay, I read that wrong then.

If you still want to run it from inside the container, mounting a shell script into /etc/vaultwarden.sh or /etc/vaultwarden.d/*.sh inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time.

Okay thanks! But I take it it's safe to apt-get install sqlite3 in a child image and continue that route? Would be much more Docker-friendly.

<!-- gh-comment-id:830826971 --> @alexpovel commented on GitHub (May 2, 2021): @fdisamuel excellent, thanks for pointing out the exact commit. I have built multipe services around the idea of backing up from *within* containers: - each container that is to be backed up gets the following: - a bind mount into the container at `/mnt/backup` (using Docker's built-in NFS driver, so the backups go directly to the correct destination) - a script at `/etc/backup.sh`; these are tailor-made for each application, like the one in the OP for vaultwarden - a container label like `backup.enabled` - the host has a `systemd` timer and simply gets all containers with the above label, and runs `docker exec <id> /etc/backup.sh`, where those shell scripts write to `/mnt/backup` Anyway... that's why running everything from within the containers is my chosen course of action. After all, these containers already ship with everything required, might as well use them. (Sometimes we *need* to be in the container anyway, like to enable maintenance mode for Nextcloud) It only sucks for scheduling, so that's done on the host. --- > Yeah, the docs are mostly meant for the user running the sqlite command from the host side, where the data directory is mounted. Ah okay, I read that wrong then. > If you still want to run it from inside the container, mounting a shell script into `/etc/vaultwarden.sh` or `/etc/vaultwarden.d/*.sh` inside the container would run that script during startup, so you can make sure anything else you need inside the container is installed any time. Okay thanks! But I take it it's safe to `apt-get install sqlite3` in a child image and continue that route? Would be much more Docker-friendly.

kerem commented 2026-03-03 02:05:40 +03:00

Author

Owner

Copy link

@andrewlow commented on GitHub (May 29, 2021):

Maybe the wiki doc should be updated to make it more clear that sqlite3 is NOT in the image, but should be on the host?

https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#restoring-backup-data

I personally just added the "missing" sqlite3 command to the container image which let my old script work fine (which did the backup from within the image).

<!-- gh-comment-id:850896469 --> @andrewlow commented on GitHub (May 29, 2021): Maybe the wiki doc should be updated to make it more clear that sqlite3 is NOT in the image, but should be on the host? https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#restoring-backup-data I personally just added the "missing" sqlite3 command to the container image which let my old script work fine (which did the backup from within the image).

kerem commented 2026-03-03 02:05:40 +03:00

Author

Owner

Copy link

@jjlin commented on GitHub (May 29, 2021):

Docker images are expected to be minimalistic, but for users who aren't familiar with the Docker philosophy, I've updated https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#sqlite-database-files.

<!-- gh-comment-id:850899335 --> @jjlin commented on GitHub (May 29, 2021): Docker images are expected to be minimalistic, but for users who aren't familiar with the Docker philosophy, I've updated https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault#sqlite-database-files.

kerem commented 2026-03-03 02:05:40 +03:00

Author

Owner

Copy link

@andrewlow commented on GitHub (May 29, 2021):

💯 agree on minimalistic docker images.

However, the small addition of the sqlite3 command enables that same minimal image to do backups.

Now that said, I trigger the job from outside the container (using cron) - because adding cron to the image would be very much against the docker philosophy.

 docker exec bitwarden sqlite3 /data/db.sqlite3 ".backup '/data/db-backups/backup.sqlite3'"

The doc update looks good and helps people understand the recommended way to do this - I value the time and effort the folks maintaining this project put into, so thank you.

<!-- gh-comment-id:850909719 --> @andrewlow commented on GitHub (May 29, 2021): 💯 agree on minimalistic docker images. However, the small addition of the sqlite3 command enables that same minimal image to do backups. Now that said, I trigger the job from outside the container (using cron) - because adding cron to the image would be very much against the docker philosophy. ``` docker exec bitwarden sqlite3 /data/db.sqlite3 ".backup '/data/db-backups/backup.sqlite3'" ``` The doc update looks good and helps people understand the recommended way to do this - I value the time and effort the folks maintaining this project put into, so thank you.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

revert-7033-patch-1

cached-config-operations

test_dylint

1.35.8

1.35.7

1.35.6

1.35.5

1.35.4

1.35.3

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels   

SSO

  

Third party

  

better for forum

  

bug

  

bug

  

documentation

  

duplicate

  

enhancement

  

future Vault

  

future Vault

  

future Vault

  

good first issue

  

help wanted

  

low priority

  

notes

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

troubleshooting

  

wontfix

No labels

SSO

Third party

better for forum

bug

bug

documentation

duplicate

enhancement

future Vault

future Vault

future Vault

good first issue

help wanted

low priority

notes

pull-request

question

troubleshooting

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/vaultwarden#1028

No description provided.