第一次把DBX跑起来，通常只要几条Docker命令。真正检验部署是否可靠的，是几周以后那次更新：容器换了，保存的连接还在不在；服务器换了，原来的凭据还能不能解开；新版本不适合，能否退回昨天的状态。
本文把DBX当作一个需要长期维护的VPS应用来部署。安装只是第一步，接着把程序版本、工作台数据和业务数据库备份分开，再做一次不覆盖原环境的恢复演练。命令都围绕独立的Compose项目，便于看清楚每一步影响什么。
三份东西，不要只备份其中一份
DBX程序可以重新拉取，Compose和环境文件可以重建部署，数据卷保存连接及工作台状态。它连接的PostgreSQL、MySQL等业务数据库，又在另外的位置。把这些混成一个“数据库备份”，恢复时就会发现少东西。
| 对象 | 保存什么 | 单独保留它还缺什么 |
|---|---|---|
| 镜像与版本记录 | 对应版本的DBX程序 | 连接、密码和工作台状态 |
| Compose与环境文件 | 端口、卷、入口密码等配置 | 实际数据卷内容 |
| 完整DBX数据卷 | 工作台数据及该部署使用的状态文件 | 目标数据库业务数据 |
| 业务数据库备份 | 目标库的结构和数据 | DBX工作环境与访问入口 |
如果另外配置了外部加密密钥文件，它也要纳入恢复材料。不要把密钥换成一个“新的更强的”就期待旧密文照常解开。密钥轮换和恢复是不同操作。
建一个名称稳定、路径明确的部署
下面固定使用Docker Hub的0.6.29。创建目录和入口密码：
mkdir -p ~/services/dbx/backups
cd ~/services/dbx
umask 077
printf 'DBX_PASSWORD=%s\n' "$(openssl rand -hex 24)" > .env
chmod 600 .env
compose.yaml：
name: dbx
services:
dbx:
image: t8y2/dbx:0.6.29
restart: unless-stopped
ports:
- "127.0.0.1:4224:4224"
environment:
DBX_PASSWORD: ${DBX_PASSWORD:?请设置入口密码}
DBX_DATA_DIR: /app/data
volumes:
- dbx-data:/app/data
stop_grace_period: 90s
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
volumes:
dbx-data:
运行docker compose config --quiet、docker compose pull、docker compose up -d。本机用ssh -N -L 14224:127.0.0.1:4224 your-user@your-vps进入，浏览器访问http://127.0.0.1:14224。如果使用宿主机Caddy提供HTTPS，上游仍是回环4224；若代理在容器内，需另按容器网络配置上游。
固定项目名dbx的好处，是卷名可预期。不要今天在一个目录启动，明天换目录再用不同项目名启动，然后误以为原连接消失。容器可以重建，但它必须重新挂载原来那份卷。
选择VPS时，备份空间也是配置的一部分。可以查看雨云当前服务器方案，把地域、可用磁盘和异地备份成本一起算进去。若主机已经足够，优先补齐恢复流程，比为了低负载工作台换更高配置实际得多。
先找出容器真正挂载的卷
不要凭目录名猜，直接查看当前容器：
container_id=$(docker compose ps -q dbx)
docker inspect --format '{{range .Mounts}}{{println .Type .Name .Destination}}{{end}}' "$container_id"
找到目标为/app/data的一行，确认类型是volume。下面把这个名称取到变量里，并验证它确实存在：
volume_name=$(docker inspect --format '{{range .Mounts}}{{if eq .Destination "/app/data"}}{{.Name}}{{end}}{{end}}' "$container_id")
test -n "$volume_name"
docker volume inspect "$volume_name" >/dev/null
如果用的是绑定目录，Name可能为空，这套命令就不适用；应备份实际绑定目录。这里故意让检查失败，而不是在目标不明确时继续打包一份空目录。
镜像信息也保存下来：
docker image inspect t8y2/dbx:0.6.29 \
--format '{{json .RepoDigests}}' > image-digests.json
镜像标签是方便阅读的名字，digest提供更具体的内容标识。备份记录里同时保留两者，回头查版本更容易。不同CPU架构也应记录，恢复到另一种架构前先核对镜像支持范围。
停止工作台，再备份完整卷
这个方法会造成短暂不可用，适合个人或小范围使用的DBX。先通知正在使用的人退出，再停止容器，避免在打包时应用继续改写自己的状态文件。
下面在同一个shell里执行，承接前面的volume_name。先拉取归档工具镜像，别等停机后才下载：
docker pull alpine:3.23
stamp=$(date +%Y%m%d-%H%M%S)
archive_name="dbx-data-$stamp.tar.gz"
docker compose stop dbx
if docker run --rm \
-v "$volume_name":/data:ro \
-v "$PWD/backups":/backup \
-e ARCHIVE_NAME="$archive_name" \
alpine:3.23 sh -c 'tar -czf "/backup/$ARCHIVE_NAME" -C /data .'; then
sudo chmod 600 "backups/$archive_name"
else
docker compose start dbx
echo '备份失败，已重新启动原服务；请检查磁盘与权限。'
exit 1
fi
docker compose start dbx
sudo tar -tzf "backups/$archive_name" >/dev/null
sudo sha256sum "backups/$archive_name" > "backups/$archive_name.sha256"
-C /data .包含隐藏目录，不只是dbx.db。归档可读、校验值存在，只说明文件基本完整；还没有证明其中的工作环境能启动。Compose、.env和密钥资料也要放进受保护的备份位置，限制权限，另存异地副本。不要把带凭据的归档放在网站静态目录里。
官方的数据安全说明专门提醒保留数据与加密密钥的配对关系。部分旧状态需要经过迁移，切换版本前应阅读当次说明。数据安全升级与迁移
恢复到新卷，别拿唯一的原卷做实验
选择刚才确认过的归档，创建一份全新的卷。以下仍在原部署目录操作：
restore_volume="dbx_restore_$stamp"
docker volume create "$restore_volume"
docker run --rm \
-v "$restore_volume":/data \
-v "$PWD/backups":/backup:ro \
-e ARCHIVE_NAME="$archive_name" \
alpine:3.23 sh -c 'tar -xzf "/backup/$ARCHIVE_NAME" -C /data'
docker run -d --name "dbx-restore-$stamp" \
--env-file .env \
-p 127.0.0.1:4225:4224 \
-v "$restore_volume":/app/data \
t8y2/dbx:0.6.29
它使用不同的卷和4225端口，不覆盖原工作台。如果原部署还有外部密钥、额外挂载或自定义环境变量，恢复实例也要按原样提供，不能只复制这条最小命令。
本机再开一个SSH转发：ssh -N -L 14225:127.0.0.1:4225 your-user@your-vps，访问http://127.0.0.1:14225。先确认登录和连接列表。如果要验证连接，应只让恢复实例接入专用测试数据库网络，或使用明确授权的只读目标。不要让复制出来的自动化任务、插件或其他副作用未经检查就恢复执行。
截图来自独立恢复实例，数据是虚构样例。恢复演练没有使用网站的业务数据库。
恢复验收不能停在“网页能开”。打开已保存连接，确认不需要重新手工输入所有凭据，再读一张样例表；重启恢复容器，再做一次。若需要重新补齐关键凭据，说明备份与恢复流程仍不完整。
验收完先停止恢复容器，记下结果。准备删除时只删除此次演练的容器和新卷，名称逐项核对；不要用广泛的volume prune来代替清理。
更新和回退，需要程序与数据一起考虑
更新前，先看发行说明，确认驱动、内部数据迁移、认证和路径是否变化。拉取新镜像后，不急着替换正式实例；有条件就用恢复副本试新版本，验证代表性连接和常用查询，再安排正式更新。
正式更新时，保留升级前备份。假如新版已经改写内部数据格式，直接把镜像标签改回旧版本可能不够，旧程序未必理解新数据。可靠回退是旧程序加升级前的数据副本，而不是让两个版本轮流打开唯一的一份卷。
DBX连接配置的加密导出适合迁移选定连接，但它不是整卷镜像，也不包含所有外部驱动和工作环境。换设备时可以使用这个功能；要恢复整台工作台，仍应核对卷、配置和密钥。配置导出与导入
三种容易误判的故障
更新后连接列表空了，先查挂载和项目名，不要马上重新建一遍连接。列表在但凭据无法使用，检查是否丢失密钥、换了数据目录或未完成迁移。网页502则先看应用是否启动和代理上游是否正确，不要把每种故障都归因于“升级不兼容”。
磁盘满也值得单独检查。卷里的驱动、临时文件、备份归档和容器日志都可能增长。日志轮转只约束标准输出日志，不会自动管理你的backups目录。设置保留周期时，至少留下一份已经成功恢复过的备份，而不是只留下最新时间戳。
**本文验证范围：**2026 年 9 月 30 日，在本地隔离 Docker 环境运行 DBX 0.6.29（ARM64）与 PostgreSQL 18.6，完成网页密码登录、保存连接、三行样例查询，以及数据库只读角色拒绝 UPDATE 的检查；停止 DBX 后备份完整卷，恢复到独立卷与端口，再次登录并使用保存的连接查询成功。本文没有在生产 VPS 安装 DBX；1Panel 点击安装、公网证书签发、MongoDB、文件数据库、批量导入导出和跨版本升级未作实测，相关步骤依据官方资料与部署原理说明。
最有用的运维记录不是“安装成功”，而是“这份归档在这个版本下恢复过，保存的连接可以重新查询”。下次换VPS时，有这条记录和对应文件，部署就不再依赖当初那个人还记得多少细节。