기술 가이드 · 실용 가이드
rsync 종료 코드 24: 경고를 무시하기 전에 사라진 파일 확인
코드 24는 전송 중 원본 파일이 사라졌다는 뜻입니다. 경로와 원래 상태를 보존하고 파일 중요성을 판단한 뒤 안정된 원본의 재실행을 검증하고 자동화 정책을 바꾸세요. 래퍼가 누락 파일을 완전한 백업으로 만들지는 않습니다.
rsync 종료 코드 24는 원본 파일 소실에 따른 부분 전송입니다. 다른 오류로 부분 전송이 발생했다는 23과는 다릅니다. 발견 후 파일이 사라지는 현상은 정상적인 실시간 변화일 수 있지만 상태만으로 누락된 것이 임시 잠금 파일인지 중요한 데이터의 유일한 사본인지 알 수 없습니다.
1. 경고를 거르기 전에 실행 기록 보존
표준 출력과 오류, 시각, 양쪽 rsync 버전, 정확한 원본·대상 루트, 끝 슬래시 규칙, 필터와 삭제 옵션을 저장하세요. rsync가 반환한 직후 실제 종료 상태를 얻어야 합니다. 다른 명령이나 파이프라인 뒤에는 기록 도구의 상태를 얻을 수 있습니다. 소실 경로 목록을 백업 식별자와 함께 보존하세요.
다음 통제된 시도에서 --itemize-changes로 계획·실제 변경을 보고 --log-file=FILE로 전송 활동을 기록할 수 있습니다. 활동 로그가 표준 오류를 대신한다고 가정하지 마세요. 한 경로부터 삭제·이름 변경·접근 불가인지, 다른 원본 뷰에서는 있는지 확인하세요. 광범위한 경고 필터로 유일한 증거를 없애지 마세요.
2. 어떤 누락을 수용할지 판단
앱이나 데이터 책임자에게 경로 내용을 물으세요. 버려도 되는 잠금·임시 파일은 백업 목표 밖일 수 있지만 메일·문서·중요 앱 상태는 디렉터리가 바쁘다고 버려도 되는 것은 아닙니다. 정책상 누락을 허용할 때만 좁고 검토된 제외 규칙을 기록하세요. 모든 tmp 폴더나 잠금 확장자 제외는 실제 요구를 숨길 수 있습니다.
2023년 Back In Time 이슈에는 rsync의 종료 코드 24 때문에 취소된 실제 스냅샷이 있습니다. 유지관리자는 24를 정보로 기록하고 다른 오류는 오류로 두는 변경을 병합했다고 보고했습니다. 제품 정책이지 모든 누락이 무해하다는 증거는 아닙니다. 안정된 중요 경로가 반복 소실되거나 마운트·I/O 오류가 동반되면 상태를 바꾸기 전에 원본을 조사하세요.
3. 검증할 수 있는 원본에서 재실행
삭제 옵션이 있는 명령을 반복하기 전에 같은 검토된 루트·필터에 --dry-run --itemize-changes를 붙여 특히 삭제 예정 항목을 확인하세요. 시험 실행은 복사도 이전 누락 복구도 하지 않습니다. 계획된 조용한 시간이나 앱 지원 스냅샷 절차로 원본 변화를 줄이세요. 변하는 앱의 실시간 rsync만으로 특정 시점에 일관된 백업이 되지는 않습니다.
승인된 실제 재실행 뒤 필요한 내용과 각 중요 소실 경로의 결과를 비교하세요. 기본 빠른 검사는 크기·수정 시각을 쓰고 --checksum은 파일 데이터를 읽는 비용으로 내용 체크섬에 따른 선택으로 바꿉니다. 변하는 원본을 안정화하지 않으며 전송 파일의 일반 재구성 검사와도 다릅니다. 종료 0만 보지 말고 대표적인 복원 내용이나 앱의 문서화된 복원 테스트를 확인하세요.
4. 정당화한 정책만 변경
공식 FAQ 래퍼는 정확히 24만 0으로 바꾸고 다른 상태는 유지합니다. 예상 누락과 수용할 백업 결과를 기록한 뒤에만 적용하고 로그·모니터링에는 원래 24를 남기세요. || true로 모든 실패를 성공으로 바꾸지 마세요. 중요 누락이 설명되지 않으면 래퍼가 0이어도 목표에 비해 불완전합니다.
비슷한 이름의 두 옵션은 다른 일을 합니다. --ignore-missing-args는 첫 조회에서 없는 명시 원본 인수 오류를 숨기며 처음 발견됐다가 나중에 사라진 파일에는 적용되지 않는다고 매뉴얼이 명시합니다. --ignore-errors는 I/O 오류가 있어도 --delete를 진행합니다. 둘 다 누락 파일을 복원하지 않습니다. 필요한 데이터가 존재하고 사용 가능하며 누락이 설명되고 다른 실패가 보이는 것이 완료이지 경고가 사라진 것만은 아닙니다.
