linux中rsync结合inotify实现实时同步的核心是事件驱动：inotify监控目录变化并即时触发rsync，需合理配置、明确权限、防止重复触发与资源超限。
Linux 中用 rsync 结合 inotify 实现实时同步，核心是让 inotify 监控目录变化，一有改动就立刻触发 rsync 执行同步。这不是定时轮询，而是事件驱动，真正接近“实时”。关键不在装两个工具，而在配置合理、权限清晰、避免重复触发和资源超限。
安装并确认基础环境
先确保系统支持 inotify（内核 2.6.13+ 即可，现代发行版都满足），再装齐工具：
- CentOS/RHEL：运行 yum install -y rsync inotify-tools（EPEL 源需提前启用）
- Ubuntu/Debian：运行 apt-get install -y rsync inotify-tools
- 验证是否就绪：inotifywait --version 和 rsync --version 都应正常输出
- 检查内核限制：cat /proc/sys/fs/inotify/{max_user_watches,max_queued_events}，若监控大量文件，建议把 max_user_watches 调高（如 524288），写入 /etc/sysctl.conf 并执行 sysctl -p
编写可靠监控同步脚本
脚本要解决几个实际问题：避免重复触发、过滤临时文件、处理 SSH 密钥或密码、防止 rsync 正在运行时新事件堆积。下面是一个生产可用的简化版：
#!/bin/bash
SOURCE_DIR="/data/web"
DEST_DIR="user@192.168.1.100:/backup/web"
# 排除常见干扰文件
EXCLUDES="--exclude='*.swp' --exclude='.git/' --exclude='cache/'"
inotifywait -m -r -e close_write,move,create,delete,attrib \
--format '%w%f' \
$SOURCE_DIR | while read file; do
# 防止短时间内多次触发
[ -f "$file" ] || continue
echo "$(date): Sync triggered for $file"
rsync -avz --delete $EXCLUDES "$SOURCE_DIR/" "$DEST_DIR/"
done
- -m 表示持续监听；-r 递归子目录；close_write 是最常用且稳妥的事件（文件写完关闭后才触发）
- 用 while read file 而非直接管道进 rsync，便于加判断和日志
- 如果走 SSH 同步，确保已配置免密登录（ssh-copy-id），否则脚本会卡住
让脚本稳定后台运行
不能只手动执行一次。推荐两种方式：
- systemd 服务（推荐）：创建 /etc/systemd/system/inotify-rsync.service，定义 Type=simple、Restart=always，启用并启动服务。这样开机自启、崩溃自动拉起、日志统一归集
- nohup + 后台进程：运行 nohup ./sync.sh > /var/log/inotify-sync.log 2>&1 &，再把 PID 记入文件便于管理。适合测试或简单场景
- 避免用 crontab 定时拉起脚本——它无法保证唯一实例，容易引发并发冲突
同步方向与安全要点
rsync + inotify 默认是单向同步（源 → 目标），这也是最安全、最常用的模式：
- 不要轻易做双向实时同步——inotify 无法识别“谁先改”，极易导致循环同步或数据覆盖
- 目标端若为远程服务器，建议 rsync 使用 --delete-after（删完再传）而非 --delete（边传边删），降低中间态风险
- 首次运行前，手动执行一次完整 rsync，确保两边基线一致；之后再启动 inotify 监控
- 在脚本中加入简单锁机制（如用 mkdir /tmp/rsync.lock 判断）可防止 rsync 多次并发执行
不复杂但容易忽略：事件类型选错、排除规则缺失、用户权限不对、SSH 连接没配好——这四点占了八成失败原因。调通后，用 touch 或 echo > 在源目录里快速建删改几个小文件，观察日志和目标端是否即时响应，就基本能确认跑稳了。
