《Docker 运维入门实战：备份不是存过，是恢复出来过——数据卷与数据库备份演练》

关键词：备份、恢复演练、数据卷、mysqldump、Docker

上一篇给集群装上了眼睛，能第一时间看见出事。但看见不等于能救：机器真没了、数据卷真坏了的时候，唯一的问题是——东西还能不能找回来。今天补上这最后一块保命的：备份。而且先把标准定死：备份的完成标准不是"存过一份"，是"真的恢复出来过"。没做过恢复演练的备份，只能算一个心理安慰文件。

先分清要备什么。回到状态外置那篇的结论：副本是无状态的，真正要保的全在三个地方——数据卷里的文件、数据库里的数据、配置（Compose 文件、config、secret 清单）。镜像不用备，它随时能从代码重新构建出来。备错了对象，是新手最常见的浪费。

一、数据卷备份：把卷打包带走

文件类数据（上传文件、共享数据）住在数据卷里。备份的办法很朴素：起一个临时容器，把卷挂上，打包成一个带日期的 tar 文件，完事删掉临时容器：

docker run --rm \
  -v myapp_uploads:/data:ro \
  -v /backup:/backup \
  alpine tar czf /backup/uploads-$(date +%F).tar.gz -C /data .

几个要点：源卷以只读（:ro）挂载，别让备份动作改到原数据；文件名带日期，一眼能分清新旧；备份文件落在宿主机 /backup 目录——但这还不算完，原因看第四节。

数据库不在卷里裸存文件备份（直接拷数据库的数据目录容易拷到一半写一半的状态），数据库用它自己的导出工具，下一节单独说。

二、数据库备份：用导出，别拷目录

以 MySQL 为例，用 mysqldump 把库导成一个 SQL 文件：

docker exec myapp_db mysqldump -u root -p"$DB_ROOT_PASSWORD" myapp \
  > /backup/myapp-db-$(date +%F).sql

这样导出的是一致的逻辑备份：恢复时把 SQL 灌回一个空库即可，不依赖原容器的文件布局。PostgreSQL 同理换成 pg_dump。节奏上一般每天一次就够小项目用；保留策略定简单点：最近 7 天的都留，再老的自动删，别让备份把磁盘吃掉（监控那篇刚讲过磁盘写满的坑，别在备份上重演）。

把命令写成脚本、挂上定时任务（宿主机 crontab 每天凌晨跑一次），备份这件事才算脱离了人手——靠记得住的人工备份，忘一次就断一档。

三、恢复演练：新建一套空的，把备份灌回去

这是全文最重要的一节。找个不影响现网的时机（练习环境、或另一台机器），全程演练一遍：

# 1. 新建一个空卷、起一个空数据库容器
docker volume create myapp_uploads_restore
docker run -d --name db_restore -e MYSQL_ROOT_PASSWORD=... \
  -e MYSQL_DATABASE=myapp mysql:8

# 2. 把最近的数据库备份灌回去
cat /backup/myapp-db-2026-11-07.sql | docker exec -i db_restore \
  mysql -u root -p... myapp

# 3. 把文件备份解回空卷
docker run --rm -v myapp_uploads_restore:/data -v /backup:/backup \
  alpine tar xzf /backup/uploads-2026-11-07.tar.gz -C /data

# 4. 用这套恢复出的卷和库启动一份服务，打开页面验证数据在不在

验证不能只看"命令没报错"：真的登进恢复出的服务，看一条老数据、开一张老图片，都在，才算演练通过。顺手把全程耗时记下来——这就是你的恢复时长（RTO），出真事时心里有数。演练完把带 _restore 的临时容器和卷删掉，别和现网混淆。

四、备份放哪：至少有一份不在这台机器上

备份和源数据躺在同一台机器、同一块盘上，机器没了就一起没，等于没备。最低配的异地：每天打包后自动同步一份到另一台机器或云对象存储（rsync、对象存储的命令行工具都能做），形成"本地一份 + 异地一份"。常说的 3-2-1 原则（3 份副本、2 种介质、1 份异地）是这个思路的完全版，小项目先做到"有一份异地"就及格。

还有一样常漏的：配置和 secret 也要在备份清单里。Compose 文件、stack 文件进代码仓库就是备份；secret 不能直接导出明文留档，但要留一份"有哪些 secret、各自怎么重新创建"的清单（内容通过密码管理工具另行保管），否则数据恢复出来了，服务却因为缺密码起不来。

五、三个新手最容易踩的坑

1. 只备不恢复
备份脚本跑了半年，第一次用是真出事那天，结果发现文件损坏、格式不对、少备了关键卷。恢复演练至少做一次，之后每次改备份方式再做一次。

2. 备份任务静默失败
定时任务挂了、磁盘满了、密码改了导出失败，没人知道，备份停在三个月前。备份脚本要检查上一步的退出码，失败就发一条告警——监控那篇的两条告警之外，这是最值得加的第三条。

3. 把备份当版本库
指望从备份里找"上周误删的那条数据"，结果备份是全量快照、恢复要整库回滚。备份管的是"整套没了能重建"，单条数据的找回是回收站、软删除那一层的事，两件事别混。

结语

到这一篇，从单机跑起第一个容器开始的这条线正式闭环：编排、数据卷、网关、日志与健康检查、滚动更新、资源限制、CI/CD、多副本、状态外置、Swarm 集群、secret 与 config、监控、备份与恢复——每一环都补上了。下一篇不加新零件了，做一次全链路复盘：把这些环节按"一次代码提交，从流水线到集群更新、到监控确认"的顺序完整串一遍，看看它们拼在一起长什么样。