Bitwarden 2026.2.1 - Power Outage Corruption

Robert F.P. Ludwick

A Reminder

As a quick reminder, I’ve been running Bitwarden since 2021 in a self-hosted solution.

Historical Tidbit

My Bitwarden installation is currently version 2026.2.1. I had previously attempted to upgrade to 2026.3.x, but ran into an issue with the MSSQL container described here. So I pinned my version to 2026.2.1, per the instructions you find in that thread.

The Power Interruption

Late last night while I was inadvertently drifting to sleep while watching some The Traitors NZ with my wife, the stream halted and I came to. I thought it was a temporary Internet service outage, but still went into the office to check the server rack. To my horror, I found my NAS offline. This means that at least some devices lost power. Which ones, you ask? Well, I knew exactly which ones - all of the devices connected to my APC 2200VA Smart-UPS.

See, this has happened once before. Earlier this year while I was working, the backup unit just fritzed out on me. My theory at the time was that it went to run a self-test and glitched, cutting power to all connected devices. Aside from the annoyance in bringing my home lab back up from that unplanned outage, I had forgotten about it. Chalked it up to a one-time thing. Well, it happened again last night, and this time the consequences were far worse.

I spent the immediate time after the outage getting things running again. Physically powering on the Synology NAS. Remounting NFS mounts on devices which use them from the NAS. I found that my PostgreSQL container on the NAS had a corrupted database, so I restored it to a backup. Then I looked at Bitwarden, which runs on the NAS. The NGINX container was flaking on me, and I couldn’t figure out why… I left it until this morning.

This morning I looked and NGINX complaining about MSSQL issues. I looked at the MSSQL container and it was throwing errors about being unable to start the database. Well damn…

Lots of Trial and Error

I don’t want to get into the gory details of all of my trial-and-error. I can’t even remember all of the details anyhow. Suffice to say, here are some of the hurdles and attempts to recover my Bitwarden installation I tried:

  • Tried upgrading in-place to 2026.4.1 - failed. MSSQL still wouldn’t start correctly.
  • Tried a fresh install of 2026.4.1 - failed, even without a database restoration. Unsure why; MSSQL would complain about being unable to open its database.
  • Tried to find a way to repair the database in-place. Could not find one.
  • Tried to run a database restoration on the existing database - failed. Because MSSQL would not start correctly, I couldn’t even connect to it to run the restoration.
  • Couldn’t figure out for quite some time why my connection to the NAS seemed so slow. It took a long time for me to realize that my laptop was connected to my IoT network instead, because I’d recently done some work in there. My IoT network is heavily restricted in firewall configurations and bandwidth. Sigh. When I figured it out, I told my laptop to forget the connection.

How I Fixed It

Ultimately, here is how I fixed my busted Bitwarden installation. I used Bitwarden’s Backup Server Data documentation to guide me. I had daily backups of the database ready to go. First things first, I moved my old bwdata directory to a backup location on the NAS so I could run a fresh installation. Then I ensured that 2026.2.1 version was locked in place in the ./bitwarden.sh script to ensure I would be running the same version which was running when everything went haywire.

I ran the installation to spin up a fresh instance in the same directory where Bitwarden has always been running. I copied over pertinent values for the environmental keys from before:

global.override.env:

globalSettings__baseServiceUri__vault=
globalSettings__installation__id=
globalSettings__installation__key=
globalSettings__mail__replyToEmail=
globalSettings__mail__smtp__host=
globalSettings__mail__smtp__port=
globalSettings__mail__smtp__ssl=
globalSettings__mail__smtp__username=
globalSettings__mail__smtp__password=
globalSettings__disableUserRegistration=true
adminSettings__admins=

I also ensured that my NGINX configurations in config.yml were correct. I restarted Bitwarden and it came up, looking for me to login. I first tested out /admin to check that my admin access was restored, and it was. Then I ran the backup restoration per the earlier documentation; I copied over the most recent .BAK file from my old installation backup. Restarted Bitwarden and checked in /admin - I could not access the Users information. Everything else loaded up correctly. I did, however, notice and odd error when I navigated back to the admin panel from the 404 that the Users link was showing. I found my solution in this community thread; I had to copy over some data protection files from the old installation. I did so and restarted Bitwarden once more.

Great success! Admin worked, and all individuals hosted on the instance were able to login, view their vaults, and sync their secrets. Unfortunately… after a few hours, the organizational license expired somehow, despite the actual expiration time being in the future. I logged in and tried to load the subscription page to upload the license file, but the HTTP call kept returning 500. I couldn’t figure out how to correct it quickly, and since I had a backup of the organization’s vault contents, I just deleted the existing one, created the new one, uploaded the license file, and imported the backup. If I did not have a backup ready, I’d have tried harder to figure out why Bitwarden was throwing 500s.

If you have an organization, export its vault ASAP after you get Bitwarden running again from a recovery!

Fin

I never want to do this again. This was a cumulative four hours’ worth of effort over the course of the day.