rsync 是面向文件的增量同步工具，工作在用户空间，支持跨平台备份但存在一致性窗口；文件系统快照是内核级原子视图，保证事务一致性但需配合导出才能实现异地备份；生产中常组合使用以兼顾效率、一致性和可靠性。
rsync 和文件系统快照（如 BTRFS、ZFS、LVM 快照）是两类不同层级的备份机制，适用场景和设计目标有本质区别。选对方案，关键看你要解决的是“数据同步”问题，还是“系统状态捕获”问题。
rsync 是面向文件的增量同步工具
它工作在用户空间，不依赖特定文件系统，核心能力是比对源与目标的文件差异，只传输变化部分。
- 支持跨文件系统、跨主机、跨网络备份，比如把 ext4 系统备份到 NTFS 外置硬盘或远程 NAS
- 保留权限、时间戳、软硬链接、ACL 等元数据（需加 -a 参数）
- 首次全量耗时长，后续增量极快；但每次运行前需扫描全部文件做校验，百万级小文件时 CPU 和 I/O 开销明显
- 不是实时机制：靠 cron 定时触发，两次备份间存在窗口期，无法保证强一致性（尤其对数据库等持续写入服务）
- 可配合 inotify 或 fswatch 实现近实时同步，但会增加复杂度和资源占用
文件系统快照是内核级原子状态保存
它由文件系统原生提供，本质是写时复制（CoW）机制下的瞬间视图，不涉及文件内容逐个比对。
- 创建快照几乎零耗时（毫秒级），且保证事务一致性——例如 MySQL 正在写入时拍一个 BTRFS 快照，恢复后数据不会损坏
- 初始不占额外空间，仅当原始数据被修改时才按需分配新块；空间复用率高
- 局限性强：BTRFS 快照必须在同一子卷/分区内；LVM 快照需预留足够元数据空间且不支持无限嵌套；ZFS 快照虽强大但对内存要求高
- 快照本身不是备份：它依附于原存储设备，磁盘故障即丢失；必须配合 rsync、zfs send 等导出到异地才算完成备份闭环
实际生产中常组合使用
单一技术难以兼顾一致性、效率与可靠性，成熟策略往往是分层设计：
- 用 BTRFS 快照做本地快速回滚（分钟级恢复），应对误操作或升级失败
- 用 rsync 将快照挂载后的目录，定时同步到另一块物理盘或远程服务器，实现异地容灾
- 对数据库等关键服务，在执行快照前调用 mysqlbackup --flush-logs 或 pg_basebackup，再拍快照，确保日志与数据一致
- 避免直接 rsync 正在运行的数据库文件目录——可能拷出中间状态，导致恢复失败
真正可靠的备份，从来不是“选 rsync 还是选快照”，而是搞清每个环节要守住哪条底线：快照守一致性，rsync 守可移植性，人工策略守恢复验证。
