怎么利用Docker持久化存储实现容器化数据库的冷备份实战

冷备份关键在于停稳后精准备份持久化路径。需确认数据库真正关闭、只备份宿主机上的卷或绑定目录、保持重启策略一致，并对Neo4j等特殊数据库覆盖多路径。

冷备份要可靠，关键不是“怎么停容器”，而是“停稳之后备份什么、怎么备”。Docker 本身不提供备份功能，它只负责让数据库静止、让数据落盘、让持久化路径可访问。真正的冷备动作发生在宿主机上——对卷或绑定目录做文件级复制。

确保数据库真正静默再备份

docker stop 不等于数据库已关机。PostgreSQL、MySQL 等会在收到 SIGTERM 后执行事务清理、刷盘、关闭监听，这个过程可能持续数秒甚至更久。

• 用 docker stop --time=30 mydb 显式延长等待时间，避免强制 kill 中断写入流程
• 停止后立即检查日志：docker logs mydb | tail -20，确认出现 database system is shut down 或 mysqld: Shutdown complete 类终态提示
• 不要仅凭 docker ps 显示 “Exited” 就开始拷贝——进程退出 ≠ 数据已安全写入磁盘

只备份持久化路径，绝不碰容器可写层

Docker 容器的可写层（container layer）是临时的，随 docker rm 永久消失。冷备必须绕过容器，直击宿主机上的真实数据位置。

• 若用 命名卷（推荐）：运行 docker volume inspect mydb_data，找到 Mountpoint（如 /var/lib/docker/volumes/mydb_data/_data），对该路径做 rsync 或 tar -czf
• 若用 绑定挂载（bind mount）：备份你明确指定的宿主机目录（如 /nas/mysql/data），该路径由 -v /nas/mysql/data:/var/lib/mysql 定义
• 禁用 docker export 和 docker commit：它们捕获的是容器运行时状态，无法反映持久化数据的一致性，冷备中完全无效

备份前后保持服务策略连续性

人为执行“停—备—启”容易遗漏重启，导致服务长期离线。应把 restart policy 纳入流程闭环管理。

• 备份前记录原策略：docker inspect mydb --format='{{.HostConfig.RestartPolicy.Name}}'
• 更稳妥做法：先 docker update --restart=no mydb，再 docker stop mydb，完成备份后执行 docker update --restart=unless-stopped mydb && docker start mydb
• 这样既避免误删容器后自动重启干扰备份，又确保恢复后服务行为与之前完全一致

Neo4j 等特殊数据库需额外注意路径覆盖

Neo4j 默认将图数据、日志、配置分别存于 /data、/logs、/conf。只挂载 /data 不够，冷备需全部覆盖。

• 启动时建议三路挂载：-v neo4j-data:/data -v ./logs:/logs -v ./conf:/conf
• 冷备时同步备份这三个宿主机路径，否则恢复后可能缺失日志轮转规则或自定义配置
• 若用 neo4j-admin backup 做热备，那是另一套机制；冷备场景下，仍以文件系统拷贝为准，且必须在服务完全停止后进行