inotifywait监控目录+rsync增量同步最可靠,但需调大max_user_watches等内核参数防句柄耗尽;事件选close_write/move/delete并排除临时文件;用flock防rsync并发冲突;systemd服务需设重启策略、日志输出及权限。

直接结论:用 inotifywait 监控目录 + rsync 增量同步是最可靠、低开销的实时触发方案,但必须调优内核参数,否则监控一启动就报 No space left on device。
为什么 inotifywait -m -r 会突然失败
这不是磁盘满,是 inotify 实例数或监听句柄超限。Linux 默认对每个用户限制为 8192 个 inotify watches,递归监控 /var/log 或 /etc 这类含大量子目录的路径时极易触顶。
- 检查当前使用量:
cat /proc/sys/fs/inotify/max_user_watches - 临时提高(重启失效):
sudo sysctl fs.inotify.max_user_watches=524288 - 永久生效:写入
/etc/sysctl.conf并运行sudo sysctl -p - 顺带调大另外两个参数:
max_user_instances(默认 128)、max_queued_events(默认 16384),尤其在高并发写入场景下
inotifywait 的事件组合怎么选才不漏不重
只监听 create 会丢掉编辑保存、重命名等操作;全开又可能因编辑器临时文件(如 .swp、.part)引发误同步。生产环境推荐以下组合:
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包,适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 核心事件:
close_write(文件写入完成)、move(含重命名/移动)、delete(删文件/目录) - 必须排除干扰:
--exclude '\.(swp|swo|part|~)$',避免 vim/gedit/下载器生成的临时文件触发 - 加
-q静默输出,只让事件流进管道;--format '%w%f %e'确保能准确提取路径和事件类型 - 不要用
modify:它在文件写入中途就触发,rsync 可能读到不完整内容
如何防止 rsync 并发冲突和覆盖正在写的文件
inotify 是事件驱动,但 rsync 是重量级进程。若源目录高频变更,多个事件可能堆积,导致多个 rsync 同时跑,既耗资源又可能把未写完的文件同步过去。
- 用
flock加锁:在 rsync 前加flock -n /tmp/rsync_backup.lock -c 'rsync ...',抢不到锁就跳过本次 - 加
--delay-updates:让 rsync 把所有更新暂存在临时目录,最后原子替换,避免中间态暴露 - 慎用
--delete:仅在目标是“完全镜像”时启用;若目标有额外文件或需保留历史版本,改用--backup --backup-dir=... - 本地备份建议加
-a --numeric-ids;远程同步务必加--rsync-path="sudo rsync"(如果目标需 root 权限还原权限)
systemd 管理 inotify 监控服务的关键细节
用 nohup 或后台 & 启动脚本不可靠——进程意外退出不会自动拉起,日志也难追踪。应封装为 systemd service:
- Service 文件里必须设
Restart=on-failure和RestartSec=5,防止 inotifywait 因信号中断后挂死 -
StandardOutput=journal+StandardError=journal,方便用journalctl -u backup-monitor.service查问题 - 避免在
ExecStart中直接写长管道命令,拆成独立脚本(如/usr/local/bin/backup-monitor.sh),便于调试和权限控制 - 若监控系统目录(如
/etc),service 需加CapabilityBoundingSet=CAP_SYS_ADMIN,否则 inotifywait 无法监听某些受保护路径
最易被忽略的一点:inotify 不监控子目录创建后的自动递归——-r 参数只对已有子目录生效。如果业务会动态建新子目录(比如日志按天分目录),必须配合 --monitor(即 -m)+ 定期重新扫描,或改用更重但支持动态递归的 inotifywatch(非 inotify-tools 自带)或 fanotify。普通场景下,老老实实用 -m -r + 调参,足够稳。










