Rsync 미러 복사가 실수로 삭제된 파일을 백업에 복사하는 이유는 무엇인가요?

rsync 미러는 미러가 현재 소스와 대상이 일치하도록 설계되었기 때문에 실수로 삭제된 파일도 복사합니다. 작업이 다음을 사용할 때 --delete 또는 관련 삭제 옵션으로, 홈 NAS에서 누락된 파일은 백업 대상에서 추가 파일로 간주되어 동기화 중에 제거됩니다. 이 동작은 미러에는 적합하지만 유일한 복구 기록으로는 안전하지 않습니다.

Rsync는 모든 과거 버전을 보존하는 것이 아니라 미러 규칙을 따릅니다

삭제 옵션이 없으면 rsync는 일반적으로 새 파일과 변경된 파일만 복사하고 대상 전용 파일은 그대로 둡니다. --delete 옵션을 사용하면 대상이 소스와 일치하도록 조정됩니다. 이 플래그에 대한 간결한 설명은 소스에서 파일을 삭제하면 대상에서도 삭제되어 대상이 진정한 미러 상태를 유지한다는 것입니다.

ZimaSpace 홈 NAS의 경우, 삭제된 가족 사진, 이름이 바뀐 미디어 폴더, 제거된 컨테이너 구성 또는 일시적으로 마운트되지 않은 상태가 다음 예약 실행 시 USB 또는 원격 미러에 반영될 수 있습니다.

삭제는 누락된 소스 경로에서 시작됩니다

Rsync는 파일이 의도적으로 삭제되었는지, 앱이 정리했는지, 사용자가 실수했는지, 랜섬웨어가 트리를 변경했는지, 또는 소스 데이터셋이 마운트 실패했는지 알지 못합니다. 보이는 소스 트리와 대상 트리를 비교합니다. 객체가 수신 측에만 존재하고 삭제가 활성화되어 있으면 삭제 후보가 됩니다.

삭제 타이밍은 파일이 제거되는 시점을 변경할 뿐, 파일이 제거되는지 여부는 변경하지 않습니다.

관련 옵션은 전송 단계를 제어합니다. --delete-before 복사 전에 대상 전용 파일을 제거합니다, --delete-during 디렉터리가 처리되는 동안 삭제하며, --delete-after 전송이 완료될 때까지 기다립니다. 이들은 여유 공간 동작과 실패 노출에 영향을 미치지만 미러를 버전 관리 백업으로 바꾸지는 않습니다.

타이밍을 신중하게 사용하세요. 전송 전에 삭제하면 용량을 확보할 수 있지만 이전 미러 상태가 더 빨리 사라집니다. 전송 후에 삭제하면 이전 대상 콘텐츠가 더 오래 유지되지만 작업이 완료되면 최종 결과는 여전히 소스와 일치합니다.

마운트 누락은 대량 삭제처럼 보일 수 있음

가장 위험한 홈서버 상황 중 하나는 실제 저장 풀 마운트에 실패한 후 예약된 소스 경로가 빈 디렉터리로 남아 있을 때입니다. 이 경우 rsync는 빈 소스와 채워진 대상을 비교할 수 있습니다. 제안된 안전장치는 실제 동기화 전에 dry-run으로 삭제 예정 수를 확인하는 것입니다.

가정용 NAS에서는 예상된 소스 마운트, 파일시스템 UUID, 마커 디렉터리, 최소 파일 수가 없으면 작업이 실패하도록 설정하세요. 빈 경로가 존재한다고 해서 정상적인 소스로 간주하지 마세요.

삭제된 파일 복구 시도 전에 작업 일시 중지

1. 예약된 rsync 작업을 즉시 비활성화하세요.
2. “스스로 고쳐지는지 보기 위해” 명령어를 다시 실행하지 마세요.
3. 스냅샷, 휴지통, 버전 백업 저장소, 두 번째 오프라인 복사본을 확인하세요.
4. 미러에 여전히 파일이 남아 있다면 다음 실행 전에 rsync 대상 외부의 격리 경로로 복사하세요.
5. 라이브 공유에 복원하기 전에 소스 삭제가 의도된 것인지 확인하세요.

가족 사진을 여러 독립 복사본으로 보관하는 방법에 관한 ZimaSpace 글이 여기에 해당합니다: 동기화된 미러는 한 계층일 뿐, 오래된 파일이 살아남을 수 있는 유일한 장소가 되어서는 안 됩니다.

정확한 삭제 대상 미리보기

--dry-run 옵션과 자세한 항목화, 삭제 보고를 포함해 동일한 명령어를 실행하세요. 소스 및 대상 경로, 후행 슬래시, 제외 항목, 마운트 상태, 계획된 삭제 수를 검토하세요. 최근 rsync 안전성 관련 글에서는 미러가 실수 삭제나 랜섬웨어 피해를 재현할 수 있으므로 별도의 기록 계층이 필요하다고 강조합니다.

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

예상보다 많은 삭제 수가 발생하면 사전 점검 실패로 간주하세요. 의도한 NAS 데이터셋이 마운트되어 있는지, 명령어가 상위 디렉터리나 잘못된 이동식 디스크를 대상으로 하지 않는지 확인을 중단하고 검증하세요.

삭제된 대상 파일을 복구 영역으로 이동

미러가 필요하지만 짧은 복구 창도 원한다면 삭제를 백업 디렉터리나 스냅샷 계층과 결합하세요. Rsync는 교체되거나 삭제된 대상 파일을 즉시 파괴하는 대신 날짜별 복구 디렉터리로 이동할 수 있습니다. 삭제된 rsync 데이터를 보존하는 커뮤니티 가이드는 삭제된 파일을 자체 정리 정책이 있는 별도 위치에 보관할 것을 권장합니다.

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

먼저 중요하지 않은 데이터로 명령을 테스트하세요. 복구 디렉터리는 미러된 하위 트리 밖에 있어야 하며, 그렇지 않으면 이후 실행 시 소스의 일부로 간주되거나 동일한 정책으로 삭제될 수 있습니다.

과거 상태가 중요할 때는 버전 관리 스냅샷을 사용하세요

현재 미러는 “소스가 지금 어떻게 생겼는가?”에 답합니다. 백업은 “실수 이전에 소스가 어떻게 생겼는가?”에 답합니다. 둘 다 필요하다면 빠른 접근을 위해 미러를 유지하고 파일시스템 스냅샷, 하드링크 스냅샷 디렉터리, 버전 관리 백업 도구 또는 두 번째 오프라인 디스크를 추가하세요.

실수로 인한 rsync 삭제 사례는 근본적인 약점을 명확히 설명합니다: 직접 만든 rsync 워크플로우는 명시적인 회전 및 삭제 보호가 필요합니다. 하나의 변경 가능한 대상에 정확한 동기화와 장기 기록을 모두 의존하지 마세요.

자주 묻는 질문

만약 제가 제거한다면 --delete, 그러면 미러가 백업이 되나요?

그 자체로는 아닙니다. 대상에만 있는 파일은 남지만, 덮어쓴 파일은 이전 내용을 잃을 수 있고 특정 날짜에 대한 깔끔한 복원 지점이 없습니다. 스냅샷이나 버전 관리 백업 저장소를 추가하세요.

어떤 삭제 타이밍 옵션이 가장 안전한가요?

--delete-after 전송이 완료될 때까지 삭제를 지연시켜 실행 중에 이전 대상 상태를 더 오래 유지합니다. 완료 시 대상에만 있는 파일은 여전히 삭제하므로 사전 점검과 버전 기록이 필요합니다.

예상치 못한 대량 삭제를 어떻게 막나요?

스케줄을 비활성화하고, 삭제 출력과 함께 드라이런을 실행하며, 소스 마운트와 경로를 확인하고, 삭제 횟수 임계값이나 마커 파일 검사를 설정하세요. 제안된 삭제 목록을 이해하기 전까지는 라이브 명령을 다시 실행하지 마세요.

최종 요약

Rsync는 삭제 옵션이 백업 대상이 보이는 NAS 소스와 일치하도록 만들어 실수로 인한 삭제를 반영합니다. 마운트를 확인하고, 삭제 내용을 미리 보고, 제거된 파일을 격리하며, 버전 관리되거나 오프라인 복구 지점을 유지하여 ZimaSpace 홈 서버 워크플로우를 보호하세요. 미러는 유용할 수 있지만, 기록이 없는 정확한 미러는 사람의 실수로부터 충분한 보호가 되지 않습니다.