検証の三段階

LabHub 에서 이어서 보기

한국어 원문으로 표시합니다.

한 줄 요약

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

階層図: 존재하는가 → 읽히는가 → 복구되는가・"최근 성공이 24시간 이내인가"・압축이 정상인데 tar 구조가 깨진 경우도 있고 그 반대도 있다.・이것만이 진짜 검증이다.

왜 이게 필요했나

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

어떻게 동작하나

1단계 — 존재하는가

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

ls -lh /backup/prod/ | tail -5
find /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 bash
set -euo pipefail
ARCHIVE="${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 를 쓰는 이유 중 하나가 자체 체크섬이다.

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

3-2-1 이 지금도 유효한 이유

오래된 규칙이지만 클라우드에서도 그대로입니다.

사본 3개 · 매체 2종 · 오프사이트 1개

여기에 요즘은 두 가지가 더 붙습니다.

1개는 오프라인 또는 불변(immutable) — 랜섬웨어가 백업까지 암호화하는 것이 표준 수법입니다. Object Lock 의 COMPLIANCE 모드처럼 관리자도 못 지우는 사본이 하나 있어야 합니다.
0개의 검증되지 않은 사본 — 확인하지 않은 백업은 사본으로 세지 않습니다.

두 번째가 이 모듈의 요점입니다. 백업 개수를 자랑하는 것보다 복원해 본 백업이 하나라도 있는지 가 중요합니다.

무결성 검증을 자동화하기

사람이 기억해서 하는 검증은 언젠가 멈춥니다. 세 층을 자동으로 돌립니다.

# 1) 파일이 온전한가 — 매일
sha256sum -c backup-2026-09-06.sha256
gzip -t backup-2026-09-06.sql.gz          # 압축 무결성만 확인(빠르다)

# 2) 읽을 수 있는가 — 주마다
pg_restore --list backup.dump > /dev/null  # 목록만 뽑아 본다

# 3) 복원되는가 — 분기마다
pg_restore -d verify_db backup.dump && psql verify_db -c "select count(*) from orders"

1번은 몇 초, 2번은 몇 분, 3번은 몇 시간입니다. 비용에 맞춰 주기를 다르게 두는 것이 실무의 답입니다. 셋 다 안 하면 "백업이 있다" 는 믿음만 남습니다.

검증 결과를 어디에 남기나

검증이 실패했는데 아무도 모르면 안 한 것과 같습니다. 세 가지를 갖춥니다.

지표 — 마지막 성공 시각을 게이지로 내보냅니다. time() - last_success > 2일 이면 경보. 실패 건수보다 마지막 성공으로부터의 경과 가 정확한 신호입니다.
기록 — 언제 무엇을 어떻게 검증했고 결과가 무엇인지. 감사에서 요구합니다.
경보 — 백업 자체의 실패와 검증의 실패를 다른 경보 로 둡니다. 원인과 대응이 다릅니다.

# 백업이 돌지 않는다 (심각)
time() - backup_last_success_timestamp > 86400 * 2

# 백업은 도는데 검증이 실패한다 (더 심각 — 있다고 믿었던 것이 없다)
backup_verify_success == 0

두 번째가 더 심각합니다. 백업이 안 도는 것은 알아채기 쉽지만, 돌고 있는데 쓸 수 없는 상태 는 필요한 순간까지 아무도 모릅니다.

다음 실습에서 할 것

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