前阵子 Bitwarden 客户端升到 2026.7 之后，自建 Vaultwarden 的圈子里结结实实慌了一波：Windows 桌面端、浏览器扩展打开密码库一片空白，GitHub 上的反馈帖光评论就几十条。GitHub就在昨天，还有安卓用户在知乎发帖，说手机 App 升级后所有密码“凭空消失”。知乎好在最后查下来，密码并没有丢——服务端数据都在，只是新版客户端和服务端接口没对上，升级服务端到 1.37.1 再重新登录就回来了。GitHub
但这件事真正该提醒自建用户的，不是"客户端升级要小心"，而是一个更扎心的问题：如果你的密码库哪天真的没了，你手里还有第二份吗？
对绝大多数 NAS 和轻量服务器玩家来说，Vaultwarden 部署完就再也没碰过，全部密码就躺在某块硬盘的一个 sqlite 文件里。硬盘坏了、手滑删了、升级翻车了，密码就是真的没了。今天这篇就把官方文档、社区实践和这次事件的教训揉在一起，讲清楚三件事：哪些文件必须备份、怎么备份才不是自欺欺人、怎么用一次演练证明备份真的有用。
先说清楚：你的密码库到底由哪些文件组成
Vaultwarden 的所有数据都在一个 data 目录里（Docker 部署的话就是你挂载的那个数据卷），官方 Wiki 把它拆得很清楚：
必须备份的有两类。一个是 db.sqlite3，主数据库，你的账号、条目、组织关系、设备信息全在里面，这是命根子。另一个是 attachments 目录，密码条目里的附件文件不存数据库，单独放在这里，体积可能不小但同样丢了就没了。
建议备份的也有两类。config.json 存着你在管理面板里改过的所有配置，注意里面有明文敏感信息，比如管理员 token 和 SMTP 密码，所以备份它可以，但传网盘之前最好加个密。GitHub还有 rsa_key 开头的几个文件，用来签登录令牌，丢了不会丢密码，但所有人会被强制登出，发出去的邀请链接也会失效。
至于 sends 目录（Send 功能的临时文件）和 icon_cache（网站图标缓存），官方标注可备可不备，一般用户可以直接跳过，省点空间。
这里还有一个很多人想当然的误区：NAS 玩家特别爱用快照，觉得"我群晖/飞牛有快照，等于有备份"。官方 Wiki 专门提醒过：不要依赖文件系统或虚拟机快照作为备份手段。GitHub原因很简单，快照恢复是整机级别的粗粒度操作，真出事的时候，你大概率不敢为了一个密码库把整台 NAS 回滚，而且快照本身和源数据在同一块盘上，盘一挂，快照跟着陪葬。快照是后悔药，异地备份才是保险。
为什么直接复制文件不算备份
不少人的"备份"方式是偶尔手动 cp 一份 db.sqlite3 到别的目录。这个动作在服务运行期间做，是有一定损坏风险的。SQLite 是 WAL 模式，写入先进 -wal 日志文件，运行中直接拷贝主文件，可能拷到一个事务写了一半的状态。官方给的正确姿势有三个：
第一个是用 sqlite3 命令行工具的 .backup 命令，它走 SQLite 的在线备份接口，服务不停机也安全；第二个是 VACUUM INTO，备份的同时顺手压缩数据库，多花点 CPU 但文件更小；第三个最省事，从 1.32.1 版本开始 Vaultwarden 内置了备份命令，容器里直接执行 docker exec -it vaultwarden /vaultwarden backup 就行，连 sqlite3 工具都不用装——因为官方 Docker 镜像里本来就没有 sqlite3 和 cron，定时任务得配在宿主机上。GitHub
三套方案，按勤快程度自己选
方案一，极简党：宿主机加一条 crontab，每天凌晨跑一次内置备份命令，把生成的数据库文件丢到另一个目录。五分钟搞定，缺点是只覆盖了数据库，attachments 和配置文件还得自己记得另外拷，而且没有异地副本。适合"先有个心理安慰，回头再完善"的起步阶段。
方案二，推荐大多数人选的：社区工具 vaultwarden-backup，GitHub 上一千八百多颗星，还在持续维护，也是官方 Wiki 收录的第三方备份示例之一。它是个独立 Docker 容器，帮你把数据库、config.json、rsa_key、attachments、sends 一次性打包，通过 rclone 推到你指定的远端——OneDrive、坚果云 WebDAV、对象存储都行，还支持备份成功失败的邮件和 ping 通知。GitHub飞牛私有云论坛对 NAS 用户来说，配置一次以后就彻底无感，这是把“定期自动+异地副本”两条官方要求一步到位的方案。GitHub唯一要注意的是配置文件里有明文 token，远端存储别选完全不放心的。
方案三，已有备份体系的：如果你本来就用 restic、rustic 或者群晖 Hyper Backup 之类做整机/目录级备份，直接把 Vaultwarden 的 data 目录纳入进去也行，增量备份对大附件友好。但记得给数据库这一步做特殊处理：要么备份前触发一次内置 backup 命令生成一致性快照文件，要么确保备份时机和写入错峰，别直接裸拷运行中的 sqlite。
最后一步才是灵魂：演练一次恢复
官方 Wiki 里有句话值得抄下来贴在 NAS 上：建议定期走一遍恢复流程，验证备份真的可用。GitHub备份圈的老话也是一样的——没恢复过的备份等于没有备份。
演练流程并不复杂：先把 Vaultwarden 容器停掉，把备份文件替换回 data 目录，再启动容器，打开网页版确认条目都在。这里面藏着一个很容易踩的坑：如果你恢复的是 .backup 或 VACUUM INTO 生成的数据库文件，替换前必须先删掉目录里原有的 db.sqlite3-wal 文件，否则 SQLite 可能拿着旧的 WAL 日志去恢复新数据库，直接损坏。GitHub另外演练之前，一定先把当前的 data 目录整体留一份，万一演练翻车，你还有退路。
半年演练一次就足够了。真到了硬盘报废那天，你会感谢今天花了二十分钟的自己。
收尾三件事
第一，如果你还停在 1.37.0 之前的版本，除了兼容新版客户端，1.37.0 还一次修了 8 个中危漏洞，包括图标接口的 SSRF 和跨组织访问问题，这个更新真的不能再拖。GitHub1.37.1 修复了邀请链接的问题，是目前建议停留的版本。GitHub第二，备份配置完成之后，给自己设个半年一次的恢复演练提醒。第三，下次再遇到客户端大版本更新后密码库显示异常，先别慌着重建——多半是服务端版本没跟上，密码还在数据库里躺着。
密码管理器这东西，平时存在感为零，出事就是全账号连坐。自建的意义是数据握在自己手里，但"握在自己手里"的另一半含义是：这块盘只有你自己负责。
