rsync本身不能创建一致性快照，必须依赖lvm/zfs/btrfs等文件系统快照机制先冻结状态，再用rsync同步快照内容；快照是前提，rsync仅负责安全读取静止数据。
直接用 rsync 本身无法创建一致性快照——它只是同步工具，不干预文件系统状态。要在同步数据库物理文件前获得临时一致性视图，必须依赖底层文件系统或存储层提供的快照能力（如 LVM、ZFS、Btrfs），再用 rsync 安全读取快照内容。整个过程不是“rsync 做快照”，而是“先建快照，再用 rsync 拷贝快照”。
快照创建是前提，不是 rsync 的功能
数据库（如 MySQL InnoDB、PostgreSQL）的物理文件在运行时持续写入，直接复制会导致页断裂、事务不完整。rsync 即使加 -a 或 --checksum，也无法解决正在修改的文件内容不一致问题。唯一可靠方式是：
- 暂停写入（不推荐生产环境）
- 或借助支持 COW（写时复制）的快照机制，瞬间冻结某一时刻的文件系统状态
常见快照方案：
-
LVM 逻辑卷快照：需提前规划 LV，运行
lvcreate -s -n snap_name -L 5G /dev/vgname/lvname -
ZFS 数据集快照：
zfs snapshot pool/dataset@backup_$(date +%Y%m%d) -
Btrfs 子卷快照：
btrfs subvolume snapshot -r /data/db /data/db_snap_20260721
rsync 只负责安全读取快照路径
快照挂载后（例如 /mnt/snap_db），再用 rsync 同步该路径内容，此时文件静止、结构一致：
rsync -aHAX --numeric-ids /mnt/snap_db/ /backup/db_20260721/
关键点：
- 源路径末尾带
/→ 同步目录内容（推荐） - 加
-H保留硬链接（InnoDB 表空间常用） - 加
-A和-X保留 ACL 与扩展属性（部分数据库依赖） -
--numeric-ids避免 uid/gid 映射错乱
快照生命周期要管理好
- 快照本身不自动删除，需脚本清理过期快照（如保留最近 3 个）
- 同步完成后，尽快卸载并删除快照（尤其 LVM 快照会随原卷写入持续占用空间）
- 不建议长期挂载快照用于服务，仅作备份读取用途
实际执行顺序示例（以 LVM 为例）
- 创建快照（秒级完成）
lvcreate -s -n db_snap -L 4G /dev/vg0/mysql_data
- 挂载快照
mkdir -p /mnt/db_snap mount /dev/vg0/db_snap /mnt/db_snap
- rsync 同步（可限速、压缩、校验）
rsync -aHAX --numeric-ids --compress-level=3 /mnt/db_snap/ /backup/mysql_full_20260721/
- 卸载并删除快照
umount /mnt/db_snap lvremove -f /dev/vg0/db_snap
不复杂但容易忽略
