파일 체크섬으로 오프라인 일기 백업 검증하는 방법

체크섬 검사가 알려주는 것

체크섬은 파일의 내용을 기반으로 계산된 고유한 값입니다. 내용이 변경되면 계산된 값도 달라지게 됩니다. 따라서 백업 파일을 기준값과 비교하면 복사 또는 저장 과정에서 발생한 변경 사항을 확인하는 데 도움이 됩니다. 디지털 보존 연합(Digital Preservation Coalition)은 체크섬을 성공적인 전송과 지속적인 파일 고정성(fixity)을 확인하는 방법으로 설명하며, 올바르다고 확인된 기준과의 비교를 강조합니다 ([Fixity and checksums](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums)).

이때 기준선 자체가 중요합니다. 이미 손상된 동일한 사본에서 기준선과 비교값을 모두 계산한다면, 값이 일치하더라도 이전 원본에 어떤 내용이 들어 있었는지는 증명되지 않습니다. 또한 일치 결과가 일기 항목이 올바르게 열리는지, 원본이 완전했는지, 혹은 누가 파일을 생성했는지를 증명하지는 못합니다. 이 작업은 의도적으로 선택한 파일 집합에 대한 바이트 단위 비교로 취급해야 합니다.

원본 집합 선택 및 기록

백업할 안정적인 상태의 내보낸 일기 폴더를 확인하고, 해시를 생성하기 전에 모든 편집을 완료하세요. 이 예제는 숨김 파일을 포함한 일반 파일을 다루며, 심볼릭 링크를 추적하거나 실행 중인 애플리케이션 데이터베이스를 실시간으로 온전히 캡처하지는 않습니다. 필요한 경우 연결된 자료를 선택한 폴더로 내보내고 애플리케이션의 내보내기 지침을 확인하세요. 생성된 목록과 매니페스트는 해당 폴더 외부에 저장해야 합니다.

이 예제는 Ubuntu Linux와 같은 환경의 Bash 및 GNU findutils/coreutils를 필요로 하며, 수정되지 않은 기본 macOS 또는 Windows 터미널용 명령어가 아닙니다. 이 예시에서는 가상의 로컬 경로와 새로운 출력 파일명을 사용합니다. 기록을 위해 기존 상위 디렉터리를 사용하고, 이전 기준선을 덮어쓰지 않도록 사용되지 않은 파일명을 선택하세요. 이러한 경로는 사용자의 컴퓨터 환경에 맞는 경로로 바꾸고, 비공개 일기와 생성된 기록은 로컬에만 보관하세요. Ubuntu 매뉴얼에서는 `sha256sum` 생성 및 이전 출력을 검증하기 위한 `--check` 옵션에 대해 다루고 있습니다 ([sha256sum manual](https://manpages.ubuntu.com/manpages/noble/man1/sha256sum.1.html)).

```bash ( set -euo pipefail set -C cd "/home/example/Diary" find . -type f -print0 | LC_ALL=C sort -z > "/home/example/diary-inventory.nul" xargs -0 -r sha256sum < "/home/example/diary-inventory.nul" > "/home/example/diary-source.sha256" test -s "/home/example/diary-source.sha256" ) ```

이 서브셸은 디렉터리 이동 실패나 파이프라인 오류 발생 시 중단되며, 기존 기록 파일을 덮어쓰지 않고, 비어 있는 체크섬 매니페스트를 거부합니다. 오류가 보고되면 불완전한 출력을 기준선으로 사용하지 마세요. 파일 목록은 줄바꿈이 포함된 파일명도 구분될 수 있도록 NUL 구분자를 사용합니다. 두 기록 파일 모두 선택한 폴더 외부에 보관됩니다. 신뢰하기 전에 원본 집합을 일기 내보내기 내용과 대조하여 검토하세요. 매니페스트가 생성되기 전에 누락된 첨부 파일은 매니페스트로 확인할 수 없습니다.

기준선 보호 및 파일 복사

매니페스트와 목록 파일은 작업 중인 원본 및 오프라인 백업 양쪽 모두와 분리된 다른 장소에 저장하세요. 실수로 편집되지 않도록 보호하고, 가능하면 보호된 두 번째 사본을 유지하는 것이 좋습니다. 체크섬 비교는 기준선을 신뢰하고 보존할 수 있는 근거가 있을 때에만 검증 기준으로서 가치를 지닙니다. 디지털 보존 지침에서도 고정성 정보를 기록하고 감사에 사용하는 데이터로 취급합니다. NARA(미국 국립문서기록관리청)는 디지털 보존 프로그램에서 고정성 기록, 파일 작업 추적, 매니페스트 및 로그 생성을 기술하고 있습니다 ([National Archives digital preservation](https://www.archives.gov/preservation/digital-preservation/about)).

평소 사용하는 파일 복사 방식을 이용해 선택한 일기 폴더를 백업 드라이브에 복사하세요. 검사할 때가 아니라면 백업 드라이브는 연결을 해제해 두세요. 여기에 제시된 명령어는 복사 작업을 수행하는 것이 아니라 이미 복사된 파일을 검사합니다. 경로가 변경되면 매니페스트가 예상 파일을 찾지 못할 수 있으므로, 검사하기 전에 백업본을 편집하거나 이름을 바꾸거나 구조를 재구성하지 마세요.

복사된 바이트 검증

오프라인 드라이브를 마운트하고 복사된 일기 폴더로 이동합니다. 원본에서 기록했던 것과 동일한 SHA-256 알고리즘 및 상대 경로를 사용하여 기준선 매니페스트를 바탕으로 검사를 실행합니다:

```bash ( set -euo pipefail cd "/media/example/DiaryBackup/Diary" sha256sum --check --strict "/home/example/diary-source.sha256" ) ```

매니페스트에는 `./`로 시작하는 상대 경로가 저장되어 있으므로, 복사된 일기 폴더 내에서 검증을 실행해야 합니다. `OK`는 해당 파일의 일치를 나타냅니다. 누락되거나 일치하지 않는 파일, 형식이 잘못된 체크섬 줄, 명령 오류 등은 조사가 필요합니다. `--ignore-missing` 옵션으로 오류를 숨기거나 눈에 보이는 몇 개의 `OK` 줄만 보고 전체 검사가 통과되었다고 넘겨짚지 마세요. [Ubuntu 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man1/sha256sum.1.html)에서 이러한 옵션들을 설명합니다.

이 검사는 매니페스트에 없었던 백업 드라이브 상의 추가 파일은 보고하지 않습니다. 추가된 파일이나 예상치 못한 디렉터리 내용을 확인해야 한다면, 별도의 단계로 백업의 파일 목록과 저장된 원본 목록을 비교하세요. 목록이 동일하더라도 저장하려던 모든 일기 항목이 원본 선택 시점에 빠짐없이 포함되어 있었는지는 여전히 증명할 수 없습니다.

증거를 덮어쓰지 않고 불일치 조사하기

파일이 일치하지 않는 경우, 해당 경로를 기록하고 두 사본을 모두 변경되지 않은 상태로 유지하세요. 지정하려던 매니페스트와 작업 폴더가 맞는지 확인한 다음, 원본과 백업을 별도로 비교합니다. 수정, 이름 변경 또는 불완전한 복사가 원인인지 확인하세요. 조사하는 동안에는 불일치 사본을 보존해야 합니다. 자동으로 덮어쓰면 원인을 규명할 증거가 사라집니다.

디지털 보존 지침에서는 고정성이 상실된 사본을 정상으로 확인된 사본으로 교체하는 방법을 설명하지만, 이는 신뢰할 수 있는 다른 사본이 확보되어 있을 때에만 가능합니다 ([Digital Preservation Coalition](https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums)). 개인 일기의 경우, 이는 확인 가능한 증거를 충분히 비교한 후에 내려야 할 결정입니다. 체크섬은 차이점을 찾아낼 뿐, 파일을 복구하거나 올바른 버전을 대신 선택해주지는 않습니다.

한계점 및 실질적인 기록 관리

원본 폴더, 기준선 생성 일자, 알고리즘, 매니페스트 위치, 각 검사 결과를 담은 간단한 로컬 기록을 남겨두세요. 추후 검사할 때는 검사 대상인 백업본에서 기준선을 다시 생성하지 말고, 기존에 확립된 기준선을 유지해 사용하세요. 의도적인 수정이나 형식 변환이 있었다면 새 버전을 별도로 문서화하세요. 가끔씩 직접 파일을 열어보고 복원 검사를 병행해야 합니다. 바이트 수준의 고정성만으로는 일기를 앞으로도 계속 정상적으로 열어볼 수 있는지까지 보장할 수는 없습니다.

이 주제 더 살펴보기