关键在于确保备份时数据一致、恢复后直接可用：一选命名卷（docker volume create），二停写或冻结状态（如pg_dump、flush tables或docker pause），三用只读临时容器打包（docker run --rm -v vol:/data:ro -v /backup:/backup alpine tar -czf /backup/xxx.tar.gz -c /data .）。
用容器卷备份和恢复持久化数据，关键不是“怎么挂载”，而是“怎么确保备份时数据不乱、恢复后能直接用”。核心动作就三步：选对卷类型、停写或冻结状态、用只读容器打包归档。
优先用命名卷，别碰匿名卷和绑定挂载存业务数据
命名卷（Named Volume）是 Docker 官方推荐的持久化方式，由 Docker 自己管理路径和权限，删容器不会丢数据，迁移也安全。
- 创建：docker volume create app-data
- 挂载进容器（如 PostgreSQL）：
docker run -d --name pg-db -v app-data:/var/lib/postgresql/data -e POSTGRES_PASSWORD=123456 postgres:15 - 避免直接写容器内路径（比如
/var/lib/postgresql/data），也不要用匿名卷——它没名字、难追踪、删容器时可能被连带清理 - 绑定挂载（Bind Mount）适合配置文件或日志，但不适合核心数据库目录：宿主机路径一改、权限一错，容器就起不来
备份前必须让数据“静止”或“一致”
运行中直接 tar 数据卷，大概率得到损坏备份。尤其数据库类应用，得靠工具或机制保证一致性。
- PostgreSQL 用
pg_dump导出逻辑备份：pg_dump -U postgres mydb > backup.sql - MySQL 可临时锁表：
FLUSH TABLES WITH READ LOCK;→ 备份 →UNLOCK TABLES; - 如果底层存储支持快照（ZFS/LVM/云盘），优先启用卷级快照——比文件打包更原子、更快、更可靠
- 实在无法停服又没快照？至少暂停容器：
docker pause my_container，再执行备份操作
用只读临时容器安全打包，不碰宿主机 volume 目录
别手动去 /var/lib/docker/volumes/ 下复制文件——权限混乱、易误删、还可能破坏 Docker 内部状态。
- 正确做法：启动一个轻量容器，把卷只读挂载进去，再用
tar打包 - 示例命令：
docker run --rm -v app-data:/data:ro -v /backup:/backup alpine tar -czf /backup/appdata-$(date +%Y%m%d).tar.gz -C /data . -
:ro强制只读，杜绝误写；--rm自动清理；-C保证路径还原准确；压缩格式用.tar.gz节省空间
恢复不是解压完就结束，必须验证可用性
有 backup.tar.gz ≠ 能恢复成功。没验证过的备份等于没备份。
- 先检查归档完整性：
tar -tzf appdata-20260807.tar.gz | head -10 - 在测试环境走一遍完整流程：新建命名卷 → 启动空容器挂载该卷 → 解压备份到卷内 → 启动业务容器 → 连接查询数据是否可读
- 把备份脚本加进
cron（比如每天 2 点全量），再搭配rsync --link-dest或Restic做增量，长期才可控
