科技 · 实用指南
rsync 报“Broken pipe (32)”？调 SSH 前先找到第一个失败端
发送端报错常发生在接收端或远程 shell 已失败之后。保留两端日志、按时间排序、修复首个边界，再验证续传后的完整性。
发送端报错常发生在接收端或远程 shell 已失败之后。保留两端日志、按时间排序、修复首个边界，再验证续传后的完整性。
EPIPE 表示写入端发现管道或套接字的读取端已关闭。 Rsync 会区分套接字 I/O、文件 I/O、协议流和超时退出。
1. 采集同一次失败的两端证据
保存完整本地命令、两端 rsync --version、本地 stderr、远程服务或内核日志、时间戳及每个进程退出码。脱敏凭据，但不要破坏错误顺序。
区分远程 shell 与 daemon 路径：单冒号通常经 SSH 启动远端 rsync；双冒号或 rsync:// 连接 daemon。
2. 按首个错误而非最大声错误排序
发送端 Broken pipe 只说明读取端消失，并不说明原因。对齐时间后检查接收端是否先出现 ENOSPC、EIO、权限、进程被杀或挂载异常。
利用退出码辅助：10 是套接字 I/O、11 是文件 I/O、12 是协议流、30 是数据超时。255 常来自远程 shell，因此也要保存它的诊断。
3. 区分存储、传输与协议
存储分支检查目标文件系统、挂载、空闲块和 inode、权限、配额与内核 I/O 日志；传输分支单独测试 SSH，并检查中间设备和空闲策略。
ServerAliveInterval 与 ServerAliveCountMax 可发现 SSH 对端无响应，却修不了磁盘错误。--timeout 只是 rsync 的 I/O 静默边界，也不是万能修复。
4. 有意修复并续传
只修已证明的首个边界。若要保留部分文件，明确采用 --partial 或 --partial-dir 策略，并确保源/目标与尾斜杠语义未被意外改变。
版本相同不等于根因已排除，压缩也不是每次断线的原因。保存版本和传输路径，每次受控重试只改一个变量。
5. 验证最终目录
最终运行必须退出 0，随后对相同源和目标做 itemized dry run。逐项解释剩余差异，不能用已传字节数代替完整性。
对代表性大文件和关键元数据执行适合应用的哈希或校验，并把两端日志与修复差异作为验收记录。
