데이터 손상 복구

데이터 손상(블록/페이지 체크섬 오류, 읽을 수 없는 테이블, 손상된 RDB/AOF)에 대한 단계별 의사결정 트리: 먼저 손상 범위를 확인한 뒤 블록 수준 복구, 백업에서의 전체 복구/PITR, 최후 수단인 복구 도구 중 올바르게 선택한다.

손상 범위는 어느 정도인가?

먼저 무결성 검사를 실행해 손상이 어디까지 퍼졌는지 파악한다. 일부 블록/페이지만 손상되었는가, 단일 객체(테이블/인덱스)가 영향을 받았는가, 아니면 손상이 광범위한가? 아래 명령으로 스캔해 범위를 파악한 뒤 적절한 분기를 선택한다.

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;  -- then: SELECT file#, block#, blocks, corruption_type FROM v$database_block_corruption;

• 일부 블록 / 페이지만 손상됨
• 단일 객체(테이블/인덱스)가 영향을 받음
• 손상이 광범위함 / 다수 객체
• 검사 도구가 동작하지 않고 DB가 열리지 않음
• 손상이 반복됨(근본 원인 의심)

근본 원인: 제한적인 블록/페이지 손상 → 대상 복구

일부 블록/페이지만 손상되었다면 데이터베이스 전체를 복구할 필요가 없다. 엔진의 블록/페이지 수준 복구 기능으로 손상된 부분만 백업/로그에서 복구해 데이터 손실을 최소화한다.

근본 원인: 객체 수준/광범위한 손상 → 백업에서 전체 복구 또는 PITR

손상이 하나 이상의 객체로 퍼졌다면 가장 안전한 방법은 정상 백업에서 복구하고 가능하면 손상 시점까지 롤포워드(PITR)하는 것이다. 이렇게 하면 복구 도구로 인한 데이터 손실을 피할 수 있다.

백업이 없음 / DB가 열리지 않음 — 최후 수단으로 넘어갈 것인가?

복구 도구(REPAIR_ALLOW_DATA_LOSS, innodb_force_recovery, --fix)는 데이터 손실을 유발할 수 있으며 무결성 제약 조건을 깨뜨릴 수 있다. 사용 가능한 백업이 없고 데이터베이스를 열 수 없을 때만 쓰는 최후 수단이다. 먼저 사용 가능한 백업이 정말 없는지 확인한다.

• 정상 백업을 찾음 — 복원 진행
• 백업이 전혀 없다, 복구 도구가 유일한 방법이다

최후 수단: 데이터 손실 위험이 있는 복구 도구

이 도구들은 손상된 행/페이지를 폐기해 데이터베이스를 열 수 있게 만든다. 백업이 없고 기존 파일의 사본을 먼저 확보한 경우에만 사용한다. 목표: 데이터를 내보낼 수 있을 정도로만 연 뒤 깨끗한 사본으로 옮기는 것.

근본 원인: 하드웨어/인프라 → 원인을 해결하고 체크섬을 활성화

손상이 반복된다면 실제 원인은 디스크, 컨트롤러, 메모리(RAM) 또는 불안정한 스토리지 계층일 가능성이 높다. 데이터 복구만으로는 충분하지 않으며, 원인을 해결하지 않으면 손상이 재발한다. 조기 탐지를 위해 체크섬/무결성 검증도 활성화한다.