1. 先分清该备份什么

Docker 环境里真正有价值的通常不是容器本身，而是容器外部挂载的数据、配置文件和部署描述。

建议至少区分这几类内容：

1. 业务数据目录，比如数据库数据、仓库数据、上传文件目录。
2. 服务配置文件，比如 Nginx 配置、Caddyfile、Gitea 配置、环境变量文件。
3. 编排文件，比如 docker-compose.yaml、启动脚本、反向代理规则。
4. 镜像版本信息，比如当前使用的镜像标签、构建方式和变更记录。

容器本体通常不需要单独备份，因为它本来就应该能通过镜像重新拉起。

2. 备份策略建议

配置与编排文件

这部分建议直接纳入 Git 管理，至少满足下面两点：

1. 能追踪配置变更。
2. 能快速恢复到某个稳定版本。

持久化数据目录

这部分建议采用定时任务做周期性归档，例如：

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. 推荐保留层级

一个实用的思路是至少保留三层：

1. 当日最近一次备份。
2. 近 7 天的日备份。
3. 近 4 周或近 3 个月的周备份。

如果是重要业务数据，再额外增加异地副本，避免宿主机损坏时只能依赖单点恢复。

4. 恢复前先做什么

在真正恢复前，建议先完成以下检查：

1. 确认恢复目标是整机、单服务还是单目录。
2. 核对备份对应的镜像版本和配置版本。
3. 停止目标容器，避免恢复过程中继续写入数据。
4. 先把当前目录做一次临时快照，避免恢复失败后无法回退。

5. 恢复步骤建议

一个稳妥的最小流程通常如下：

1. 停止相关容器。
2. 还原配置文件和 compose 文件。
3. 还原数据目录。
4. 按原版本拉起镜像。
5. 做健康检查和功能验证。

例如：

docker compose down
tar -xzf backup-2026-03-20.tar.gz -C ./
docker compose up -d

6. 备份策略最容易忽略的点

1. 只备份数据，不备份配置，恢复时往往拉不起来。
2. 只做备份，不做恢复演练，真正出问题时才发现备份不可用。
3. 镜像直接用 latest，导致恢复时无法确定原版本。
4. 权限和属主没有一起校验，恢复后容器无法访问挂载目录。
5. 备份长期不清理，最后把宿主机磁盘占满。

7. 和升级流程的关系

准备做镜像升级、基础设施变更或大版本迁移前，最好先完成一次可验证的备份。相关说明见 12.镜像升级与发布流程。

版权所有

版权归属：Ailurus-2233

许可证：署名 4.0 国际 (CC-BY-4.0)

贡献者: WangZhiYu

上一页持久化文件权限问题

下一页镜像升级与发布流程