容器化MySQL冷备份需停容器后对Volume数据目录做快照或tar打包，热恢复则解压备份至清空的Volume或绑定目录并修复权限后启动新容器。
容器化 mysql 的冷备份与热恢复，不能靠“停容器再拷文件”这种粗暴方式实现——因为容器本身无状态、生命周期短暂，直接操作内部文件既不可靠也不可重现。真正可行的路径，是借助宿主机的持久化存储机制，尤其是 volume（卷），把 mysql 的数据目录（/var/lib/mysql）持久化到外部，并在此基础上设计备份与恢复流程。
Volume 是备份的前提，不是备份本身
MySQL 容器必须使用命名卷或绑定挂载，将数据目录映射到宿主机可访问的路径。否则容器一删，数据全丢，谈不上备份。
- 推荐用命名卷：启动时指定
-v mysql-data:/var/lib/mysql，Docker 自动管理底层存储位置，更安全、可迁移 - 若用绑定挂载（如
-v /data/mysql:/var/lib/mysql），需确保宿主机路径权限正确（MySQL 进程用户 uid/gid 匹配），且该路径不被其他进程占用 - 切勿在容器内直接修改 Volume 数据——所有操作应通过数据库客户端或宿主机命令行进行
冷备份：停服务 + 卷快照或文件拷贝
所谓“冷”，是指 MySQL 进程停止后操作数据文件，保证一致性。但停的是容器，不是整个宿主机；Volume 本身保持不动。
- 先安全停止容器：
docker stop mysql-container（触发 mysqld 正常关闭，刷盘、写 checkpoint） - 对 Volume 所在路径做快照（如 LVM、ZFS）或直接 tar 打包：
tar -czf mysql-backup-$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/mysql-data/_data . - 备份文件存到异地或对象存储（如 S3、MinIO），避免单点故障
- 注意：若用绑定挂载，路径更明确，备份命令可直接指向
/data/mysql
热恢复：不依赖容器状态，只还原数据 + 启动新实例
恢复不是“把备份解压回原容器”，而是“准备一份干净的数据目录，再用它启动一个新容器”。这才是容器化场景下的正确热恢复逻辑。
- 停止并删除旧容器（如有）：
docker rm -f mysql-container - 清空目标 Volume 或绑定目录（如
rm -rf /data/mysql/*），避免残留文件冲突 - 解压备份到该目录：
tar -xzf mysql-backup-20260525.tar.gz -C /data/mysql - 修复权限：
chown -R 999:999 /data/mysql（MySQL 官方镜像默认用 uid 999 运行） - 用相同配置启动新容器，数据即恢复完成：
docker run -d --name mysql-new -v /data/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=xxx -p 3306:3306 mysql:8.0
为什么这算“热恢复”？
恢复过程本身不需要原容器在线，也不需要原服务响应；只要备份文件可用、宿主机正常、Docker 引擎就绪，就能在几分钟内拉起一个带完整数据的新实例。业务中断时间取决于容器启动+MySQL 初始化耗时（通常 10–30 秒），远低于传统虚拟机级恢复。关键在于：Volume 抽象了存储，解耦了数据与运行时。
