Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

데이터베이스 관리 및 사이트 안정성 엔지니어링의 고위험 세계에는 잘 알려진 격언이 있습니다. 바로 슈뢰딩거의 백업(Schrödinger’s Backup)입니다. 백업의 상태는 복원을 시도하기 전까지는 알 수 없습니다. 그 순간까지 백업은 완벽하게 실행 가능한 상태와 완전히 손상된 상태라는 양자적 중첩 상태로 존재합니다.

DevOps 엔지니어와 DBA에게 활성 인시던트 중에 중요한 데이터베이스 백업이 손상되었음을 발견하는 것은 최악의 악몽과 같은 시나리오입니다. 이는 일상적인 복구 작업을 치명적인 데이터 손실 이벤트로 바꿔버립니다. 이러한 데이터 무결성의 “소리 없는 살인자”는 백업 작업이 기본 페이로드가 손상되었을 때조차도 Exit Code 0(성공)을 보고하는 경우가 많기 때문에 종종 간과됩니다.

이 종합 가이드에서는 백업 손상의 해부학적 구조를 분석하고, 데이터베이스별 검증 기술을 탐색하며, 프로덕션 환경을 위한 자동화된 완벽한 복원 파이프라인을 구축하는 방법을 설명합니다.

백업 손상의 해부학

손상을 감지하려면 먼저 손상이 어떻게 발생하는지 이해해야 합니다. 백업 손상은 일반적으로 물리적(인프라 수준) 손상과 논리적(애플리케이션 수준) 손상의 두 가지 범주로 나뉩니다.

물리적 손상

물리적 손상은 저장 매체의 실제 비트가 변경될 때 발생합니다. 이는 소스 디스크에서 읽는 과정, 네트워크 전송 중 또는 대상 저장소에 저장된 상태에서 발생할 수 있습니다.
* 비트 로트(Bit Rot): 저장 매체의 점진적인 성능 저하로 인해 비트가 조용히 뒤바뀔 수 있습니다.
* 전송 오류: TCP에는 체크섬이 있지만, 이는 16비트로 매우 취약합니다. 처리량이 많은 환경에서는 TCP가 잡아내지 못하는 데이터 손상이 전송 중에 발생할 수 있습니다.
* 스토리지 컨트롤러 결함: RAID 컨트롤러나 SAN 패브릭의 하드웨어 버그로 인해 OS에는 성공으로 보고되면서 실제로는 쓰레기 데이터가 기록될 수 있습니다.

논리적 손상

논리적 손상은 백업 파일 자체는 완벽하게 온전하지만 그 안의 데이터가 깨져 있기 때문에 더 위험할 수 있습니다.
* 가비지 인, 가비지 아웃(GIGO): 라이브 데이터베이스에 손상된 인덱스나 찢어진 페이지(torn page)가 있는 경우, 백업 도구는 해당 손상된 페이지를 충실히 복사할 수 있습니다. 백업 작업은 성공하지만 복원 시 실패하거나 데이터베이스가 깨진 상태가 됩니다.
* 불완전한 트랜잭션: 데이터베이스 I/O를 적절히 고정하지 않고(예: MySQL에서 FLUSH TABLES WITH READ LOCK을 사용하지 않음) 파일 시스템 수준에서 스냅샷을 찍으면 찢어진 페이지가 발생하고 복구할 수 없는 상태가 됩니다.

사전 예방적 감지: 체크섬 및 암호화 해싱

물리적 손상에 대한 첫 번째 방어선은 암호화 검증입니다. 파일 크기나 수정 날짜에 의존하는 것만으로는 충분하지 않습니다.

데이터베이스 수준의 체크섬 활성화

현대적인 관계형 데이터베이스 관리 시스템(RDBMS)은 페이지 수준의 체크섬을 지원합니다. 활성화되면 데이터베이스는 디스크에 쓰기 전에 모든 페이지에 대한 체크섬을 계산합니다. 페이지를 읽을 때(쿼리나 백업 프로세스에 의해) 체크섬이 검증됩니다.

PostgreSQL의 경우 클러스터 초기화 중에 데이터 체크섬을 활성화할 수 있습니다:

# 체크섬이 활성화된 새로운 PostgreSQL 클러스터 초기화
initdb --data-checksums -D /var/lib/postgresql/data

참고: 기존 PostgreSQL 클러스터가 있는 경우 pg_checksums 유틸리티를 사용하여 오프라인에서 활성화할 수 있습니다.

Microsoft SQL Server의 경우 PAGE_VERIFY가 CHECKSUM으로 설정되어 있는지 확인하십시오(최신 버전에서는 기본값이지만 레거시 시스템에서는 확인이 필요합니다):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

저장된 백업 검증

백업이 스토리지 대상에 도달하면 암호화 방식으로 무결성을 검증해야 합니다. CloudSave와 같은 엔터프라이즈 백업 플랫폼은 전송 중 및 저장 시 백업 블록의 SHA-256 해시를 자동으로 계산하고 검증합니다. 사용자 지정 스크립트를 관리하는 경우 이를 수동으로 구현해야 합니다:

# 백업 생성 후 SHA-256 해시 생성
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# 스토리지 서버에서 해시 검증
sha256sum -c prod_db_backup.tar.gz.sha256

데이터베이스별 검증 기술

각 데이터베이스 엔진은 백업 아티팩트의 무결성을 검증하기 위한 기본 도구를 제공합니다.

PostgreSQL: pg_verifybackup

PostgreSQL 13에서 도입된 pg_verifybackup은 pg_basebackup으로 수행된 물리적 백업을 위한 획기적인 도구입니다. 백업 중에 생성된 backup_manifest 파일을 읽고 모든 파일이 존재하며 체크섬이 일치하는지 확인합니다.

# 물리적 베이스 백업 디렉토리에 대해 검증 실행
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

데이터 파일 중 하나라도 비트가 뒤바뀌면 pg_verifybackup은 치명적인 오류를 발생시켜 모니터링 시스템이 즉시 DBA 팀에 알릴 수 있도록 합니다.

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server는 백업 파일을 실제로 복원하지 않고도 물리적 무결성을 확인할 수 있는 기본 명령을 제공합니다. 이 명령은 백업 헤더를 확인하고 페이지 체크섬을 검증합니다(백업 시 활성화된 경우).

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

경고: RESTORE VERIFYONLY는 백업 파일이 읽기 가능하고 물리적 체크섬이 일치한다는 것만 확인합니다. 논리적 무결성을 보장하지는 않습니다. 논리적 무결성을 보장하려면 전체 복원을 수행하고 DBCC CHECKDB를 실행해야 합니다.

MySQL / InnoDB: Percona XtraBackup

MySQL 환경의 경우 물리적 백업은 종종 Percona XtraBackup으로 처리됩니다. 백업 프로세스는 파일 복사로 구성되지만, 트랜잭션 로그(redo logs)가 적용되기 전까지는 백업이 일관된 상태가 아닙니다. --prepare 단계가 내장된 무결성 검사 역할을 합니다.

# 백업 준비 단계에서 redo 로그가 적용됩니다. 
# 백업이 손상된 경우 이 단계에서 실패합니다.
xtrabackup --prepare --target-dir=/data/backups/mysql/

골드 표준: 자동화된 복원 테스트

체크섬과 검증 명령은 필요하지만 충분하지는 않습니다. 백업이 실행 가능하다는 것을 확실하게 증명하는 유일한 방법은 복원하는 것입니다. 현대적인 DevOps 환경에서는 이 프로세스가 완전히 자동화되어야 합니다.

백업을 코드로 취급함으로써 데이터베이스 복원을 위한 CI/CD 파이프라인을 구축할 수 있습니다. 이 파이프라인은 일시적인 인프라를 프로비저닝하고, 복원을 실행하며, 검증 쿼리를 실행하고, 환경을 삭제해야 합니다.

자동화된 복원 파이프라인 구축

다음은 PostgreSQL 논리적 덤프를 검증하기 위해 크론 작업이나 CI 러너(GitLab CI 또는 GitHub Actions 등)에 의해 매일 트리거될 수 있는 Bash 스크립트 예시입니다.

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] 자동화된 복원 테스트 시작..."

# 1. 일시적인 PostgreSQL 컨테이너 실행
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# PostgreSQL 준비 대기
echo "[INFO] 데이터베이스 초기화 대기 중..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. 대상 데이터베이스 생성
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. 복원 실행
echo "[INFO] 백업 복원 중..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. 논리적 검증 쿼리 실행
echo "[INFO] 검증 쿼리 실행 중..."
# users 테이블에 10,000개 이상의 레코드가 있는지 확인
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] 논리적 검증 실패. 10,000명 이상의 사용자가 예상되었으나 $USER_COUNT 명 발견됨"
    # 여기서 PagerDuty / Slack 알림 트리거
    exit 1
else
    echo "[SUCCESS] 논리적 검증 통과. 사용자 수: $USER_COUNT"
fi

# 5. 일시적 환경 삭제
echo "[INFO] 정리 중..."
docker rm -f $CONTAINER_NAME

echo "[INFO] 자동화된 복원 테스트 성공적으로 완료."

무엇을 검증해야 하는가?

자동화된 복원 테스트를 수행할 때 데이터베이스가 시작되는지만 확인하지 마십시오. 애플리케이션별 검증 쿼리를 실행하십시오:
1. 행 개수: 핵심 테이블에 예상되는 행 개수가 있는지 확인합니다(예: users 테이블이 비어 있지 않아야 함).
2. 최신 데이터: 지난 24시간 동안 생성된 레코드를 쿼리하여 백업이 오래되지 않았는지 확인합니다.
3. 참조 무결성: 논리적 손상을 나타내는 고아 외래 키(orphaned foreign keys)를 확인하는 스크립트를 실행합니다.

백업 이상 징후에 대한 모니터링 및 알림

재난이 발생하기 전에 손상을 감지하려면 강력한 관측 가능성이 필요합니다. 이진 성공/실패 상태를 넘어 백업 작업의 메타데이터를 모니터링하여 이상 징후를 감지해야 합니다.

휴리스틱 모니터링

백업 메타데이터를 Prometheus에 통합하고 Grafana로 시각화하십시오. 다음 휴리스틱에 대한 알림을 설정하십시오:
* 갑작스러운 크기 감소: 일일 백업이 항상 500GB였는데 오늘 50MB라면, 작업은 성공적으로 완료(Exit Code 0)되었을지라도 빈 스키마만 백업되었을 가능성이 큽니다.
* 소요 시간 이상: 일반적으로 2시간 걸리는 백업이 5분 만에 끝난다면 무언가 건너뛴 것입니다. 반대로 10시간이 걸린다면 손상으로 이어질 수 있는 디스크 I/O 성능 저하가 발생했을 수 있습니다.
* WAL/아카이브 로그 누적: 데이터베이스가 WAL(Write-Ahead Logs)을 생성하는데 백업 시스템이 이를 충분히 빠르게 아카이브하지 못하면 PITR(Point-in-Time Recovery) 체인에 공백이 생길 위험이 있습니다.

무결성 검사를 포함한 3-2-1 규칙 구현

업계 표준인 3-2-1 백업 규칙(데이터 3개 복사본, 2개의 서로 다른 매체, 1개의 오프사이트 보관)은 모든 복사본이 검증될 때만 효과적입니다.

이 지점에서 CloudSave와 같은 엔터프라이즈 솔루션을 활용하면 운영 오버헤드를 크게 줄일 수 있습니다. 모든 데이터베이스 노드에 대해 복잡한 bash 스크립트를 작성하고 유지 관리하는 대신, CloudSave는 인프라와 직접 통합되어 3-2-1 수명 주기를 자동화합니다. 랜섬웨어로부터 보호하는 불변 스토리지(immutable storage)를 제공하며, 내장된 자동 복원 검증 일정을 지원합니다. CloudSave는 격리된 샌드박스 환경을 자동으로 실행하고, 백업을 마운트하며, 사용자 지정 SQL 검증 스크립트를 실행하고, 상태를 중앙 대시보드로 보고할 수 있습니다.

결론

손상된 데이터베이스 백업은 비즈니스를 파괴할 수 있는 소리 없는 살인자입니다. 백업 스크립트의 Exit Code 0에만 의존하는 것은 위험한 도박입니다.

프로덕션 환경을 진정으로 보호하려면 심층 방어 전략을 채택해야 합니다:
1. 데이터베이스 엔진 내에서 페이지 수준 체크섬을 활성화하십시오.
2. 백업 생성 직후 기본 검증 도구(pg_verifybackup, RESTORE VERIFYONLY)를 활용하십시오.
3. 백업 메타데이터(크기, 소요 시간)를 모니터링하여 휴리스틱 이상 징후를 감지하십시오.
4. 일일 운영 파이프라인의 일부로 자동화된 일시적 복원 테스트를 구현하십시오.

수동적인 “설정 후 방치(fire and forget)” 백업 방식에서 능동적인 “지속적 복원 검증” 모델로 전환함으로써, 재난이 불가피하게 닥쳤을 때 데이터가 준비되어 있고 신뢰할 수 있으며 완전히 복구 가능함을 보장할 수 있습니다.

카테고리