Self-hosted docker does not create mssql backups

hi there!

title says it all: for some reason the nightly backups are not being triggered. can anyone point me in a direction where to look? how do i manually run the mssql export, so that a backup will be created in mssql/backups? how is this supposed to be scheduled in the first place?

environment: bitwarden team running in docker in a synology. i did follow the self-hosted install guide except for one exception: the base directory is not in /opt but in /volume1. (/opt has been wiped once by a syno update-patch.)

thank you
sebastian

Hopefully these below links will assist you in the backup of your self hosted data. I would also suggest if back ups are not running properly on their own you may attempt to make sure the install script has updated itself, and then use the script to reinstall Bitwarden docker containers

https://bitwarden.com/help/article/backup-on-premise/

1 Like

@bbbbb if you’re running this on your NAS, it may be Vaultwarden (formerly bitwarden_rs) - if so you may have a different set of commands/troubleshooting steps.

i was installing using the installer skript from bitwarden.com (bitwarden.sh), which is then downloading and setting up your environment. this used to work before (with version something like 1.41). but on a rebuild with a newer version it does not (version 1.43 or so). i know how to deal with those kind of issues, i was hoping someone knows in more detail the structure of the containers the way they are installed with the bitwarden-installer-script. it is a lot of containers. which container exactly is triggering the backup. which command line in which file is exactly running the backup command for the mssql-container. also how can i run that mssql manually. the manual only refers to “is being created nightly”.

ok, i c.

in mssql logs (bwdata/logs/mssql/errorlog) i found this:

Backup      Error: 3041, Severity: 16, State: 1.
Backup      BACKUP failed to complete the command BACKUP DATABASE vault. Check the backup application log for detailed messages.

notice vault here is the name of the referenced database. gotcha.

when installing with bitwarden.sh. the script asks you for the name of the database. the default is vault. this is what i accepted in the first setup.

the second time around, i set a different name: db_bitwarden.

if you set a name here, this is not reflected in the mssql container. i should better say it is not reflected in all the important places.

within the mssql container, there is a file, where the backup job is defined → /backup-db.sql.

in the container i did not find an editor, so i copied the file to the host.
docker cp bitwarden-mssql:/backup-db.sql .

now change the db name in there from vault to your respective name
SET @DatabaseName = 'db_bitwarden'
SET @DatabaseNameSafe = 'db_bitwarden'

and then copy back the file into the container
docker cp backup-db.sql bitwarden-mssql:/backup-db.sql

now lets see what happens tonight. i will update here.

1 Like

@bbbbb we just recently introduced the ability to change the db name and have this captured as an improvement on our backlog. Your change should address the issue :+1:

hm, didnt work tonight.

@tgreer do you know how exactly the backup script is being triggered? how do i manually launch that piece of code? what exactly is the command? is it the backup-db.sh skript in the container? not on site right now, just talking from what i recall.

As far as I am aware, yep - that’s the script. I think you may need to restart the containers using
./bitwarden.sh restart

aha. obviously i didnt realize something recreated the backup-db.sql file in the container. probably a ./bitwarde.sh update command or so. it was reset to backup the db with the default name vault.

@tgreer trey, do you know if there is an undocumented env variable which points to the db name? for now i will manually set the name and after that dont touch any updates never again. :wink: so far the documentation does not list anything like that.

manually running ./backup-db.sh in the container bitwarden-mssql does work and creates the backup in mssql/backups.

Ahh - that will definitely do it :slight_smile:

I’ll check and see if there are any env overrides you could use :+1:

after double, triple, quadruple checking of backup-db.sql for the correct db name, the scheduled backup has been created tonight.

if we now find an env-setting to tell the respective container which name to set as the db-name, i’d be close to IT nirvana.

2 Likes

According to entrypoint.sh in bitwarden-mssql container, it has the following lines:

# Replace database name in backup-db.sql
if [ ! -z "$DATABASE" ]
then
  sed -i -e "/@DatabaseName /s/vault/$DATABASE/" backup-db.sql
  sed -i -e "/@DatabaseNameSafe /s/vault/${DATABASE// /-}/" backup-db.sql
fi

This means if we set $DATABASE in the file /opt/bitwarden/bwdata/env/mssql.override.env
and run bitwarden.sh rebuild followed by bitwarden.sh start, it will all work as expected.

1 Like

@scidoner that works! thank you!

FYI I just ran into this issue with a new install where the custom vault DB name was just using the valut so I changed it to my custom name and did the rebuild of the docker files and looks to have updated the backup SQL script. Thank you!

May I please inquire about how to modify the database name? I have been using a database named Bitwarden, but due to the passage of time, I am not entirely certain. Is there a way for me to locate my database name and make the necessary modifications to enable seamless automatic MSSQL backups?

After running ./backup-db.sh in the bitwarden-mssql container, I received the following message: Database 'vault' does not exist. Make sure that the name is entered correctly.

I seem to have found that in the ./bwdata/env/global.override.env file, the value of the Initial Catalog variable in the globalSettings__sqlServer__connectionString parameter appears to be the database name for Bitwarden. Currently, I have attempted to modify the value of the DATABASE variable in the ./bwdata/env/mssql.override.env file to a custom database name, and I’m eagerly awaiting to see if automatic MSSQL backups will work tomorrow.

I’m happy to report that the above method has been confirmed to resolve the database name issue.