Btrfs快照必须在同一子卷内操作，禁止跨子卷、挂载点或设备；命令格式为btrfs subvolume snapshot <source> <dest>，顺序写反或源非子卷将报错；推荐用snapper管理，配合btrfs send/receive实现异地备份。
直接上结论：Btrfs快照不能跨子卷、不能跨挂载点、不能跨设备；btrfs subvolume snapshot 命令顺序写反就会报 No such file or directory——不是路径不存在，是源子卷找错了。
确认快照前提：必须在同一子卷内操作
Btrfs快照本质是子卷克隆，设计上禁止跨边界。比如 /mnt/data 是独立挂载的子卷，而 / 是另一个，那从根目录执行 btrfs subvolume snapshot /mnt/data /backup 会报 Invalid cross-device link。这不是权限问题，是内核强制限制。
- 先查清楚目标路径属于哪个子卷：
btrfs subvolume list -a /或btrfs filesystem show - 快照源（
<source>）必须是已存在的子卷，btrfs subvolume list能列出来才算数，普通目录不行 - 目标父目录（如
/data/snapshots/）需提前mkdir -p创建，且挂载点有写权限
命令格式和常见错误：顺序、路径、只读控制
btrfs subvolume snapshot 的参数顺序是固定的：btrfs subvolume snapshot <source> <dest>。很多人记成“目标在前、源在后”，输成 btrfs subvolume snapshot /snap/my-snap /data，结果提示 /snap/my-snap: No such file or directory——其实是把快照名当源了，<source> 根本不存在。
- 正确示例：
btrfs subvolume snapshot /data /data/snap-$(date +%Y%m%d) - 加
-r创建只读快照：btrfs subvolume snapshot -r / /snap/root-$(date +%Y%m%d-%H%M)，避免误改污染原始状态 - 不加
-r默认可写，但修改它不影响原数据（COW机制保证），适合做临时测试环境
自动化快照别硬写cron脚本：优先用snapper
手动写 btrfs subvolume snapshot + cron 容易漏掉清理、命名冲突、时间戳错乱等问题。生产环境推荐用 snapper，它专为Btrfs设计，自带保留策略、自动清理、systemd timer集成。
- 安装后运行
sudo snapper -c root create-config /，会在/etc/snapper/configs/下生成配置，并创建/.snapshots子卷 - 编辑
/etc/snapper/configs/root，调高TIMELINE_LIMIT_HOURLY="24"等参数，避免默认只留10个导致覆盖过快 - 启用定时器：
sudo systemctl enable --now snapper-timeline.timer，它每小时检查并按策略创建快照 - 注意：如果系统同时跑 cron 和 systemd timer，可能重复创建快照，得关掉一个
快照不是备份：删原卷后快照还能用，但有前提
快照依赖底层 extent 共享，只要没执行 btrfs subvolume delete 且没触发极端空间回收（如 space_cache=v2 下反复写满又清空），快照内容就还在。但它本身仍是子卷，长期保留必须单独导出。
- 用户
rm -rf快照目录就真没了——它不是回收站 - 要异地保存或归档，得用
btrfs send+btrfs receive流式传输到另一设备 - 定期验证快照可用性：
ls /.snapshots/*/snapshot/看目录是否存在，再抽样cat一个配置文件确认内容完整
最常被忽略的一点：快照能防止误改，但防不了误删快照本身；能省空间，但不解决存储介质故障——所以快照必须配合定期 btrfs send 到外置设备才算闭环。
