核心在于用命名卷实现数据与容器解耦，确保容器可销毁重建而数据持久留存；生产环境必须采用external命名卷、定期tar备份并验证恢复能力。
核心在于把数据从容器里“请出来”，让容器可随时销毁重建，而关键数据稳如磐石。生产环境的灾难恢复不靠运气，靠的是存储架构设计——卷怎么建、往哪挂、谁来管、坏了怎么换。
明确区分状态与无状态服务
这是所有恢复策略的起点。无状态服务（如 Nginx、API 网关）只管拉镜像、起容器；有状态服务（如 MySQL、Redis、RabbitMQ）必须依赖外部持久化机制。
- 无状态：备份只需存好镜像 + docker-compose.yml + 环境变量文件，5 分钟内可全量重建
- 有状态：必须确认数据是否真正落盘——不能只靠 -v /host/path:/data 这种绑定目录（易权限错、难迁移），优先用命名卷或 external 卷
- 检查方式：运行 docker volume ls 和 docker inspect 容器名 | grep Mounts，确认关键数据路径是否指向命名卷（如 app_db_data）而非宿主机绝对路径
用对卷类型：命名卷 + external 是生产标配
默认的匿名卷随容器消亡而消失；命名卷虽独立于容器，但 docker compose down -v 仍会删掉它——除非你主动声明它是“外人”。
- 在 docker-compose.yml 中为数据库等关键服务配置：
volumes:
db_data:
external: true - 这样即使误执行 down -v，Docker 也不会动这个卷，因为 Compose 明确放弃了管理权
- 首次部署前，需手动创建该卷：docker volume create db_data，再启动服务
- 若已有数据在默认命名卷中，可用 docker run --rm -v 原卷:/src -v 新external卷:/dst alpine cp -r /src/. /dst/ 迁移
备份不是“有就行”，而是“能验、能换、能跑”
备份文件躺在磁盘上 ≠ 数据可恢复。真正有效的备份必须满足三个条件：可验证、可隔离、可挂载。
- 卷备份推荐用临时容器 + tar：
docker run --rm -v db_data:/source -v $(pwd):/backup alpine tar -czf /backup/db_data_$(date +%Y%m%d).tar.gz -C /source . - 备份后立即验证：
docker volume create db_data_restore && docker run --rm -v db_data_restore:/dest -v $(pwd):/backup alpine sh -c "tar -xzf /backup/db_data_*.tar.gz -C /dest" && docker run --rm -v db_data_restore:/var/lib/mysql mysql:8.0 mysql --version - 不要只备份卷内容——同步备份 docker inspect 容器 输出、docker-compose.yml 及其引用的 env 文件，它们共同构成“可复现环境”的最小单元
恢复流程要分层，不指望一招翻盘
出问题时别慌着 up，先看损失面：是容器没了？卷还在？还是连卷都被清空了？对应不同层级的恢复动作。
- 容器异常退出，卷完好：直接 docker compose up -d，几秒内服务回来
- 卷被误删，但有近期 tar 备份：创建新卷 → 解压进新卷 → 修改 compose 文件指向新卷名 → up
- 卷和备份都丢了，但宿主机未重启：立即停写、卸载磁盘，用 extundelete 或 photorec 扫 /var/lib/docker/volumes/ 目录下残留 inode（成功率低，仅作最后尝试）
- 完全不可逆丢失：启用异地备份（如 NFS 挂载的远程目录、对象存储上传的 tar 包），走冷恢复流程——停服务 → 清残留 → 绑定备份目录为新卷 → 启动
