mysql容器备份需确保：容器内置mysqldump工具、数据库允许本地连接、备份路径挂载宿主机持久化目录，再通过docker exec调用mysqldump命令执行。
直接使用 docker exec 无法“实现”备份与恢复——它只是执行命令的工具，真正起作用的是你让它运行的数据库原生命令（如 mysqldump、pg_dump、mongodump 等）。关键在于：容器必须已安装对应客户端工具，且备份逻辑需适配容器环境（如权限、网络、存储路径）。
备份前必须确认的三件事
1. 容器内是否具备备份工具
MySQL 容器默认一般带 mysqldump，PostgreSQL 官方镜像含 pg_dump，MongoDB 则需确认是否含 mongodump（Alpine 版常不带，需自定义镜像或用 mongo:latest）。
2. 数据库是否允许本地连接
多数数据库默认只监听 localhost 或 127.0.0.1，而 docker exec 进入容器后，localhost 指向容器自身。只要服务在容器内运行且端口未被绑定限制，通常可直连 127.0.0.1:3306 等。
3. 备份目标路径是否可写且持久化
不要把备份文件写到容器临时文件系统（如 /tmp），否则容器重启即丢失。应挂载宿主机目录（如 -v /backup:/backup），再将 dump 文件存入该目录。
MySQL 容器在线备份示例（推荐方式）
假设容器名为 mysql-prod，数据库名 appdb，用户名 backupuser，密码 pass123，宿主机备份目录为 /data/backups：
- 确保启动容器时已挂载：
docker run -v /data/backups:/backup ... mysql:8.0 - 执行备份：
docker exec mysql-prod sh -c 'mysqldump -u backupuser -ppass123 appdb > /backup/appdb_$(date +\%Y\%m\%d_\%H\%M\%S).sql' - 注意单引号避免宿主机提前解析
$()；密码明文有风险，建议改用配置文件或--defaults-extra-file
PostgreSQL 容器备份与恢复要点
PostgreSQL 更依赖环境变量和信任配置：
- 备份命令：
docker exec postgres-prod pg_dump -U postgres -d myapp -F c -f /backup/myapp_$(date +\%Y\%m\%d).dump（-F c生成自定义格式，支持并行恢复） - 恢复前需先创建空库：
docker exec postgres-prod psql -U postgres -c "CREATE DATABASE myapp_restored;" - 再执行恢复：
docker exec -i postgres-prod pg_restore -U postgres -d myapp_restored （注意 <code>-i表示从 stdin 读取） - 若提示
peer authentication failed，说明 pg_hba.conf 未允许local连接，需进容器修改或用PGPASSWORD=xxx环境变量绕过
通用安全与可靠性建议
避免密码硬编码：使用 Docker secrets（swarm）、docker compose --env-file，或数据库专用配置文件挂载进容器。
验证备份有效性：定期抽取备份文件，在测试容器中执行恢复并检查表结构/数据量，不能只看文件生成成功。
不要依赖 docker commit 做备份：它保存的是容器当前状态（含临时文件、日志、进程），不是数据库一致快照，恢复后极可能损坏或无法启动。
考虑一致性：MyISAM 表需加 --lock-all-tables；InnoDB 可用 --single-transaction 实现无锁逻辑备份；MongoDB 需配合 --oplog 和副本集才能保证时间点一致性。
