Include Bitwarden Docker server files beyond its SQL backup

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 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 — 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.