很多自托管的人第一次丢数据，不是服务器被黑客端了，而是在某次"顺手升级镜像"后，容器起不来了，配置文件还在但数据库没了，或者干脆是目录挂错了。Docker 的易用性掩盖了一个事实：容器本身是"用完即焚"的临时进程，真正的身家性命全在数据持久化和升级策略上。这篇文章把 storage 的三种形态、备份恢复、双实例零停机更新这三件事讲透，每一节都对应一个会真实踩到的坑。
一、三种挂载，先分清它们的花费与用途
Docker 提供三种持久化手段，很多人混着用导致数据散落各处。第一种 bind mount 把宿主机的某个目录直接映射进容器，改动即时、肉眼可见，适合配置文件（你把 compose 目录里的 ./data 挂进去）；第二种 named volume 由 Docker 管理，存放在 /var/lib/docker/volumes/ 下，迁移和复制最方便，适合数据库这类"一串文件"；第三种 tmpfs 只写在内存，重启即失，只适合缓存、会话这类可重建数据。判断标准一句话：配置文件用 bind、重型数据用 named volume、临时数据用 tmpfs，别反着来。
bind 和 volume 最大的差异在"谁拥有权限"。容器内进程以非 root 写入 bind 目录时经常报 Permission denied，根因是 UID 不匹配；named volume 会在首次使用时空目录拷贝镜像里已有的目录所有权和内容，所以很多"明明镜像带默认配置却什么都没有"的怪病，根源正是错用了 bind 而没给宿主目录正确的属主。
二、定位数据的"家"：先把 storage 地图画出来
部署任何应用前，先花两分钟确认它把状态写在哪。命令层可以直接看：docker inspect <容器> 的 Mounts 段会列出所有挂载点与目标路径；更省事的是在 compose 里把所有需要保留的路径显式声明，并把 restart: unless-stopped 写死。这里有一个高频事故：某些镜像自身就带一个未覆盖的卷（如 SQLite 数据库写在镜像内层），如果你没有把镜像层里的数据目录显式挂出来，升级镜像时旧数据层会被整体替换，等于"静默清库"。确认手段是升级前先 docker diff 看容器内层到底改过哪些文件，凡是出现不该出现的数据路径，就该补一条显式挂载。
三、备份：卷级别的热备份，而不是"等停机拷贝"
备份的最小可恢复单元是"数据目录 + 对应版本的应用配置"，两样缺一不可。对数据库这类一致性敏感的服务，最稳的是用镜像自带的导出命令（如 mysqldump、pg_dump）备份到宿主机或异地；对普通的卷级数据，可以借助一个临时容器做一次性打包，避免在业务容器里装多余工具：
docker run --rm -v app_data:/source -v /srv/backup:/target alpine \
tar czf /target/app_$(date +%F).tar.gz -C /source .
这条命令用 alpine 把命名卷 app_data 打成带日期的 tar 包。真正重要的是把"每天备份 + 保留 N 份 + 异地一份"做成可审计的计划：本地保留 7 份、加密后再推到另一个 VPS 或对象存储。如果只有一份"备份"还留在同一台机器上，那它不是备份，只是给硬盘摔坏前的自己一点心理安慰。
四、恢复：备份的价值在恢复那天兑现
备份方案好不好的唯一标准是能不能在陌生机器上五分钟内完整还原，所以要周期性演练。恢复流程一般是：docker volume create 建新卷 → 用临时容器把 tar 解回去 → 按原 compose（数据路径一致）重新 docker compose up -d → 确认应用能读到数据、版本与备份时一致。最容易在恢复时翻车的两点：一是解包后目录层级多套了一层（tar 时 -C /source . 的问题），导致 docker 找不到数据文件；二是把旧应用大版本的数据直接铺给新大版本镜像，迁移要先看官方 upgrade 文档，而不是直接硬塞。
五、零停机升级：健康检查 + 顺序滚动，而不是一把梭 down
"down && up -d"式的升级会造成停机，且一旦新镜像起不来就是回天乏术。要做得优雅，分四步：先在 compose 里给服务定义 healthcheck，让 Docker 知道什么才算"真正可用"（不是进程活着，而是 TCP/HTTP 探活通过）；然后 docker compose up -d --no-deps 只升级目标服务，利用内置的滚动策略先起新副本、等健康检查通过再切换；升级后立即用 docker compose ps 看健康状态；一旦异常，一分钟内用 docker compose up -d --rollback 回到上一版镜像。
这里值得多写一句：healthcheck 同时救回"数据库容器比应用容器晚启动"的经典问题。用 depends_on 的语义不只是"先起哪个容器"，配合 condition: service_healthy，能让应用容器严格等待数据库真正可连之后再启动，彻底去掉"数据库还没就绪应用就崩着反反复重启"的心跳式假死。
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 10s
timeout: 3s
retries: 5
六、更新失败后的"后悔药"要提前备好
任何升级都假设过"可能要回滚"，所以回滚的每一个前置条件要在升级前就满足：旧镜像 tag 明确固定成某版本（不要用 latest，否则回滚时 latest 已经指向新版本，你连旧镜像都拉不回来）；数据目录在升级前已做一次快照备份；compose 里固定 image: xxx:版本号，让 rollback 有明确目标。数据和镜像版本是一对绑定关系，回滚到旧镜像时，如果数据库 schema 已经随新版升级了，那就不能简单回退代码——这一点要在升级前读官方迁移说明，把它写进升级前的 check 清单里，而不是等出事才到处翻。
七、把"存储+升级"沉淀成一套可重复的流程
到这里可以收敛成一句话：数据形态决定挂载方式，挂载方式决定备份方法，备份方法决定你睡觉时敢不敢点升级。每一步都向下限制下一步。把命名卷、健康检查、固定版本、备份脚本这四个习惯一次性固定到所有 compose 里，之后每一次 up -d 都是一次可回滚、可恢复、可解释的操作，而不是一次"赌运气"。自托管的上限，往往不是能跑多少个服务，而是敢对多少个服务动刀还不会出事。
