Debian에서 MariaDB 장애가 났을 때 “일단 dump 넣고 서비스 올리자”로 접근하면, 복구는 됐는데 데이터가 일부 누락되거나 권한이 깨지거나, replication/GTID 때문에 뒤늦게 더 큰 문제가 생기는 경우가 많습니다. 이 글은 복구 자체뿐 아니라 백업 검증과 복구 안전장치를 함께 넣어, 운영에서 재현 가능한 절차로 정리했습니다.

Safety vault metaphor for MariaDB backup and restore

급할수록 체크리스트가 시간을 아껴줍니다.

1) 복구 전: 상황 분류와 우선순위(어떤 복구가 필요한가)

복구는 “무엇을 얼마나 되돌릴지(RPO)”, “얼마나 빨리 서비스가 살아야 하는지(RTO)”에 따라 절차가 달라집니다. 먼저 아래 중 어디에 해당하는지 분류하세요.

  • 단일 서버 장애: 디스크/파일시스템 문제, mysqld 비정상 종료, 테이블 손상 등
  • 데이터 실수: 잘못된 DELETE/UPDATE, DROP TABLE/DB
  • 복제(Replication) 환경: primary/replica 중 어느 쪽을 기준으로 복구할지, GTID 사용 여부

가능하면 복구 착수 전에 “사고 시점(대략의 타임라인)”과 “원하는 복구 지점(시간)”을 적어두세요. 나중에 binlog까지 포함한 복구를 할 때 기준점이 됩니다.

Flowchart icons for restore planning and risk isolation

2) 백업 파일 ‘검증’이 먼저: 무결성/복원 가능성 빠르게 확인

백업이 있어도 복원 가능한 백업인지는 별개입니다. 운영 서버에 바로 넣기 전에, 최소한 아래 정도는 확인하는 걸 권장합니다.

  • 백업 종류 확인: logical(SQL dump)인지, physical(xtrabackup/mariabackup)인지
  • 파일 손상 여부: 압축 파일이면 테스트(예: gzip -t), 체크섬이 있으면 대조
  • dump 헤더/푸터 확인: mysqldump라면 파일 상단/하단에 에러 흔적이 없는지
  • 스키마만이라도 시험 복원: 별도 테스트 인스턴스/컨테이너에 CREATE만 먼저 적용

가능하면 Debian에서 임시로 MariaDB를 띄운 뒤(테스트용), dump를 일부라도 import해 “실제로 들어가는지”를 확인하세요. 이 한 번의 사전 검증이, 운영에서 되돌리기 어려운 실수를 크게 줄여줍니다.

3) 복구 안전장치: 운영 영향 최소화를 위한 격리/스냅샷/보존

복구 시작 전에 “원본을 보존”하는 게 핵심 안전장치입니다. 특히 데이터 디렉터리(/var/lib/mysql)에서 작업하기 시작하면 되돌리기가 어려워집니다.

  • 서비스 격리: 앱 서버에서 DB로 쓰기 요청이 오지 않게 먼저 차단(가능하면 점검 모드)
  • mysqld 중지: systemctl stop mariadb 로 확실히 멈춘 뒤 진행(파일 단위 작업 시 필수)
  • 원본 보존: /var/lib/mysql 전체를 다른 디스크로 복사하거나, LVM/ZFS 스냅샷이 있으면 스냅샷 생성
  • 디스크 여유: import/redo 단계에서 임시 공간이 필요(특히 대용량 dump, 대형 redo)

특히 physical restore(예: mariabackup)는 파일을 덮어쓰는 단계가 있어, 스냅샷/사본 없이 진행하면 ‘복구 중 실패’가 ‘완전 손실’로 이어질 수 있습니다.

4) 복구 절차 A: SQL dump(mysqldump)로 복구하는 표준 흐름

가장 흔한 복구 시나리오입니다. 핵심은 “새 인스턴스에 깔끔히 넣고 검증한 뒤 전환” 또는 “기존 인스턴스에 넣되 충돌을 통제”입니다.

  • 권장: 가능하면 빈 데이터 디렉터리(초기화된 인스턴스)에 import
  • charset/collation: dump 생성 당시 설정과 서버 설정 불일치 여부 확인(깨짐 방지)
  • DEFINER/SQL SECURITY: 뷰/프로시저가 있다면 사용자/권한이 먼저 준비돼야 함
  • foreign key: 대용량 import 시 FK 제약으로 시간이 급증할 수 있어 계획 필요

운영 전환 방식으로는 (1) 동일 서버 내에서 새로운 datadir로 준비 후 교체, (2) 별도 서버에 복원 후 DNS/Proxy로 전환, (3) 복제 토폴로지에서 새 primary 승격 등이 있습니다. 어떤 방식이든 검증(다음 섹션)을 통과한 뒤 트래픽을 붙이세요.

5) 복구 절차 B: physical backup(mariabackup 등)로 복구할 때 체크할 것

physical restore는 빠르지만, 단계(prepare → copy-back → 권한/소유권 정리)가 빠지면 바로 실패합니다. 도구/버전에 따라 옵션이 다르니, 본인이 가진 백업이 어떤 도구로 생성됐는지부터 확인하세요.

  • prepare 단계: apply-log(redo 적용)가 선행돼야 일관성이 맞음
  • copy-back 후 권한: datadir 소유자/퍼미션이 mysql:mysql 로 맞는지 확인
  • my.cnf 일치: innodb_page_size, innodb_file_per_table, datadir, socket 등 핵심 설정 불일치 점검
  • 버전 호환성: MariaDB major 버전이 다르면 restore 자체가 위험(테스트 필수)

복구 후 첫 기동에서 에러가 나면, 무작정 재시작 반복보다 error log를 먼저 보고 원인을 좁히는 게 빠릅니다(예: InnoDB redo/undo 불일치, 권한 문제, 파일 누락).

Step pipeline for backup prepare restore and verification

6) 복구 후 검증(필수): 데이터·권한·replication/GTID·애플리케이션 관점 점검

“mysqld가 켜졌다”는 복구 완료가 아닙니다. 아래는 운영에서 실제로 문제를 막아주는 최소 검증 항목입니다.

  • 데이터 기본 검증: 주요 테이블 row count, 최신 데이터 타임스탬프 범위, 핵심 지표 합계(예: 주문 합계)
  • 스키마/인덱스: 주요 인덱스 누락 여부(느려짐 방지), 뷰/프로시저 생성 성공 여부
  • 사용자/권한: mysql.user 및 GRANT가 기대대로인지, 앱 계정 로그인 되는지
  • charset/collation: 깨진 문자열 샘플링(특히 utf8mb4 관련)
  • replication: replica라면 SQL_THREAD/IO_THREAD 상태, GTID 사용 시 위치가 올바른지
  • binlog: point-in-time recovery를 했는지/할 예정인지에 따라 binlog 보존 정책 확인
  • 애플리케이션 리드니스: 읽기/쓰기 주요 API를 최소 1회씩 실제 호출로 검증

추가로, 복구 직후에는 트래픽을 한 번에 붙이기보다 점진적으로 늘리고(예: 배치/백그라운드 작업은 마지막에), 모니터링(Connections, InnoDB buffer pool, Disk IO, Slow log)을 1~2시간이라도 집중 관찰하는 편이 안전합니다.

마무리

Debian에서 MariaDB 복구는 “백업 파일을 넣는 작업”이 아니라, 검증과 안전장치가 포함된 운영 절차에 가깝습니다. 특히 원본 보존(스냅샷/사본)과 복구 후 검증(권한·GTID·앱 관점)을 넣으면, 복구 성공률이 눈에 띄게 올라갑니다.

다음 장애를 줄이려면, 오늘 정리한 체크리스트를 그대로 ‘복구 리허설(테스트 복원)’로 한 번 실행해보는 걸 권장합니다.