기술 가이드 · 실용 가이드
tar의 “file changed as we read it”: 경고를 숨기기 전에 경로 확인
정확한 경로와 원래 상태를 보존하고 디렉터리 변화와 앱 데이터 변화를 구분하세요. 읽을 수 있는 아카이브나 숨겨진 경고는 복원 가능한 백업과 다릅니다.
GNU tar의 “file changed as we read it”은 경로별 확인이 필요합니다. 전체 아카이브가 무용하거나 무해하다고 즉시 단정할 수 없습니다. 생성·추가·갱신 때 종료 코드 1은 파일이 바뀌었고 정확한 파일 집합의 사본이 아님을 뜻합니다. 작업의 실패 처리 정책을 바꾸기 전에 증거를 보존하세요.
1. 경로를 기록하고 입력·출력을 구분
정확한 명령, GNU tar 버전, 작업 디렉터리, 원본 루트, 제외 규칙, 출력 목적지, 시각과 전체 오류 출력을 남기세요. tar 반환 직후 자체 종료 상태를 얻어야 합니다. 이후 명령이나 파이프라인의 마지막 프로세스가 가릴 수 있습니다. 압축기와 I/O 실패도 남기세요. 경고가 파일인지 “.” 디렉터리인지에 따라 다음 질문이 다릅니다.
출력 위치를 입력 트리와 대조하세요. 트리 안에 만들었다면 통제된 재실행에서 별도 목적지로 옮기고 필요한 입력이 계속 포함되는지 확인하세요. 출력 파일을 제외했어도 생성이 상위 디렉터리를 바꿀 수 있습니다. 경고를 없애려고 검토한 집합을 셸 와일드카드로 바꾸지 마세요. 숨김 파일 선택이 달라질 수 있습니다.
2. 데이터 변화와 파일시스템 동작 분류
데이터 책임자에게 해당 경로가 버려도 되는 캐시, 활동 로그, 정적 자산 또는 중요한 앱 상태인지 물으세요. 손실을 허용하는 정책 없이 모든 로그·잠금·임시처럼 보이는 이름을 제외하지 마세요. 디렉터리 경고라면 활동과 파일시스템·컨테이너 계층을 확인하고 모든 하위 파일이 바뀌었다고 단정하지 마세요. 안정됐다고 생각한 원본에서 반복되면 버전과 작은 재현 사례를 보존하세요.
fuse-overlayfs 원본 이슈 384는 단순 진단의 한계를 보여줍니다. 보고자는 하위 항목을 제외해도 루트 경고를 보였고, 관찰된 디렉터리 타임스탬프를 바꾸는 작은 프로그램으로 줄였습니다. 가져온 기록에서 이슈는 열려 있습니다. 이 과거 사례는 계층 확인 근거이지 현재 컨테이너 원인이 같다는 증거나 보편적 수정은 아닙니다.
3. 일관된 원본에서 재실행하고 검증
정적 자산은 조용하고 검토한 임시 원본을 마련하고 tar가 읽는 동안 갱신하지 마세요. 실행 중 데이터베이스는 자체 백업 문서를 따르고 디렉터리 복사만으로 충분하다고 가정하지 마세요. 현재 PostgreSQL 지침은 일반 복사 때 서버 종료, 또는 필요한 WAL을 포함한 올바른 일관 스냅샷을 요구합니다. 여러 볼륨은 조율이 필요하며 연결 차단이나 실시간 복사 반복만으로 같아지지 않습니다.
승인한 원본에서 다른 이름의 아카이브를 만들고 재실행 출력과 상태를 남기세요. 숨김 파일과 의도한 제외를 포함해 필요한 목록과 멤버를 비교하세요. 적절하면 안정된 원본과 대조하고 격리된 시험 위치로 대표 내용을 복원하세요. 목록만으로 앱 복원을 증명하지 못합니다. 상태가 있는 데이터는 앱이 요구하는 복원 검사도 하고 대체본이 기준을 통과할 때까지 원본 아카이브를 보존하세요.
4. 경고 억제를 별도 정책으로 취급
GNU tar의 --warning=no-file-changed는 메시지 제어입니다. --ignore-failed-read는 읽기 실패가 완료 상태에 미치는 처리를 바꾸며 한 메시지를 숨기는 것보다 넓습니다. 둘 다 변하는 데이터를 일관되게 하거나 누락을 되돌리지 않습니다. 옛 Windows·컨테이너·tar 해결법을 복사하기 전에 설치 버전 문서와 실제 종료 상태를 확인하세요.
정확한 경로와 허용된 변화가 설명되고 필요한 내용이 사용 가능하며 다른 실패가 보일 때만 경고를 수용하세요. || true로 0이 아닌 모든 종료 상태를 성공으로 바꾸거나 전체 stderr를 버리거나 래퍼의 0을 복원 준비 완료로 생각하지 마세요. 중요한 데이터, 원인 미상 또는 복원 실패라면 미해결로 남기고 원본이나 앱 백업 방법을 조사하세요.
