备份与恢复策略
约 900 字大约 3 分钟
Docker备份恢复运维
2026-03-20
1. 先分清该备份什么
Docker 环境里真正有价值的通常不是容器本身,而是容器外部挂载的数据、配置文件和部署描述。
建议至少区分这几类内容:
- 业务数据目录,比如数据库数据、仓库数据、上传文件目录。
- 服务配置文件,比如 Nginx 配置、Caddyfile、Gitea 配置、环境变量文件。
- 编排文件,比如 docker-compose.yaml、启动脚本、反向代理规则。
- 镜像版本信息,比如当前使用的镜像标签、构建方式和变更记录。
容器本体通常不需要单独备份,因为它本来就应该能通过镜像重新拉起。
2. 备份策略建议
配置与编排文件
这部分建议直接纳入 Git 管理,至少满足下面两点:
- 能追踪配置变更。
- 能快速恢复到某个稳定版本。
持久化数据目录
这部分建议采用定时任务做周期性归档,例如:
tar -czf backup-$(date +%F).tar.gz ./data ./config如果准备做成可长期运行的脚本,至少要加上保留策略和失败处理。例如:
#!/usr/bin/env bash
set -euo pipefail
backup_dir="./backup"
mkdir -p "$backup_dir"
archive="$backup_dir/backup-$(date +%F-%H%M%S).tar.gz"
tar -czf "$archive" ./data ./config ./compose.yaml
find "$backup_dir" -name 'backup-*.tar.gz' -mtime +30 -delete
echo "backup created: $archive"如果数据量较大,更适合使用 rsync、快照存储,或者对象存储做增量备份。
数据库类服务
数据库不要只做文件级复制,尽量结合逻辑备份一起做,例如 MySQL 的 mysqldump、PostgreSQL 的 pg_dump。逻辑备份便于做跨版本恢复和单表恢复。
3. 推荐保留层级
一个实用的思路是至少保留三层:
- 当日最近一次备份。
- 近 7 天的日备份。
- 近 4 周或近 3 个月的周备份。
如果是重要业务数据,再额外增加异地副本,避免宿主机损坏时只能依赖单点恢复。
4. 恢复前先做什么
在真正恢复前,建议先完成以下检查:
- 确认恢复目标是整机、单服务还是单目录。
- 核对备份对应的镜像版本和配置版本。
- 停止目标容器,避免恢复过程中继续写入数据。
- 先把当前目录做一次临时快照,避免恢复失败后无法回退。
5. 恢复步骤建议
一个稳妥的最小流程通常如下:
- 停止相关容器。
- 还原配置文件和 compose 文件。
- 还原数据目录。
- 按原版本拉起镜像。
- 做健康检查和功能验证。
例如:
docker compose down
tar -xzf backup-2026-03-20.tar.gz -C ./
docker compose up -d6. 备份策略最容易忽略的点
- 只备份数据,不备份配置,恢复时往往拉不起来。
- 只做备份,不做恢复演练,真正出问题时才发现备份不可用。
- 镜像直接用
latest,导致恢复时无法确定原版本。 - 权限和属主没有一起校验,恢复后容器无法访问挂载目录。
- 备份长期不清理,最后把宿主机磁盘占满。
7. 和升级流程的关系
准备做镜像升级、基础设施变更或大版本迁移前,最好先完成一次可验证的备份。相关说明见 12.镜像升级与发布流程。