검증의 세 단계

한 줄 요약

백업 검증은 존재하는가 → 읽히는가 → 복구되는가 세 단계다. 앞의 둘은 자동화할 수 있고, 마지막은 사람이 해야 한다.

왜 이게 필요했나

백업이 매일 돌고 있다. 로그에는 성공이라고 찍힌다. 그런데 정작 복구가 필요한 날 파일이 열리지 않는다. 이 상황은 드물지 않다.

어떻게 동작하나

1단계 — 존재하는가

가장 기본이고 의외로 여기서 걸리는 문제가 많다.

ls -lh /backup/prod/ | tail -5find /backup/prod -type f -mtime -1 | wc -l

파일 크기가 0 이 아니고, 최신 시각인지 확인한다. "최근 성공이 24시간 이내인가" 를 모니터링이 감시하게 하는 것이 로그를 읽는 것보다 훨씬 낫다.

2단계 — 읽히는가

압축 무결성과 아카이브 목록을 확인한다.

gzip -t /backup/etc-2026-08-20.tar.gz && echo 'gzip OK'tar -tzf /backup/etc-2026-08-20.tar.gz > /dev/null && echo 'archive OK'sha256sum -c /backup/checksums.sha256

세 가지가 각각 다른 것을 본다. gzip -t 는 압축 스트림의 CRC, tar -t 는 아카이브 구조, sha256sum -c 는 파일 전체의 해시다. 압축이 정상인데 tar 구조가 깨진 경우도 있고 그 반대도 있다.

3단계 — 실제로 복구되는가

이것만이 진짜 검증이다. 다른 호스트나 임시 환경에 복원해 서비스를 띄워 보고, 데이터가 기대한 시점의 것인지 확인한다.

리허설 체크리스트.

• 백업 저장소에 접근할 자격 증명이 운영 서버 밖에 보관되어 있는가
• 복원 절차 문서가 복원 담당자의 노트북이 아닌 곳에 있는가
• 복원에 필요한 암호화 키가 별도로 보관되어 있는가
• 리허설에 걸린 실제 시간이 RTO 안에 들어오는가
• 복원 후 애플리케이션이 기동하고 정합성 검사를 통과하는가

암호화 키 보관은 특히 자주 빠진다. 백업을 암호화해 두고 키를 백업 대상 서버에만 두면, 그 서버가 사라졌을 때 백업은 무의미한 이진 파일이 된다.

리허설 주기는 분기 1회가 현실적인 최소선이다. 그리고 리허설은 백업을 만든 사람이 아닌 다른 사람이 문서만 보고 수행해야 절차의 빈틈이 드러난다.

검증 스크립트의 모양

#!/usr/bin/env bashset -euo pipefailARCHIVE="${1:?usage: verify.sh <archive>}"[ -s "$ARCHIVE" ] || { echo "빈 파일이거나 없음: $ARCHIVE" >&2; exit 1; }gzip -t "$ARCHIVE" || { echo "압축 스트림 손상" >&2; exit 2; }tar -tzf "$ARCHIVE" > /dev/null || { echo "아카이브 구조 손상" >&2; exit 3; }echo "OK $ARCHIVE"

종료 코드를 단계별로 다르게 주는 것이 요령이다. 모니터링에서 어느 단계에서 실패했는지 바로 알 수 있다.

현장에서 만나는 모습

비트 부패(bit rot). 오래 보관한 아카이브가 조용히 손상된다. 디스크 자체는 정상이라고 보고하는데 몇 바이트가 뒤집힌다. 정기적인 체크섬 재검증이 이걸 잡는다. 백업 저장소로 ZFS 나 Btrfs 를 쓰는 이유 중 하나가 자체 체크섬이다.

테이프/오브젝트 스토리지의 조용한 실패. 쓰기는 성공했다고 답했는데 실제로는 저장되지 않는 경우가 있다. 쓰기 직후 읽어서 확인하는 절차가 필요하다.

다음 실습에서 할 것

체크섬 매니페스트를 만들고, 손상을 인위적으로 만들어 탐지하고, 단계별 종료 코드를 가진 검증 스크립트를 작성한다. 채점기가 정상 아카이브와 손상 아카이브 양쪽으로 그 스크립트를 실행한다.