# Include Bitwarden Docker server files beyond its SQL backup > For its documented Docker deployment, Bitwarden recommends preserving the entire bwdata directory alongside database backups for disaster-recovery planning. - Canonical URL: https://update.dsesecurity.com/updates/include-bitwarden-docker-server-files-beyond-its-sql-backup/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-28T23:23:22+00:00 - Modified: 2026-10-28T23:23:38+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know For its documented Docker deployment, Bitwarden recommends preserving the entire bwdata directory alongside database backups for disaster-recovery planning. ## Potentially affected Review scope: self-hosted Bitwarden Docker with the built-in MSSQL container; Bitwarden lite, external databases and Helm require separate assessment. ## DSE recommendation DSE recommends a version-qualified server recovery inventory, protected backup dependencies and an isolated restore rehearsal. ## Article Bottom line: DSE recommendation: define the server recovery set before treating an automatically produced database file as the service backup. Name the deployment being assessed and require a complete dependency inventory so the recovery owner can identify what is present, missing or still untested. ## Source fact: what the authority says The [Bitwarden server-backup guide](https://bitwarden.com/help/backup-on-premise/) recommends preserving the entire bwdata directory for its most complete disaster-recovery plan. Its important paths include environment configuration, attachments, database data and ASP.NET data-protection material. Nightly database backups depend on the built-in MSSQL container running; Bitwarden lite does not take them. ## What the source does not establish This article is limited to the documented Docker and built-in database arrangement. It does not extend that automatic-backup behavior to lite, Helm or an external database. It does not establish that a vault export, copied live directory or untested backup can recover the service. ## Applicability questions - Which deployment method, installed version and database arrangement are actually in use? - Who owns the complete recovery inventory, and which protected copies cover each required component? - Which credentials, keys, configuration records and authorized people will the isolated recovery exercise need? - Where are the gaps, and what evidence is required before the owner accepts the backup set? ## DSE recommendation: controlled next steps The following paragraphs are DSE recommendations, not instructions or guarantees from the source. Prepare a recovery manifest that identifies the deployment and every required component without putting secret values into the manifest itself. Record the protected storage location, backup method, creation evidence and responsible owner for each entry. Mark an unknown component as unresolved rather than assuming another team or an automatic task has captured it. Protect the recovery material according to the organization’s credential and data-handling policies. Restrict who may retrieve it and arrange an authorized access path for a recovery exercise. Keep the working manifest readable for the recovery team while separating passwords, keys and sensitive attachments from routine reports. Agree who can approve copying or exposing any test data. Review the manifest after a deployment change and before accepting a new backup procedure. Keep account-level export planning separate from server recovery planning. Require an explicit decision for any component excluded from the proposed backup set, including the reason, owner and consequence to be examined in rehearsal. Avoid presenting an inventory review as a completed restoration. ## Verification and evidence Proposed verification, not a performed test: build an isolated recovery exercise for the actual deployment using the reviewed inventory and current official instructions. Agree the destination, safe test data, access controls and stop conditions first. Have the recovery owner identify any missing prerequisite before attempting a service restoration. Retain backup identifiers, component inventory, versions, protected retrieval evidence and the observations from the exercise. Test representative functions only under the approved plan and record the actual result rather than a predicted outcome. Obtain the service owner’s assessment of completeness, document gaps and assign remediation. Recheck the official deployment-specific guidance before a production recovery decision. ## Official references - [Bitwarden — Backup Server Data](https://bitwarden.com/help/backup-on-premise/) — official product documentation; source version and applicability limits are stated above. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Bitwarden — Backup Server Data - Authority: bitwarden.com - URL: https://bitwarden.com/help/backup-on-premise/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include Bitwarden Docker server files beyond its SQL backup,” DSE Security, https://update.dsesecurity.com/updates/include-bitwarden-docker-server-files-beyond-its-sql-backup/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.