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

在 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/。

  ✅ 优点：彻底防删，连 --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：❌ 会掩盖权限问题，反而增加风险。

---

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

1. 使用非 root 用户（如 backup）执行 rsync；
2. 目标根目录 /backup 所有者为 root:backup，权限 750；
3. 每次同步完成后，立即运行：

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

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

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