飞牛应用数据怎么备份：容器卷、数据库和配置目录

备份照片和文档已经成了习惯，但跑在 NAS 上的那些服务——下载器、笔记、自动化、数据库——它们的数据还没人管。

这些数据丢了不一定可惜，但重建配置能让人抓狂。

应用数据藏在哪

Docker 应用的数据一般有三种位置：

绑定挂载（bind mount）：直接把宿主机目录挂进容器，比如 -v /mnt/存储空间/app/config:/config。数据就在那个目录里，看得见摸得着，最好备份。

命名卷（named volume）：由 Docker 管理，实际存在 /var/lib/docker/volumes/ 下面。备份要绕一下。

容器内部：没做任何挂载，数据跟着容器走，容器一删就没了。这是最糟的情况。

先摸清楚有哪些

docker ps -a
docker inspect 容器名 | grep -A5 Mounts

inspect 的输出里能看到每个容器挂了哪些目录、用的是卷还是路径。

养成习惯：部署新容器时，配置目录一律挂到存储空间上，不要用命名卷。

备份什么

• 配置文件：docker-compose.yml、各应用的 config 目录；
• 数据库：直接复制 SQLite 文件可能拿到不一致的状态，最好先导出；
• 图片视频等内容：跟着媒体库一起备份就行；
• 命名卷：用 docker run --rm -v 卷名:/data -v 备份路径:/backup alpine tar czf /backup/卷名.tgz -C /data . 这类方式导出。

数据库的特殊处理

SQLite 是最常见的：先停容器再复制文件最稳。热备份可以用 sqlite3 数据库 ".backup 备份文件"，能拿到一致的快照。

PostgreSQL、MySQL 这类，用它们自带的导出工具：

pg_dump -U 用户 数据库 > 备份.sql
mysqldump -u 用户 -p 数据库 > 备份.sql

直接复制数据文件，很有可能恢复不起来。

恢复的注意点

• 恢复前先停容器；
• 目录属主和权限要还原（容器里跑的应用可能是 uid 1000 之类的非 root 用户）；
• 配置里如果有写死的路径、IP，换了环境要改；
• 恢复后看日志，确认应用真的起来了。

备份频率

• 配置类：改动之后备份一次；
• 数据库：每天或者每天多次；
• 容器镜像：不用备份，重新 docker compose up 会拉。

常见的坑

只备份了数据，没备份 compose 文件：恢复时不知道端口、环境变量、挂载路径。

容器在跑就复制数据库：拿到损坏的文件。

命名卷忘了备份：容器删了，卷还在，但没人知道里面是什么。

恢复后权限不对：应用起不来，日志里一堆 permission denied。

小结

应用数据备份的关键是先搞清楚数据在哪，再决定备份方式。

一句纪律：新建容器时，配置目录一律挂到存储空间上——这样它天然就跟着 rsync 一起被备份了。