如何在Linux中配置具体的文件系统快照计划

Linux配置计划快照核心是三步：先确认文件系统原生支持（Btrfs/ZFS）或LVM可用，再选匹配工具（Snapper/Timeshift/LVM脚本），最后绑定定时机制（systemd timer/cron/daemon），缺一不可。

Linux 中配置文件系统快照计划，核心不是“写个 cron 就完事”，而是先确认底层能力（Btrfs/LVM/ZFS）、再选对工具、最后绑定定时机制——三者错一个，快照就不可靠或根本创建失败。

确认你的文件系统是否原生支持快照

Btrfs 和 ZFS 是唯二在内核级支持快照的主流 Linux 文件系统；ext4/xfs 等不支持真快照，只能靠 LVM 或外部备份工具模拟。运行 df -T / 查类型，再用 btrfs filesystem show 或 zpool list 验证是否启用对应功能。若输出为空或报错，说明没启用或根本不是该文件系统——此时别硬套 btrfs subvolume snapshot，会直接失败。

• LVM 快照不依赖文件系统类型，但要求逻辑卷已存在且有足够剩余空间（vgdisplay 查 Free PE）
• Timeshift 虽支持 Btrfs 模式，但若根分区是 ext4，它只能退化为 rsync 增量备份，不是 COW 快照
• 云服务器（如 AWS EC2）的 EBS 快照由平台提供，与本地文件系统无关，无需配置内核级快照工具

Snapper：Btrfs 生产环境首选的自动计划方案

Snapper 并不是那种“又一个命令行工具”。它本质上是围绕 Btrfs 子卷打造的一套生命周期管理器，命名规则、清理机制以及与 systemd timer 的集成都已经内置好了。反过来看，手动用 btrfs subvolume snapshot 配合 cron 虽然也能做，但很容易因为时间戳冲突、残留快照越堆越多，或者权限配置出错，最后把整套策略拖到失效。

• 先确认子卷已注册配置：sudo snapper list-configs 输出中必须有 root/home 等项；若为空，运行 sudo snapper -c root create-config /
• 编辑 /etc/snapper/configs/root，关键参数必须显式开启：TIMELINE_CREATE="yes"，否则 timer 不会创建快照
• 保留策略按需调高：TIMELINE_LIMIT_HOURLY="24"（默认仅 10），避免刚生成就被覆盖
• 启用 timer：sudo systemctl enable --now snapper-timeline.timer，验证状态时注意 Next elapse 是否在 1 小时后，而非 immediate

Timeshift：新手友好但限制明确的图形化计划

很多人会把 Timeshift 的“自动快照”想当然地理解成 cron 在定时跑任务，但实际并不是这样，真正负责驱动它的是 timeshift-daemon.service。这套机制用在桌面环境，或者配置相对简单的服务器上，通常都挺合适。不过有两个硬性前提不能忽视：第一，备份位置必须是独立的挂载点，不能直接放在 /home 或 /；第二，它默认会跳过用户数据目录。偏偏后者最容易被漏看，结果就是不少人以为自己“备份了整个系统”，其实并没有。

• 首次运行 sudo timeshift 时，务必选择 BTRFS Snapshots 类型（若文件系统支持），而非 RSYNC；选错类型会导致快照体积暴增、恢复变慢
• 计划频率在 GUI 的 Settings → Schedule 里设置，但背后依赖 timeshift-daemon，需用 sudo systemctl is-active timeshift-daemon 确认服务已 running
• 排除路径修改必须写进 /etc/timeshift/timeshift.json 的 "exclude" 数组，格式为 "/var/log/**"，末尾不加斜杠，否则规则不生效
• 不要同时启用 Snapper 和 Timeshift 的 timeline 功能，二者都监听同一子卷时可能重复创建快照，填满 /.snapshots

LVM 快照轮换：需手动编排的轻量级方案

LVM 快照本身无自动清理机制，lvcreate -s 只创建单次快照，必须自己写脚本控制生命周期。常见错误是只创建不删除旧快照，或删除时未 umount 导致 lvremove 失败。

• 快照大小必须预估：用 iostat -x 1 60 观察 1 小时内写入量，快照 LV 至少预留同等空间，否则快照会立即失效（lvs 显示 snap% = 100）
• 轮换脚本必须包含原子操作：先 lvremove -f /dev/vg00/old_snap，再 lvcreate -L 2G -s -n new_snap /dev/vg00/lv_data，顺序颠倒会导致无快照可用窗口
• cron 执行前加锁：flock -n /tmp/lv-snap.lock -c "your_script.sh"，防止因脚本执行超时（如 IO 卡顿）导致多次并发运行
• 挂载测试快照后记得 umount，否则 lvremove 会报 device busy

真正容易被忽略的是验证环节：无论用哪种方案，都得定期手动检查快照是否生成、能否挂载、内容是否完整——尤其在磁盘空间紧张时，Snapper 可能静默跳过创建，Timeshift 的 daemon 可能因挂载点丢失而停摆，LVM 脚本可能因权限变更失效。自动化不等于免维护。