lvm快照本身不是备份，而是为备份提供一致性的数据视图，通过写时复制机制秒级生成只读时间点镜像，需配合rsync/tar等工具复制到独立存储才形成可靠备份，且须满足同卷组、文件系统支持冻结、合理预估快照大小三条件。
LVM快照本身不是备份，而是为备份提供一致性的数据视图。它通过写时复制（COW）机制，在秒级内生成逻辑卷的只读时间点镜像，让备份工具能安全读取静止状态的数据，避免因业务写入导致备份不一致。
快照必须配合真实复制才能形成可靠备份
快照依赖原始逻辑卷存在，空间有限，且无法脱离当前主机环境长期保存。单独保留快照毫无恢复价值。真正可用的备份需用 rsync、tar 等工具，把快照内容完整复制到独立存储路径或远程主机：
- 挂载快照时加 -o ro,nouuid，防止 UUID 冲突或误写破坏一致性
- rsync 推荐带 --checksum 校验和 --compress 压缩，确保完整性并减少传输量
- tar 备份需保留扩展属性：tar --acls --xattrs -cf backup.tar -C /mnt/snap .
创建前必须满足三个硬性条件
缺一不可，否则快照可能立即失效或无法挂载：
- 源逻辑卷与快照必须在同一卷组（VG）内，且 VG 有足够空闲 PE
- 文件系统需支持在线快照：XFS 强烈建议先 xfs_freeze -f /mount/point 冻结；ext4 虽可跳过冻结，但务必执行 sync && echo 3 > /proc/sys/vm/drop_caches
- 快照大小不能拍脑袋估算——按“单位时间写入量 × 预估备份耗时 × 1.5”计算，生产环境关键数据建议按源 LV 容量的 3%～5% 配置
备份流程中容易被忽略的关键动作
快照只是临时桥梁，生命周期应严格控制在备份窗口内：
- 挂载后立即执行备份，完成后立刻 umount，避免挂载点残留影响后续操作
- 确认备份文件可解压/可同步后，再执行 lvremove -f 删除快照，释放 PE 空间
- 日常需监控 lvs -o +data_percent，一旦 data% ≥90%，说明快照区即将溢出，必须紧急处理
这种组合特别适合三类场景
它解决的是“不停机、要一致、可验证”的核心矛盾：
- 数据库热备：MySQL、PostgreSQL 数据目录在 LVM 上时，冻结+快照+rsync 可实现秒级停写、分钟级传输
- 备份窗口可控：LVM 快照创建始终
- 恢复路径清晰：备份结果是标准文件结构，无需依赖 LVM 环境，直接 rsync 回灌或挂载验证即可
