백업 파일은 매일 쌓이고 있었는데 복구가 안 됐던 이유

문제 발생

매일 새벽 물리 백업이 정상적으로 쌓이고 있었습니다. 용량도 맞고 오류 로그도 없었습니다.

실제로 복구가 필요해졌을 때, 백업 디렉터리를 datadir에 넣고 서버를 올리자 InnoDB가 크래시하며 올라오지 않았습니다.

원인 분석

복사가 끝난 파일이 곧 복구 가능한 상태는 아닙니다. MariaDB 문서가 이유를 그대로 적습니다 — mariadb-backup이 대상 디렉터리에 만드는 데이터 파일들은 백업 작업 중 서로 다른 시점에 복사되기 때문에 point-in-time consistent 하지 않습니다.

그래서 복구 전에 반드시 준비 단계가 필요합니다.

mariadb-backup --prepare --target-dir=/var/mariadb/backup/

문서는 이 단계를 거치지 않은 상태에 대해서도 경고합니다 — 원본 전체 백업에서 그대로 복구하려 하면 InnoDB가 데이터를 보호하기 위해 크래시합니다. 즉 우리가 본 크래시는 고장이 아니라 안전장치가 작동한 것이었습니다.

진짜 문제는 이걸 사고 당일에 알았다는 점입니다. 백업 스크립트는 매일 성공했고, 아무도 복구를 해본 적이 없었습니다.

해결 방안

1. 세 단계를 하나의 절차로 문서화합니다. 백업만 자동화하고 나머지를 사람의 기억에 두지 않습니다.

mariadb-backup --backup  --target-dir=/backup/$(date +%F)   # 1. 백업
mariadb-backup --prepare --target-dir=/backup/$(date +%F)   # 2. 준비(필수)
mariadb-backup --copy-back --target-dir=/backup/$(date +%F) # 3. 복구
chown -R mysql:mysql /var/lib/mysql/                        # 4. 소유권 복구

문서가 명시하듯 복구 시 datadir은 비어 있어야 하고, 복구 후 파일 소유권을 고쳐야 서버가 올라옵니다.

2. 복구 리허설을 주기적으로 합니다. 별도 서버(또는 컨테이너)에 최신 백업을 복구해 서비스가 뜨는지, 최근 데이터가 있는지 확인합니다. 이 리허설을 통과한 적 없는 백업은 백업이 아니라 파일입니다.

3. 리허설을 자동화하고 결과를 알립니다. 매주 복구가 성공했는지 여부만 알림으로 받아도, 조용히 깨진 백업을 몇 달씩 안고 가는 상황이 사라집니다.

4. 복구 시간(RTO)을 재둡니다. "복구는 되는가"와 "몇 시간 걸리는가"는 다른 질문입니다. 실제로 재보면 대개 예상보다 깁니다.

5. 논리 백업도 함께 검토합니다. 문서 설명대로 논리 백업은 CREATE/INSERT 문으로 구성되어 하드웨어와 DB 버전 간 이식성이 좋고, 물리 백업은 더 빠르지만 이식성이 떨어집니다. 테이블 하나만 되살리는 상황에서는 논리 백업이 훨씬 편합니다.

6. 백업을 다른 곳에 둡니다. 같은 서버, 같은 디스크에 있는 백업은 그 서버가 죽는 시나리오를 전혀 막지 못합니다.

공식 문서

• MariaDB: Full Backup and Restore with mariadb-backup
• MariaDB: Backup and Restore Overview