我在跨境电商项目中踩过这样的坑：系统运行过程中发生了一次突发故障，恢复备份时却发现日志只保留到1小时前，部分数据完全丢失，直接影响了财务对账和用户订单同步。根因很简单，日志备份机制是基于 cron，每小时同步一次，而数据写入却是分钟级乃至秒级的。那次之后，我彻底改造了备份链路——采用 rsync + incrond 组合，实现文件变更的秒级感知与跨地域增量同步，确保数据日志几乎实时地同步至香港、深圳和新加坡等多个节点。
以下是我在香港服务器上搭建这套机制的全过程实录，完整落地方案可适用于高频日志场景下的数据保障。
一、技术选型与架构说明
目标需求：
- 监听指定目录内的新增、变更、删除操作；
- 将变动文件通过 rsync 增量同步到多个备份节点；
- 实现秒级触发，适配高频日志写入；
- 网络为公网或内网互通，支持 SSH 密钥认证；
- 稳定、可复用、低资源占用。
技术栈：
| 组件 | 作用 |
|---|---|
rsync |
文件增量同步传输工具 |
incrond |
文件系统事件监听守护进程 |
ssh + 密钥 |
实现远程主机间免密通信 |
架构图：
[应用服务器]
└── /data/logs/xxx.log
│
[incrond监听]
│
触发脚本
│
rsync 传输
│
┌──────────────┐
│ 香港备份节点 │
└──────────────┘
┌──────────────┐
│ 深圳备份节点 │
└──────────────┘
┌──────────────┐
│ 新加坡节点 │
└──────────────┘
二、安装与配置环境准备
2.1 安装 rsync 与 incrond
# 安装 rsync
sudo apt install rsync -y # Debian/Ubuntu
# 或者
sudo yum install rsync -y # RHEL/CentOS
# 安装 incrond
sudo apt install incron -y
sudo systemctl enable incrond
sudo systemctl start incrond
2.2 配置 SSH 免密登录
生成密钥并复制至备份节点：
ssh-keygen -t rsa -b 4096
ssh-copy-id backupuser@backup-node-ip
在多个节点执行相同操作，确保所有目标节点都能接受 rsync 免密传输。
三、编写 rsync 同步脚本
创建统一的同步脚本 rsync_sync.sh，用于 incrond 触发时调用：
#!/bin/bash
SRC_FILE="$1"
LOG_TAG="rsync-incron"
# 目标列表，可扩展为配置文件
TARGETS=("backupuser@hk-backup:/data/backup/"
"backupuser@sz-backup:/data/backup/"
"backupuser@sg-backup:/data/backup/")
for TARGET in "${TARGETS[@]}"; do
/usr/bin/rsync -az --relative "$SRC_FILE" "$TARGET" \
>> /var/log/rsync_sync.log 2>&1
logger -t "$LOG_TAG" "Synced $SRC_FILE to $TARGET"
done
注意事项：
- –relative 保留相对路径；
- 建议限制路径只允许在 /data/logs 下传输，防止滥用。
赋予可执行权限：
chmod +x /usr/local/bin/rsync_sync.sh
四、配置 incrond 实现文件监听
4.1 启用 incrond 服务
sudo systemctl start incrond
sudo systemctl enable incrond
4.2 配置监听规则
编辑监听表 /etc/incron.allow，添加当前用户：
echo "youruser" | sudo tee -a /etc/incron.allow
设置监听规则：
incrontab -e
添加如下内容：
/data/logs IN_MODIFY,IN_CLOSE_WRITE,IN_CREATE /usr/local/bin/rsync_sync.sh $#@
说明：
- IN_MODIFY：文件内容变化；
- IN_CLOSE_WRITE：写入完成；
- IN_CREATE：新文件生成；
- $#@：自动传入触发文件完整路径。
五、测试与验证方案
可执行以下测试流程验证系统运行情况：
在主服务器 /data/logs/ 创建测试日志文件：
echo "test log $(date)" >> /data/logs/test.log
检查各个备份节点是否同步：
ssh backupuser@hk-backup "cat /data/backup/data/logs/test.log"
查看系统日志和 rsync 运行日志：
tail -f /var/log/rsync_sync.log
journalctl -u incrond
六、优化建议与注意事项
6.1 rsync 参数优化
- 可加入 –remove-source-files 用于搬迁；
- 加入 –bwlimit 控制带宽；
- 使用 –timeout=10 避免卡死连接。
6.2 多线程并发传输（高级）
如果同步目标非常多，可使用 GNU parallel 优化并发同步，避免串行阻塞：
parallel -j 3 "/usr/bin/rsync -az --relative {1} {2}" ::: "$SRC_FILE" ::: "${TARGETS[@]}"
6.3 防止死循环触发
避免 rsync 写入本地目录再次触发 incrond，建议通过 .incronignore 或专属中转目录设计规避。
七、典型落地场景
多地业务日志集中备份
- 对接安全审计系统或 ELK 日志分析平台。
秒级文件分发
- 实时将上传的图片或视频分发到多地 CDN 节点。
MySQL binlog 增量拉取中转
- 将 binlog 同步至分析节点进行离线解码与解析。
rsync 与 incrond 的组合为我解决了日志延迟与数据一致性的问题，尤其是在多地分布式架构下，它提供了一种简单、可靠且低开销的实时同步机制。相比周期性调度，它更具响应性，也更适合业务对 RTO/RPO 要求苛刻的场景。在部署这套方案后，我们的日志同步延迟从分钟级缩短到了秒级，真正支撑起了“数据不中断、分析不断链”的要求。对于日志密集型、异地备份型业务，我认为这是值得落地推广的一套基础设施组件方案。
