Oracle 19c RMAN RESTORE VALIDATE: 백업이 실제 복구 가능한지 확인하는 범위와 순서

Oracle 19c에서 백업이 실제로 복구 가능한지 확인하려면 RESTORE DATABASE VALIDATE를 사용합니다. RMAN이 현재 복구에 필요한 백업 조각과 이미지 복사를 고른 뒤 끝까지 읽지만, 데이터파일을 쓰지는 않습니다.

다만 이 명령의 성공은 “선택된 백업으로 파일을 복원할 수 있다”는 뜻입니다. 복구 시간 목표(RTO), 모든 아카이브 로그의 확보, 애플리케이션이 다시 정상 동작하는지까지 대신 검증하지는 않습니다. 정기 검증과 별도의 격리 복구 훈련은 구분해야 합니다.

적용 조건과 영향 범위

왜 BACKUP VALIDATE나 CROSSCHECK만으로 부족한가

CROSSCHECK는 RMAN 저장소의 기록과 디스크 헤더 또는 미디어 관리 카탈로그를 대조합니다. 파일이 보인다는 사실을 확인하는 데 알맞지만, 백업 조각 전체를 읽어 복원 경로를 검증하는 명령은 아닙니다.

VALIDATE BACKUPSET는 지정한 백업 세트를 검사합니다. 반면 RESTORE ... VALIDATE는 데이터베이스나 특정 테이블스페이스처럼 복구 대상에서 출발하고, RMAN이 그 시점에 실제로 선택할 백업을 고릅니다. 같은 객체의 오래된 사본까지 모두 건강한지를 검사하는 용도도 아닙니다.

명령 선택표

작업 전: 복구 목표와 RMAN 구성을 먼저 확인

검증 창을 잡기 전에 무엇을 되살릴지 정합니다. 전체 CDB, 한 PDB, 또는 특정 테이블스페이스는 필요한 백업과 아카이브 로그가 다릅니다. 단순히 최근 전체 백업이 있다는 이유로 원하는 시점까지 복구된다고 판단하면 안 됩니다.

RMAN> SHOW ALL;
RMAN> LIST BACKUP SUMMARY;
RMAN> LIST ARCHIVELOG ALL;

테이프나 클라우드 모듈을 쓴다면 해당 장치용 채널이 실제 복구 때도 할당되는지 확인합니다. RMAN은 할당된 채널이 읽을 수 있는 백업만 후보로 고릅니다. 디스크 백업만 보이는 환경에서 테이프 백업을 검증하면, “백업 없음”은 백업 손상보다 채널 설정 문제일 수 있습니다.

최소 재현: 테스트 DB에서 검증 범위를 좁히기

운영에서 처음 실행할 명령을 바로 전체 데이터베이스로 넓히지 말고, 동일한 RMAN 구성의 테스트 환경에서 작은 테이블스페이스부터 시간과 I/O를 관찰합니다. 아래 예제의 APP_DATA는 예시 이름입니다. 실제 테이블스페이스 이름으로 바꾸기 전에 데이터파일 수와 백업 위치를 확인합니다.

RMAN> RESTORE TABLESPACE app_data VALIDATE;

전체 복구 가능성을 확인하는 기본 명령

RMAN> RESTORE DATABASE VALIDATE;

VALIDATE 위치는 RESTORE DATABASE VALIDATE와 RESTORE VALIDATE DATABASE처럼 문법상 모두 쓸 수 있지만, 팀 표준에서는 한 형태로 고정해 운영 로그 검색을 쉽게 하는 편이 낫습니다. 실패한 조각 이름, 채널, 오류 시각을 남기고 같은 명령을 즉시 반복하지 않습니다. 일시적 네트워크 오류인지, 특정 백업 조각의 손상인지, 카탈로그 정보 불일치인지 먼저 분리합니다.

시점 복구 계획을 함께 확인하는 방법

장애 시점을 가정했다면 검증도 목표 시점을 포함해야 합니다. 다음 예제는 2026년 8월 15일 09:00:00까지 복원 가능한 백업 후보를 찾는 형태입니다. 날짜 형식과 시간대는 조직의 NLS 설정과 복구 절차에 맞춰 명확히 통일합니다.

RUN {
  SET UNTIL TIME "TO_DATE('2026-08-15 09:00:00','YYYY-MM-DD HH24:MI:SS')";
  RESTORE DATABASE VALIDATE;
}

출력에서 성공과 실패를 구분하는 기준

정상 종료라면 RMAN 출력에 선택한 백업 조각의 경로와 채널별 검증 완료 메시지가 남습니다. 이때도 어떤 사본을 선택했는지 확인해야 합니다. 디스크와 테이프에 같은 백업이 있을 때 검증이 한 사본만 읽었다면, 다른 사본의 건전성까지 확인한 것은 아닙니다. 장치별 복구 경로가 필요하면 채널과 DEVICE TYPE을 바꿔 별도로 계획합니다.

오류가 났다면 가장 앞선 RMAN 오류와 직전의 백업 조각 이름을 함께 보존합니다. ‘백업을 찾지 못함’은 보존 정책으로 조각이 삭제됐거나, 카탈로그·컨트롤파일 기록이 오래됐거나, 채널이 해당 저장소를 읽지 못한다는 뜻일 수 있습니다. ‘읽기 오류’는 미디어나 네트워크 문제와 조각 손상을 구분해야 합니다. 오류 한 줄만 보고 백업 전체를 무효로 판단하지 않습니다.

RMAN> LIST BACKUP OF DATABASE SUMMARY;
RMAN> CROSSCHECK BACKUP;
RMAN> LIST EXPIRED BACKUP;

검증 후 읽어야 할 로그와 뷰

성공 메시지만 기록하지 말고 검증에 걸린 시간, 사용 채널, 읽은 백업 위치, 실패 조각을 운영 기록에 남깁니다. 실패가 블록 손상이라면 RMAN 출력과 alert log·trace를 보존합니다. Oracle은 검증에서 발견한 블록 손상 정보를 V$DATABASE_BLOCK_CORRUPTION에 기록할 수 있으므로, 이전 기록과 구분해 조회합니다.

SELECT file#,
       block#,
       blocks,
       corruption_type
FROM   v$database_block_corruption
ORDER  BY file#, block#;

흔한 오해와 운영 순서

• 성공했으니 DR 훈련은 불필요하다: 검증은 파일을 쓰지 않습니다. 격리된 환경에서 실제 RESTORE와 RECOVER, 기동·업무 점검까지 주기적으로 연습합니다.
• 헤더만 읽으면 충분하다: VALIDATE HEADER 또는 preview는 빠른 후보 확인에 유용하지만, 전체 블록 읽기와 다릅니다.
• 실패하면 백업을 바로 삭제한다: 다른 사본·다른 장치·채널 설정을 확인하기 전에는 보존본을 제거하지 않습니다.
• 운영 부하는 없다: 출력 파일을 쓰지 않아도 백업을 끝까지 읽는 작업입니다. 일정과 자원 한도를 복구 계획에 포함합니다.

정기 RESTORE DATABASE VALIDATE는 백업 성공 로그의 빈틈을 줄이는 좋은 점검입니다. 그러나 복구 가능성은 한 명령의 성공 여부가 아니라, 목표 시점의 로그·접근 권한·암호화 키·채널·복구 시간과 격리 복구 훈련이 함께 맞을 때 확인됩니다.

공식 출처

• Oracle Database 19c RMAN RESTORE Reference
• Oracle Database 19c RMAN VALIDATE Reference
• Oracle Database 19c Performing Backup and Recovery