도입
dump 명령이 성공하고 파일이 존재해도 그 파일이 원하는 시점과 범위의 데이터를 복원한다는 보장은 없다. 백업은 격리된 환경에 복원하고 구조·데이터·애플리케이션 읽기를 확인해야 운영 가능한 복구 수단이 된다.
MariaDB 10.11의 테스트 DB를 대상으로 하며 운영 DB에는 복원하지 않는다. 명령 실행 전 원본과 복원 대상 이름을 각각 출력해 잘못된 덮어쓰기를 막는다.
검증 기준을 먼저 정한다
| 영역 | 확인값 |
|---|---|
| 파일 | 생성 시각, 크기, SHA-256 |
| 구조 | 테이블, 뷰, 제약, 인덱스 |
| 데이터 | 주요 테이블 행 수와 집계 |
| 사용 | 읽기 전용 애플리케이션 점검 |
개인정보 원문을 비교 자료로 출력하지 않고 행 수, 기간별 합계와 비식별 집계를 사용한다.
백업 파일을 격리 DB에 복원하기
백업 파일과 메타데이터
mariadb-dump --single-transaction --routines --triggers \
--databases test_source > test-source.sql
sha256sum test-source.sql
ls -lh test-source.sql--single-transaction의 일관성 범위는 트랜잭션 스토리지 엔진과 실행 중 DDL 여부에 영향을 받는다. 백업 시작·종료 시각과 MariaDB 버전을 함께 기록한다.
새 DB에만 복원하기
mariadb -e "CREATE DATABASE restore_rehearsal"
mariadb restore_rehearsal < test-source.sql
echo $?
mariadb restore_rehearsal -e "SHOW TABLES"dump가 CREATE DATABASE나 USE를 포함하는지 먼저 검사한다. 위 예시는 형식에 따라 조정하며 운영 DB 이름이 명령에 나타나면 중단한다.
무결성 검증
SELECT COUNT(*) FROM information_schema.tables
WHERE table_schema = 'restore_rehearsal';
SELECT COUNT(*) AS row_count, MIN(created_at), MAX(created_at)
FROM restore_rehearsal.example_table;원본과 복원본에 같은 읽기 전용 쿼리를 실행하고 불일치가 하나라도 있으면 성공으로 처리하지 않는다. 마지막에는 복원 DB를 가리키는 읽기 전용 애플리케이션 스모크 테스트를 수행한다.
복원 성공 메시지 뒤에서 확인할 것
복원은 성공했지만 객체가 빠졌다
증상
테이블은 있지만 routine이나 trigger가 없다.
원인
dump 옵션과 계정 권한이 필요한 객체를 포함하지 않았다.
확인 방법
원본과 복원본의 information_schema 목록을 비교한다.
해결
필요 옵션과 권한을 수정해 새 백업으로 다시 리허설한다.
예방
백업 대상 객체 목록을 설정과 검증표에 함께 둔다.
복원 시간이 목표를 넘는다
증상
데이터는 맞지만 서비스 복구 목표 시간에 맞지 않는다.
원인
전송, 압축 해제, 인덱스 생성과 검증 시간을 포함하지 않았다.
확인 방법
각 단계 시작·종료 시각을 분리한다.
해결
백업 방식과 복구 인프라를 조정하고 다시 측정한다.
예방
정기 리허설 결과로 RTO를 갱신한다.
복원 완료 체크리스트
- 운영과 분리된 새 DB에만 복원했는가?
- 백업 파일의 시각, 크기와 해시를 기록했는가?
- 뷰, trigger와 routine까지 비교했는가?
- 데이터 집계와 읽기 스모크 테스트가 통과했는가?
참고 자료
한 줄 요약
MariaDB 백업은 격리된 새 DB에 복원하고 파일·구조·데이터·애플리케이션 검증을 통과해야 복구 수단으로 인정할 수 있다.
댓글 0