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 的“自动快照”实际由 timeshift-daemon.service 驱动，不是 cron job。它适合桌面环境或简单服务器，但有两个硬约束：备份位置必须是独立挂载点（不能是 /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 脚本可能因权限变更失效。自动化不等于免维护。
