快照功能依赖底层文件系统或逻辑卷管理器：btrfs、zfs、lvm原生支持，ext4/xfs不支持；需先用lsblk -f或df -T确认根分区类型，再选择snapper、lvcreate -s或rsync等对应方案。
快照不是文件系统自带功能，得看底层是否支持
Linux内核本身不提供通用快照能力，btrfs、zfs、lvm才是真正的支撑层。你用ext4或xfs直接跑btrfs subvolume snapshot会报错——命令根本不存在；而lvcreate --snapshot对非LVM卷也无效。别在错误前提下折腾配置。
先确认你的根分区类型：lsblk -f看FSTYPE列，或df -T /。如果是btrfs，优先走snapper；如果是LVM卷（vg00/lv_root这类路径），就用lvcreate -s；若只是普通ext4，那就别硬套“快照”概念，改用rsync --link-dest或timeshift这类逻辑备份方案。
btrfs subvolume snapshot 命令写反就会失败
btrfs subvolume snapshot的参数顺序不能颠倒：必须是source在前、dest在后。输成btrfs subvolume snapshot /snap/my-snap /data，报错/snap/my-snap: No such file or directory——不是目标路径没建，而是系统把/snap/my-snap当成了源子卷，但它压根不存在。
- 源必须是已挂载的子卷：
btrfs subvolume list /能列出的才算数，普通目录不行 - 目标父目录（如
/mnt/btrfs/snapshots/）要提前mkdir -p，且挂载点有写权限 - 加
-r创建只读快照：btrfs subvolume snapshot -r /etc @etc-20260710，避免误改污染原始状态 - 不加
-r默认可写，但修改它不影响原数据（COW机制保证），适合临时测试
用 snapper 管理 btrfs 快照比手写 cron 可靠得多
手动写cron调btrfs subvolume snapshot容易出问题：时间戳格式错乱、命名冲突、旧快照不清理、没检查空间是否溢出。生产环境强烈建议用snapper，它专为btrfs设计，自带保留策略和systemd集成。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 安装后运行
sudo snapper -c root create-config /，会在/etc/snapper/configs/root生成配置，并自动创建/.snapshots子卷 - 编辑配置文件，把
TIMELINE_CREATE="yes"打开，并设TIMELINE_LIMIT_HOURLY="24"（默认只留10个，不够用） - 启用定时器：
sudo systemctl enable --now snapper-timeline.timer，它每小时触发一次 - 注意别同时开
cron和snapper-timeline.timer，否则重复创建快照，空间很快耗尽
恢复时最常卡在“卸载不了 /etc”
发现配置被篡改后想回滚，执行btrfs subvolume snapshot快照没用——快照只是副本，要生效得替换当前挂载点。而/etc正在被系统使用，无法直接umount。常见错误是死磕卸载，其实该换思路：
- 停掉所有依赖
/etc的服务：sudo systemctl stop nginx sshd cron等，再试umount /etc - 更稳妥的做法：进单用户模式（启动时按
e编辑内核参数，加systemd.unit=emergency.target），此时/etc未被多服务占用 - 用
cp -a复制快照内容而非挂载：sudo cp -a /.snapshots/123/snapshot/etc/* /etc/，避免挂载点冲突 - 如果用了
snapper，直接sudo snapper rollback 123即可，它内部处理了卸载与替换逻辑
真正麻烦的不是创建快照，而是恢复时能否快速停掉服务、避开挂载点锁、验证快照内容是否完整——这些细节没提前演练过，故障时刻就会卡住。
