기술 · 실용 가이드
rsync --link-dest가 파일을 복사했나요? 경로 구조와 보존 속성을 검증하세요
대상 디렉터리를 출발점으로 비교 기준 디렉터리의 경로를 해석하고, 속성 불일치를 찾아낸 뒤, 해시 일치만 믿지 말고 장치 번호와 inode 번호로 하드 링크를 검증하세요.
rsync --link-dest에는 파일의 바이트 내용이 동일하다는 것만으로 충분하지 않습니다. 이전 파일이 같은 상대 경로에 있어야 하며, 명령이 보존하는 모든 속성도 일치해야 합니다. 대상 디렉터리를 기준으로 한 비교 기준 경로의 오류, --relative로 유지되는 접두 경로, 모드나 그룹의 차이, 또는 --ignore-times 옵션 때문에 파일 내용이 바뀌지 않아도 별도의 복사본이 만들어질 수 있습니다.
하드 링크 생성을 검증 가능한 백업 속성으로 다루세요. 정확한 명령과 수신 측에서 해석한 경로를 기록하고, 같은 명령에 --dry-run과 --itemize-changes를 추가해 실행한 뒤 빈 스냅샷에 기록하고 장치 번호와 inode를 비교합니다. 해시 일치는 바이트가 같다는 뜻일 뿐 저장 공간 공유를 증명하지 않습니다.
1. 명령을 확정하고 빈 대상을 준비하세요
원본과 대상 경로 끝의 슬래시, -a를 풀어 쓴 옵션 목록, -R 또는 --relative, -H, ACL 또는 xattr 옵션, 제외 규칙, 모든 --link-dest를 포함하여 정확한 rsync 명령을 장애 조사 기록에 그대로 옮겨 두세요. 새로 만든 빈 스냅샷 디렉터리에서 작업하세요. rsync 공식 매뉴얼은 대상에 이미 존재하는 파일의 속성이 변경될 수 있으며, 항목별 변경 출력도 해석하기 어려워질 수 있다고 경고합니다.
진단을 간단히 하려고 --ignore-times를 추가하지 마세요. rsync 매뉴얼은 이 옵션이 --link-dest의 링크 생성을 막는다고 명시합니다. 링크 생성은 전송을 대신하는 작업이며, 업데이트가 끝난 뒤에 수행하는 두 번째 처리 단계가 아니기 때문입니다.
2. 대상 디렉터리를 기준으로 비교 기준 경로를 해석하세요
DEST=/backups/2026-10-28이고 --link-dest=../2026-10-27이라면 비교 기준 경로는 /backups/2026-10-27로 해석됩니다. 대상 경로와, 대상 경로에 비교 기준의 상대 경로를 조합한 경로에 realpath를 사용하고, 새 전송이 만들어 낼 것과 같은 상대 경로에 이전 파일이 있는지 확인하세요. 상대 경로로 지정한 비교 기준을 현재 셸 디렉터리에서 출발해 해석하지 마세요.
끝에 슬래시가 있는 원본은 디렉터리 내용을 전송하고, 슬래시가 없으면 원본 디렉터리 계층이 하나 더 생깁니다. --relative는 원본 접두 경로도 보존합니다. 절대 기준 경로는 DIR 시작 위치의 모호함만 없애며 --relative가 추가한 접두 경로를 제거하지 않습니다. 이전 트리에도 전송된 것과 같은 상대 경로가 있어야 합니다.
3. 바이트 일치와 속성 일치를 따로 확인하세요
원래 rsync 명령을 같은 실행 시작 호스트, 사용자 계정, 작업 디렉터리에서 실행하세요. 원본과 대상 끝점 및 나머지 모든 옵션은 바꾸지 않고 --dry-run과 --itemize-changes만 추가합니다. 비교 기준 경로, 대상 경로와 각각의 장치 번호는 수신 측 호스트에서 확인하세요. 체크섬이 같다고 멈추지 말고 항목별 출력 문자를 해석합니다. p, o, g, t, a 또는 x 차이는 rsync가 로컬 복사본을 만든 이유일 수 있습니다. 하드 링크된 이름마다 서로 다른 inode 메타데이터를 가질 수는 없습니다.
stat로 원본 파일과 이전 스냅샷의 후보 파일을 비교하면서 모드, 소유자, 그룹, 크기, 수정 시간을 기록하세요. 어떤 속성을 의도적으로 보존하지 않는다면 이를 명시적인 정책으로 정하고, 원본과 이전 스냅샷, 새 실행에 일관되게 적용하세요. 중복 제거를 억지로 성립시키려고 보존 옵션을 무작정 빼서는 안 됩니다.
4. 파일시스템과 rsync의 제약을 확인하세요
GNU 문서에 따르면 하드 링크는 파일시스템 경계를 넘을 수 없습니다. 이전 파일과 새 대상 디렉터리의 장치 번호를 기록하세요. 장치 번호가 다르더라도 rsync가 이전 파일을 전송의 기준 파일로 사용할 수는 있지만, 파일시스템을 가로지르는 하드 링크를 만들 수는 없습니다. 특수 파일 유형과 파일시스템에는 추가 제약이 있을 수 있습니다.
-H와 --link-dest를 구분하세요. -H는 원본에 이미 있는 하드 링크 그룹을 보존합니다. --link-dest는 변경되지 않은 파일에 대해 다른 스냅샷 계층에 있는 파일로 연결되는 링크를 만듭니다. 어느 한 옵션도 다른 옵션의 잘못된 비교 기준 경로를 고쳐 주지는 않습니다.
5. 한 번 실행한 뒤 링크를 입증하세요
실제로 실행할 때는 검토한 명령에서 --dry-run(또는 -n을 사용했다면 -n)을 제거하고 나머지 검토한 옵션을 유지한 채 rsync로 빈 대상에 기록하세요(아래 stat -c 검사는 GNU stat을 사용합니다). 변경되지 않은 일반 파일을 표본으로 골라, 이전 경로와 새 경로에 stat -c '%d %i %h %a %s %Y %n'을 사용하세요. 장치 번호와 inode 번호가 일치할 때에만 저장 공간이 절약되었다는 주장을 인정하세요. 링크 수에도 이름이 하나 더 추가되었다는 사실이 반영되어야 합니다.
내용 무결성을 확인하기 위해 해시도 기록하되, 두 검증에서 내리는 결론은 구분하세요. 로컬 rsync 3.2.7 검증용 픽스처에서는 속성이 정확히 일치할 때 같은 inode와 링크 수 2가 나왔습니다. 모드만 바꾸면 항목별 출력에 cf...p.....가 나타나고 새 inode가 생성되었습니다. --ignore-times를 사용하면 >f.........가 나타나고 또 다른 새 inode가 생성되었습니다. 모든 SHA-256 해시는 일치했는데도 이러한 결과가 나왔습니다.
6. 버전별 실패는 증거를 갖춰 보고하세요
상위 단계로 넘기기 전에 관찰 결과로 분기하세요. 계산한 --relative 경로에 이전 후보 파일이 없으면, 전송되는 경로의 계층과 선택한 이전 스냅샷에 그 파일이 포함되어 있고 작업이 성공적으로 완료되었는지를 모두 확인합니다. 파일이 없다는 사실만으로 접두 경로 불일치를 단정할 수는 없습니다. 경로 계층의 불일치를 확인했다면 전송 설정의 경로 구조를 바로잡으세요. 참조 스냅샷이 불완전하거나 그 파일이 없다면, 사용할 수 있는 경우 해당 후보가 포함된 검증된 완전한 참조 스냅샷을 선택합니다. 사용할 참조가 없다면 그 파일은 새로 복사될 것으로 예상하세요. p, o, g, t, a 또는 x 표시는 보존 대상 속성값이 다르다는 뜻입니다. 무엇을 변경할지 결정하기 전에 원본과 이전 파일의 메타데이터를 의도한 보존 정책과 비교하세요. -I 또는 --ignore-times는 링크로 전송을 대체하는 동작을 끄며, 장치 번호가 다르면 하드 링크를 만들 수 없습니다. 이 검사를 모두 통과한 경우에만 로컬과 원격 rsync 버전, 전송 모드, 항목별 출력과 최소 재현을 기록하세요. 2026년의 1차 이슈는 daemon 상대 기준 경로 회귀로 데이터가 경고 없이 다시 전송되는 문제를 기록했고, 이 문제는 프로젝트에서 수정되었습니다. 모든 실패를 같은 버그로 단정하지 말고 버전 증거를 보존하세요.
이 절차가 증명하는 것은 표본으로 선택한 경로에서 일반 파일의 하드 링크가 재사용된다는 사실입니다. 모든 ACL, xattr, 심볼릭 링크, 장치 노드, 원격 마운트 또는 이전 rsync 빌드를 인증하는 것은 아닙니다. 백업이 지원을 약속하는 정확한 파일 유형을 중심으로 표본을 넓힌 뒤, 새 스냅샷에서 inode가 재사용되는지와 예상치 못한 전송 바이트 수가 발생하는지를 모니터링하세요.
