rsync中怎么利用只读模式在备份节点上防止数据被源端误删操作而同步抹除-linux运维-PHP中文网

rsync备份的“只读模式”需通过系统权限控制实现：以非root用户运行rsync，目标目录设为755权限并归属root:backup组，必要时用chattr +i锁定，配合--dry-run预检，确保--delete等操作因权限不足而失败。

rsync中怎么利用只读模式在备份节点上防止数据被源端误删操作而同步抹除

在 rsync 备份中，“只读模式”不是 rsync 自身的运行选项，而是通过操作系统层面的权限控制来实现的——核心目标是：让备份节点（目标端）上的文件对 rsync 进程不可写，从而阻断 --delete 或覆盖操作生效，避免源端误删或误同步导致备份数据被连带清除。

这不是靠加某个 rsync 参数就能开启的“开关”，而是一套配合使用的防护逻辑。

✅ 关键思路：让目标目录对 rsync 进程“不可删除、不可覆盖”

rsync 执行删除（--delete）、覆盖、重命名等操作时，依赖目标端文件系统对该路径具有写权限。只要目标端对应目录或文件被设为只读（对运行 rsync 的用户而言），rsync 就会失败并报错（如 Permission denied 或 Operation not permitted），从而中止危险操作。

? 实现方式（按推荐顺序）

对目标目录设置不可写权限（最常用有效）
假设你用 backupuser 账户执行 rsync 同步到 /backup/app/：

# 先同步一次（确保初始数据就位）
rsync -av /srv/app/ /backup/app/

# 然后锁定目标目录：移除 backupuser 对其的写权限
chmod 755 /backup/app        # 目录可进入、可读、不可写
chmod -w /backup/app/.env   # 单独保护关键配置文件（如果存在）
chown root:backupuser /backup/app
chmod g-w /backup/app       # 组内也去写权限（若 backupuser 属于 backupuser 组）

⚠️ 注意：rsync 进程必须以 backupuser（非 root）身份运行，否则 root 可绕过权限限制。这是前提。

用 chattr +i 设置不可变属性（更强硬，适合静态归档）
对已完成备份的整个目录启用不可变标志（仅 root 可设/取消）：
```
sudo chattr -R +i /backup/app/
```
此时即使 root 用户也无法删除、修改、重命名该目录下任何内容（包括 rsync）。恢复写入需先 sudo chattr -R -i /backup/app/。

Flowise
一款开源的低代码AI应用开发工具，通过可视化流程编排帮助开发者构建聊天机器人、Agent和其他AI应用。

下载

✅ 优点：彻底防删，连 --delete 都无法触发实际删除。
❌ 缺点：每次更新备份前必须手动解除，不适合全自动高频同步。
分离“同步用户”与“备份所有权”
让 rsync 以专用低权限用户（如 rsync-runner）运行，但目标目录归属 root:backup，且 rsync-runner 不在 backup 组中：
```
sudo chown root:backup /backup/app
sudo chmod 750 /backup/app
sudo usermod -aG backup root  # 允许 root 维护，但 rsync-runner 无组写权
```
这样 rsync-runner 可读、可遍历，但无法 unlink() 或 rename() 文件——--delete 会静默跳过（不报错但不执行），而覆盖则因 open(O_WRONLY|O_TRUNC) 失败而中断。
配合 --dry-run + 权限检查做预检（运维习惯）
每次正式同步前，加 -n 和 --delete 测试：
```
rsync -avn --delete /srv/app/ /backup/app/
```
观察输出中是否有大量 deleting xxx 行。若目标目录已设只读，你会看到类似：
```
rsync: delete failed: Permission denied (13)
```
提示你当前策略已生效，无需担心真实执行时误删。

? 不要依赖的“伪只读”做法

rsync --read-only：❌ 不存在这个参数，rsync 官方无此选项。
--chmod=ugo-w：❌ 这是在同步过程中修改源文件权限，不影响目标端已有文件的删除能力。
--ignore-errors 或 --force：❌ 会掩盖权限问题，反而增加风险。

✅ 最佳实践组合建议（生产环境推荐）

使用非 root 用户（如 backup）执行 rsync；
目标根目录 /backup 所有者为 root:backup，权限 750；

每次同步完成后，立即运行：

sudo chmod 755 /backup/app && sudo chown root:backup /backup/app

关键子目录（如 /backup/app/config）额外用 chattr +i 锁定；
cron 任务中始终带上 --dry-run 日志检查，再执行真同步。

这样既保留了 rsync 增量同步的能力，又把“误删传播”挡在了文件系统门外——不是靠 rsync 聪明，而是让它“想删也删不动”。