rsync 不支持真正的双向同步，仅能通过两个单向任务模拟，但易引发数据冲突与损坏；生产环境灾备绝不可依赖此方式，应采用主从复制、日志复制、专业容灾平台或分布式文件系统等更可靠方案。
rsync 本身不支持真正的双向同步，它是一个单向同步工具。所谓“双向同步”，在 rsync 场景中实际是通过两个独立的单向任务（A→B 和 B→A）模拟实现的，但这种做法风险极高——极易引发数据冲突、覆盖、时序错乱，最终导致主备节点数据漂移甚至损坏。生产环境中的异地灾备系统，**绝不应依赖 rsync 实现双向同步**。
为什么 rsync 不适合做双向同步
– rsync 没有内置冲突检测与合并机制，无法判断同一文件在两端是否被同时修改
– 无全局时钟或版本向量，无法可靠判定“谁更新、谁覆盖”
– 同步顺序、执行时机、网络延迟都会放大竞争条件
– 即使加锁或串行化，也无法解决应用层写入与同步窗口之间的竞态问题
异地灾备中更安全的替代方案
– 主从异步复制（推荐）：明确主节点（可读写），备节点（只读/待切换）。用 rsync 定期拉取主节点数据（如每小时一次），配合校验脚本和时间戳标记，确保灾备点始终是主节点的历史快照
– 基于日志的复制（如 MySQL binlog、PostgreSQL WAL、文件系统级 CDP）：保证操作顺序与一致性，天然支持故障回退与精确恢复点
– 专业容灾平台（如 OceanStor HyperReplication、Veritas NetBackup、Veeam）：提供租户级 Pair 管理、分裂/同步/回切流程、一致性组、RPO/RTO 控制等企业级能力
– 分布式文件系统（如 CephFS、GlusterFS）：通过多副本+共识算法维持跨站点数据一致性，但需专用架构支撑
若必须用 rsync 模拟“准双向”场景，仅限测试或低风险静态数据
– 严格限定为非并发写入：同一时段仅允许一端写入，另一端仅同步；可通过调度器（如 cron + 锁文件）强制互斥
– 使用 --backup --suffix 保留被覆盖文件，便于人工追溯
– 增加 --itemize-changes -i 日志记录每次变更类型（如 >f+++++++++ 表示新增，.f…… 表示属性变更）
– 每次同步前先运行 rsync -avn 预检，人工确认无高危覆盖再执行
– 同步路径必须区分命名空间（如 /data/primary/ 与 /data/standby/），禁止直接覆盖对方工作目录
真正可靠的异地灾备，核心在于角色清晰、流程可控、状态可验。把 rsync 当作“数据搬运工”，而不是“智能协调员”。主备数据漂移问题，本质是架构设计问题，不是 rsync 参数能解决的。
