제품 선택
📝

백업 ZIP 복원 확인: 파일 수가 같아도 놓치는 손상 찾기

백업 ZIP을 새 폴더에 복원하고 파일 경로·크기·SHA256을 비교하는 방법입니다. 합성 파일 8개의 실제 시험과 누락·같은 크기 손상 대조 결과, 재현 스크립트와 CSV를 제공합니다.

백업 ZIP 복원 확인: 파일 수가 같아도 놓치는 손상 찾기

백업 폴더에 ZIP이 있고 압축 해제가 끝났다면, 그 안의 내용도 원본과 같을까요? 확인하려면 복원한 파일의 상대경로·바이트 크기·SHA256을 원본 기록과 나란히 비교해야 합니다. SHA256은 파일 내용으로 계산하는 긴 지문입니다. 이름과 크기가 그대로여도 내용이 바뀌면 지문 비교에서 차이를 찾을 수 있습니다.

이 글의 목표는 백업 프로그램을 고르는 것이 아닙니다. 원본을 덮어쓰지 않는 작은 복원 시험을 하고, 결과표에서 누락과 내용 변경을 구분하는 것입니다. MillionsCode 편집실은 이를 확인하기 위해 합성 파일 8개를 만들고 실제로 압축·복원했습니다. 이어 두 가지 오류를 일부러 넣어 검사기가 차이를 찾는지도 확인했습니다. 실제 고객 자료나 개인 백업은 사용하지 않았습니다.

8개 파일 실측과 검증 방법

2026년 9월 28일 Windows 환경에서 PowerShell 7.6.0-rc.1과 Microsoft.PowerShell.Archive 1.2.5로 실행했습니다. 안정판 여러 버전의 호환성을 비교한 시험은 아닙니다. 데이터에는 0바이트 파일, 공백이 든 한글 파일명, 각각 4바이트지만 내용이 다른 두 파일, 서로 다른 하위 폴더에 들어 있는 같은 이름의 파일, 256바이트 이진 파일과 안내문을 넣었습니다. 합계는 8개, 372바이트였습니다.

먼저 원본의 파일 목록을 만들었습니다. nested/level2/sample.txt처럼 시험 폴더에서부터의 위치를 상대경로로 적고, 각 파일의 크기와 SHA256을 저장했습니다. 그 폴더를 ZIP으로 묶은 뒤 새 폴더에 풀었습니다. 원본과 복원본의 경로가 같은 파일끼리 크기와 지문을 비교했습니다. 단순 파일명만 비교하면 서로 다른 폴더의 sample.txt 두 개를 혼동할 수 있습니다.

시험 조건원본 파일 수비교 대상 파일 수일치발견한 차이
ZIP을 새 폴더에 정상 복원888없음
복원본을 다시 복사하면서 파일 하나를 의도적으로 제외877중첩 폴더의 15바이트 파일 누락
별도 복원본의 AAAA를 ZZZZ로 변경8874바이트 파일의 SHA256 불일치

첫 시험은 정상 경로입니다. 나머지 둘은 오류를 넣으면 실패로 표시되는지 보는 대조 시험입니다. ZIP 도구가 파일을 잃거나 손상시켰다는 결과가 아닙니다. 누락은 복사 단계에, 내용 변경은 압축 해제 후의 별도 복사본에 편집실이 직접 넣었습니다.

세 번째가 특히 유용합니다. 파일 수는 8개로 같고 바뀐 파일도 전후 4바이트였습니다. 폴더 크기나 파일 개수만 확인하면 통과시킬 수 있는 상황이지만, 내용 지문을 대조하자 해당 파일 하나가 달랐습니다. 파일 수와 크기는 빠른 확인 항목이고, 내용 일치 확인은 별도 단계라는 것을 보여 줍니다.

결과 CSV는 이렇게 읽습니다

함께 제공하는 restore-summary.csv는 위 세 시험을 요약합니다. restore-comparison.csv에는 파일별 24행이 있습니다. Case는 시험 이름, RelativePath는 폴더 안 위치입니다. ExpectedBytes와 ActualBytes는 원본과 비교 대상의 크기이고, 두 SHA256 열은 내용 지문입니다.

  • MATCH: 이 상대경로의 크기와 내용 지문이 모두 일치했습니다.
  • MISSING: 원본 목록에 있는 경로가 비교 대상에 없었습니다. 이때 실제 크기의 빈칸은 0바이트가 아니라 파일 없음입니다.
  • HASH_MISMATCH: 같은 크기였지만 내용 지문이 달랐습니다. 파일을 다시 복원해 확인할 대상입니다.
  • 검사 스크립트는 크기가 다르면 SIZE_MISMATCH, 원본 목록에 없던 파일이면 UNEXPECTED로 표시합니다. 이 두 분기는 이번 세 시험에서 별도로 오류를 주입해 검증하지 않았습니다.

예를 들어 same_size_change의 same-a.txt 행은 크기가 양쪽 모두 4입니다. 하지만 원본 지문은 63C1DD95…, 변경본은 96741164…로 시작합니다. 실제 비교는 앞부분만 쓰지 않고 전체 64자리로 했습니다. 반면 empty.txt는 원래부터 0바이트이며 정상 복원에서도 같은 지문이 나왔습니다. “0바이트니까 손상”이라고 일괄 판단하면 의도적으로 빈 파일까지 잘못 걸러냅니다.

내 자료로 옮기기 전에 안전하게 따라하기

재현용 스크립트 원문을 먼저 읽고, 연습 폴더에 restore-lab.ps1이라는 이름으로 저장합니다. 파일 확장자가 .ps1.txt로 남지 않았는지 확인하세요. 재현용 restore-lab.ps1은 사용자 파일 경로를 입력받지 않습니다. 저장된 위치 아래에 매번 새로운 시험 폴더를 만들고, 자체 생성한 파일만 압축·복원·변경합니다. 원본 파일을 삭제하는 명령과 기존 복원본을 강제로 덮어쓰는 옵션도 없습니다. 먼저 비어 있는 연습 폴더에 이 스크립트를 놓고 내용을 읽은 뒤 PowerShell에서 실행하세요. 회사 정책으로 스크립트 실행이 막혀 있다면 정책을 임의로 해제하지 말고 아래 수동 흐름으로 결과를 이해해도 됩니다.

# restore-lab.ps1을 저장한 연습 폴더에서 실행
& '.\restore-lab.ps1'

실행 결과의 zip_restore는 PASS, 의도적 오류 두 건은 FAIL이어야 합니다. 마지막 ControlBehavedAsExpected가 세 행 모두 True라면 이번 정상·오류 조건에 대해 검사 결과가 예상대로 나왔다는 뜻입니다. 오류 시험의 FAIL을 정상 백업 실패와 혼동하지 마세요. 실험을 끝내면 화면에 표시된 새 폴더에서 CSV와 results.json을 열어 실행 시각, 버전, 전체 지문을 확인할 수 있습니다.

자신의 실제 백업을 확인할 때는 압축을 만들 당시의 원본 목록을 기준으로 삼아야 합니다. 그 뒤 수정된 현재 파일과 비교하면 정상적인 과거 백업도 불일치로 나올 수 있습니다. 중요한 파일의 복사본으로 먼저 연습하고, 복원 대상은 기존 자료가 없는 새 폴더로 정하세요. 압축을 풀 때 원본 위치를 목적지로 고르지 않습니다.

핵심 명령은 다음과 같습니다. 경로는 설명용 예시이므로 자신의 연습 폴더에서만 바꿔 사용합니다. 첫 명령은 연습용 원본을 압축하고, 두 번째는 ZIP을 새 위치에 복원하며, 마지막 두 명령은 대응하는 파일의 지문을 보여 줍니다. 복원본에 source 폴더가 한 단계 더 생기는 것은 폴더 자체를 압축했기 때문입니다.

Compress-Archive -LiteralPath '.\source' -DestinationPath '.\trial.zip'
Expand-Archive -LiteralPath '.\trial.zip' -DestinationPath '.\restore-new'
Get-FileHash -LiteralPath '.\source\notes.txt' -Algorithm SHA256
Get-FileHash -LiteralPath '.\restore-new\source\notes.txt' -Algorithm SHA256

Microsoft의 Get-FileHash 안내에서 내용 지문 비교와 SHA256 기본값을 확인할 수 있습니다. Expand-Archive 안내는 목적지 지정과 덮어쓰기 옵션을 구분합니다. 이 예시는 -Force로 기존 파일을 덮어쓰지 않습니다.

통과했어도 아직 확인하지 않은 것

Q. 통과하면 전체 백업도 안전한가요?

이번 PASS는 8개 합성 파일의 위치·크기·내용이 복원 후 일치했다는 뜻입니다. SSD 속도, 디스크 수명, 클라우드 동기화 성공률이나 대용량 백업 신뢰도를 측정하지 않았습니다. 하나의 환경에서 실행했으며 파일 권한, 소유자, 암호화 키, 앱 설정과 열린 데이터베이스도 시험하지 않았습니다. 스프레드시트나 사진은 실제 앱에서 열리는지, 업무 프로그램은 필요한 연결 자료까지 돌아오는지 따로 확인해야 합니다.

Q. 숨김·대용량 파일도 같은 방법으로 확인하나요?

Microsoft의 Compress-Archive 문서는 숨김 파일·폴더를 건너뛸 수 있고 파일 크기 제한이 있음을 설명합니다. 이 작은 ZIP 예제를 운영체제 전체나 숨김 설정까지 보존하는 백업 방법으로 확대하지 마세요. 이번 원본에는 숨김 파일과 2GB 이상 파일을 넣지 않았습니다.

Q. 원본과 지문이 같으면 검증은 끝인가요?

또한 비교 기준 목록 자체가 틀리거나 함께 변조되면 지문 일치만으로 진짜 원본을 보장할 수 없습니다. 별도로 보관한 기준 목록과 생성 시점을 확인하고, 누락·불일치가 있다면 원본을 지우기 전에 해당 경로를 다시 복원해야 합니다. 파일 목록과 지문 검사를 통과한 뒤 실제로 필요한 문서를 열어 보는 것까지 마치면, 단순히 ZIP이 있다는 확인보다 다음 복구 행동을 훨씬 구체적으로 정할 수 있습니다.

관련 글