기술 · 실용 가이드
rsync “Broken pipe (32)”? SSH를 조정하기 전에 처음 실패한 끝점을 찾으세요
송신자 메시지는 수신자나 원격 셸이 먼저 실패한 뒤 나타날 수 있습니다. 양쪽 로그를 보존하고 첫 경계를 고친 뒤 재개 복사를 검증하세요.
송신자 메시지는 수신자나 원격 셸이 먼저 실패한 뒤 나타날 수 있습니다. 양쪽 로그를 보존하고 첫 경계를 고친 뒤 재개 복사를 검증하세요.
EPIPE는 파이프나 소켓의 읽는 쪽이 닫힌 뒤 쓰기를 뜻합니다. Rsync는 소켓 I/O, 파일 I/O, 프로토콜 스트림과 타임아웃 종료를 구분합니다.
1. 한 실패의 양쪽 증거 수집
전체 명령, 양쪽 rsync --version, 로컬 stderr, 원격 서비스나 커널 로그, 시각과 모든 프로세스 종료 코드를 저장하세요. 자격 증명만 지우고 순서는 남깁니다.
단일 콜론 remote-shell 경로와 이중 콜론 또는 rsync:// daemon 경로를 구분하세요.
2. 가장 큰 오류가 아닌 첫 오류 정렬
sender Broken pipe는 읽는 쪽이 사라졌다는 뜻일 뿐 이유는 아닙니다. 시간을 맞추고 receiver의 ENOSPC, EIO, 권한, kill, mount 문제가 먼저인지 찾으세요.
종료값 10은 socket I/O, 11은 file I/O, 12는 protocol stream, 30은 data timeout입니다. 255는 원격 셸일 수 있어 진단을 함께 보존합니다.
3. 저장소·전송·프로토콜 분류
저장소에서는 대상 파일시스템, 마운트, 블록과 inode, 권한, 쿼터와 커널 I/O를 확인하세요. 전송에서는 SSH와 중간 장비를 따로 검사합니다.
ServerAlive 설정은 무응답을 찾지만 디스크 오류를 고치지 못합니다. --timeout도 I/O 무응답 경계이지 보편적 치료가 아닙니다.
4. 의도적으로 수정하고 재개
입증된 첫 경계만 고치세요. 부분 파일을 남기려면 --partial 또는 --partial-dir 정책을 명시하고 trailing slash 의미를 바꾸지 마세요.
같은 버전이나 압축 변경만으로 원인을 단정하지 말고 제어된 재시도마다 한 변수만 바꿉니다.
5. 완성 트리 검증
최종 실행은 exit 0이어야 하며 같은 원본과 대상에 itemized dry run을 수행하세요. 남은 모든 차이를 조사합니다.
대표 대용량 파일과 핵심 메타데이터를 적절한 해시나 앱 검사로 확인하고 양쪽 로그와 수정 차이를 승인 기록으로 보존합니다.
