DBA 실무/Oracle(오라클)

[오라클 운영] RMAN 백업과 복구 완벽 가이드 - 운영 환경 표준 패턴부터 5가지 복구 시나리오까지

isony 2026. 7. 1. 06:59

[오라클 운영] RMAN 백업과 복구 완벽 가이드 - 운영 환경 표준 패턴부터 5가지 복구 시나리오까지

테스트 환경: Oracle 19c / 21c, Oracle Linux 8

DBA가 가장 두려워하는 순간이 있습니다. "DB가 안 올라옵니다." 운영팀에서 새벽 4시에 전화가 옵니다. 데이터 손상, 디스크 장애, 컨트롤 파일 손실. 이때 DBA의 진짜 실력은 평소 백업이 얼마나 잘 되어 있느냐로 결정됩니다.

오라클은 RMAN(Recovery Manager)이라는 표준 백업 도구를 제공합니다. 그런데 한국어 자료는 대부분 "RMAN으로 백업하는 법" 까지만 다루고, "운영 환경에서 어떻게 표준화하고 어떻게 복구하는가" 는 산발적입니다.

이 글에서는 다음을 종합 정리했습니다.

RMAN의 본질과 다른 백업과의 차이
운영 환경 표준 백업 전략 (Level 0 + Level 1)
자동화 가능한 실전 스크립트
★ 5가지 복구 시나리오 (전체, 시점, 테이블스페이스, 컨트롤 파일, PDB)
자주 발생하는 함정과 트러블슈팅

장애 대응 중이라면 긴급 복구 시나리오부터 보세요. 본 글은 CDB/PDB 운영 가이드의 보완편 성격도 갖습니다.

RMAN이란 무엇인가

RMAN은 오라클이 제공하는 데이터베이스 전용 백업/복구 도구입니다. OS 레벨 파일 복사와는 본질적으로 다릅니다.

OS 백업 vs RMAN 백업

항목 OS 백업 (cp, tar) RMAN 백업

백업 방식	파일 통째 복사	블록 단위 인식
핫 백업	ALTER TABLESPACE BEGIN BACKUP 필요	별도 작업 불필요
증분 백업	❌ 불가	✅ 가능 (변경 블록만)
손상 감지	❌ 불가	✅ 자동 (block checksum)
압축	OS 도구 필요	✅ 내장
복구 자동화	수동	✅ 자동 (Archive Log 적용)
운영 표준	비권장	권장

운영 환경에서는 RMAN이 사실상 유일한 표준입니다. OS 백업은 RMAN 백업의 보조 수단으로만 사용하세요.

RMAN의 핵심 객체 3가지

객체 역할

백업 셋(Backup Set)	RMAN 전용 형식의 백업 파일 (압축, 효율적)
이미지 카피(Image Copy)	데이터파일 1:1 복사본 (OS 파일과 동일 형식)
컨트롤 파일 자동 백업	데이터베이스 메타데이터 (필수)

대부분의 운영 환경에서는 백업 셋 + 컨트롤 파일 자동 백업 조합을 표준으로 사용합니다.

★ 첫 RMAN 설정 - 운영 표준 CONFIGURE

RMAN의 강력함은 CONFIGURE 명령으로 영구 설정할 수 있다는 점입니다. 한 번 설정하면 매번 다시 지정할 필요가 없습니다.

권장 표준 설정

# RMAN 접속
rman target /

# 1) 컨트롤 파일 자동 백업 ★ 필수
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

# 2) 보존 정책 - 7일 복구 윈도우
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

# 3) 백업 셋 자동 압축
RMAN> CONFIGURE COMPRESSION ALGORITHM 'MEDIUM';

# 4) 백업 옵션 - 압축 백업 셋 기본
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED BACKUPSET;

# 5) 백업 위치 - FRA 또는 별도 디스크
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/rman/%U';

# 6) 손상 블록 처리
RMAN> CONFIGURE MAXSETSIZE TO UNLIMITED;

현재 설정 확인

RMAN> SHOW ALL;

이 표준 설정만 해두면 백업 명령이 단순해집니다.

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

위 한 줄이 압축 + 병렬 + 자동 컨트롤 파일 백업 + 위치 지정까지 모두 포함합니다.

★ 운영 표준 백업 전략 - Level 0 + Level 1

운영 환경에서 가장 검증된 패턴입니다.

백업 일정 표준

일요일 새벽 2시:  Level 0 (전체 백업, 약 1~3시간)
월~토 새벽 2시:   Level 1 (증분 백업, 약 10~30분)
매시간:            ARCHIVELOG 백업

Level 0 - 일요일 전체 백업 스크립트

#!/bin/bash
# /home/oracle/scripts/rman_level0.sh

export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
export ORACLE_SID=PRODDB
export PATH=$ORACLE_HOME/bin:$PATH

LOG=/var/log/rman/level0_$(date +%Y%m%d).log

rman target / log=$LOG << EOF
RUN {
    CROSSCHECK BACKUP;
    CROSSCHECK ARCHIVELOG ALL;
    
    BACKUP AS COMPRESSED BACKUPSET 
        INCREMENTAL LEVEL 0 
        DATABASE 
        TAG 'WEEKLY_L0';
    
    BACKUP ARCHIVELOG ALL 
        DELETE INPUT 
        TAG 'WEEKLY_L0_ARC';
    
    DELETE NOPROMPT OBSOLETE;
    DELETE NOPROMPT EXPIRED BACKUP;
}
EXIT;
EOF

Level 1 - 평일 증분 백업 스크립트

#!/bin/bash
# /home/oracle/scripts/rman_level1.sh

export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
export ORACLE_SID=PRODDB
export PATH=$ORACLE_HOME/bin:$PATH

LOG=/var/log/rman/level1_$(date +%Y%m%d).log

rman target / log=$LOG << EOF
RUN {
    CROSSCHECK BACKUP;
    
    BACKUP AS COMPRESSED BACKUPSET 
        INCREMENTAL LEVEL 1 
        DATABASE 
        TAG 'DAILY_L1';
    
    BACKUP ARCHIVELOG ALL 
        DELETE INPUT 
        TAG 'DAILY_L1_ARC';
    
    DELETE NOPROMPT OBSOLETE;
}
EXIT;
EOF

cron 등록

# crontab -e (oracle 사용자)
0 2 * * 0   /home/oracle/scripts/rman_level0.sh > /var/log/rman/level0.log 2>&1
0 2 * * 1-6 /home/oracle/scripts/rman_level1.sh > /var/log/rman/level1.log 2>&1
0 * * * *   /home/oracle/scripts/rman_arclog.sh > /var/log/rman/arclog.log 2>&1

Differential vs Cumulative Level 1 - 어떤 걸 쓸까

Level 1 증분 백업은 두 가지 방식이 있고, 트레이드오프가 명확합니다.

항목 DIFFERENTIAL (기본) CUMULATIVE

대상	가장 최근 Level 0 또는 Level 1 이후 변경분	가장 최근 Level 0 이후 변경분
백업 크기	작음	점진적 증가
복구 시 적용	모든 Level 1 차례로	마지막 Level 1 하나만
복구 속도	느림	빠름
운영 권장	백업 시간 최적화 시	복구 시간 최적화 시

명령어 차이

# Differential (기본값)
BACKUP INCREMENTAL LEVEL 1 DATABASE;

# Cumulative (명시)
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

선택 가이드

OLTP 운영 (24/7 가용성 중시) → CUMULATIVE

복구 시간 단축이 가장 중요
백업 디스크는 충분히 확보

대용량 DW (백업 윈도우 짧음) → DIFFERENTIAL

백업 시간이 더 중요
복구는 자주 발생하지 않음

Block Change Tracking 활성화 (필수)

Level 1 백업 속도를 5~10배 향상시키는 옵션입니다. 운영 환경이라면 무조건 켜세요.

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
     USING FILE '/u01/oradata/bct/bct.log' REUSE;

-- 활성화 확인
SELECT * FROM v$block_change_tracking;

BCT는 변경된 블록을 비트맵으로 추적해서 Level 1 백업 시 전체 데이터파일을 스캔할 필요가 없게 합니다.

Retention Policy - Recovery Window vs Redundancy

RMAN은 어떤 백업을 "필요 없는 백업(obsolete)"으로 판단할지 두 가지 방식을 지원합니다.

방식 의미 시나리오

RECOVERY WINDOW	시점 기반: "N일 전까지 복구 가능하도록 보존"	PITR이 중요한 운영 환경 (권장)
REDUNDANCY	개수 기반: "최근 N개 백업 보존"	하드웨어 다중성만 중요한 환경

설정 예시

# 7일 복구 윈도우 (권장)
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

# 또는 3개 백업 보존
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

# 또는 정책 비활성 (모든 백업 보존, 권장하지 않음)
RMAN> CONFIGURE RETENTION POLICY TO NONE;

OBSOLETE vs EXPIRED - 헷갈리지 말 것 ★

상태 의미 발견 방법

OBSOLETE	정책상 불필요 (파일은 존재)	REPORT OBSOLETE
EXPIRED	파일이 실제로 없음 (RMAN 카탈로그에는 등록)	CROSSCHECK BACKUP 후 발견

# 불필요 백업 식별
RMAN> REPORT OBSOLETE;

# 불필요 백업 삭제
RMAN> DELETE NOPROMPT OBSOLETE;

# 카탈로그와 실제 파일 동기화
RMAN> CROSSCHECK BACKUP;

# 카탈로그에 있는데 실제 파일 없는 것 정리
RMAN> DELETE NOPROMPT EXPIRED BACKUP;

운영 스크립트에는 두 정리 명령을 모두 포함시키세요.

19c 환경 주의사항: Oracle 19c 2023.01 CPU 이후 일부 환경에서 retention policy 동작이 미묘하게 변경되었습니다. 패치 적용 후엔 반드시 REPORT OBSOLETE로 동작을 확인하세요.

★ 5가지 복구 시나리오

장애 발생 시 가장 중요한 부분입니다. 시나리오별 정확한 절차를 정리했습니다.

시나리오 1: 전체 데이터베이스 복구 (Complete Recovery)

DB 전체가 손상되어 모든 데이터파일 복구가 필요한 경우입니다.

# 1) DB를 MOUNT 상태로
sqlplus / as sysdba
SQL> STARTUP MOUNT;

# 2) RMAN 접속해서 복구
rman target /

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;

# 3) DB OPEN
SQL> ALTER DATABASE OPEN;

3개 명령으로 전체 복구가 완료됩니다. 이게 RMAN의 진짜 위력입니다.

시나리오 2: 특정 시점 복구 (PITR - Point-In-Time Recovery)

"어제 오후 3시 상태로 되돌려 주세요" 같은 경우입니다. 운영 사고 대응에 필수입니다.

sqlplus / as sysdba
SQL> STARTUP MOUNT;
SQL> EXIT;

rman target /

RMAN> RUN {
    SET UNTIL TIME "TO_DATE('2026-05-28 15:00:00', 'YYYY-MM-DD HH24:MI:SS')";
    RESTORE DATABASE;
    RECOVER DATABASE;
}

# OPEN RESETLOGS (PITR 후 필수)
SQL> ALTER DATABASE OPEN RESETLOGS;

중요: PITR 후엔 반드시 즉시 새 Level 0 백업을 받으세요. RESETLOGS 이후엔 이전 백업으로 복구할 수 없습니다.

시나리오 3: 단일 테이블스페이스 복구

특정 테이블스페이스만 손상된 경우, 전체 DB를 멈추지 않고 복구 가능합니다.

# 1) 테이블스페이스 오프라인
sqlplus / as sysdba
SQL> ALTER TABLESPACE users OFFLINE IMMEDIATE;

# 2) RMAN으로 해당 테이블스페이스만 복구
rman target /

RMAN> RESTORE TABLESPACE users;
RMAN> RECOVER TABLESPACE users;

# 3) 다시 온라인
SQL> ALTER TABLESPACE users ONLINE;

다른 사용자는 정상 서비스를 받으면서 특정 테이블스페이스만 복구할 수 있다는 게 RMAN의 큰 장점입니다.

시나리오 4: 컨트롤 파일 손실 복구

가장 까다로운 시나리오입니다. 컨트롤 파일 자동 백업 설정이 이때 빛을 발합니다.

# 1) DB 중지
sqlplus / as sysdba
SQL> SHUTDOWN ABORT;

# 2) NOMOUNT 상태로 시작
SQL> STARTUP NOMOUNT;

# 3) RMAN으로 컨트롤 파일 복구
rman target /

# 자동 백업에서 가장 최근 컨트롤 파일 복구
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

# 4) MOUNT
SQL> ALTER DATABASE MOUNT;

# 5) 데이터베이스 복구
RMAN> RECOVER DATABASE;

# 6) RESETLOGS로 OPEN
SQL> ALTER DATABASE OPEN RESETLOGS;

CONFIGURE CONTROLFILE AUTOBACKUP ON을 안 해뒀다면 이 시나리오에서 복구가 매우 어려워집니다. 반드시 켜두세요.

★ 시나리오 5: PDB 단위 복구 (12c+)

CDB/PDB 운영 가이드에서 다룬 멀티테넌트 환경의 특수 시나리오입니다.

# 1) 특정 PDB만 CLOSE
sqlplus / as sysdba
SQL> ALTER PLUGGABLE DATABASE testpdb CLOSE IMMEDIATE;

# 2) RMAN으로 PDB만 복구
rman target /

RMAN> RESTORE PLUGGABLE DATABASE testpdb;
RMAN> RECOVER PLUGGABLE DATABASE testpdb;

# 3) PDB OPEN
SQL> ALTER PLUGGABLE DATABASE testpdb OPEN;

다른 PDB는 정상 가동하면서 한 PDB만 복구합니다. 이게 멀티테넌트 환경의 강력함입니다.

PDB 단위 백업 (위와 짝)

RMAN> BACKUP PLUGGABLE DATABASE prodpdb;
RMAN> BACKUP PLUGGABLE DATABASE prodpdb, testpdb;

PDB 단위 백업/복구 정책을 분리해 두면 운영 유연성이 크게 올라갑니다.

백업 검증 - 정기 확인 필수 ★

"백업이 있다"와 "백업이 복구 가능하다"는 다릅니다. 백업 검증은 백업만큼 중요합니다.

정기 검증 명령

# 백업 파일 존재 여부 확인
RMAN> CROSSCHECK BACKUP;

# 가장 강력한 검증: 가상 복구 시뮬레이션
RMAN> RESTORE DATABASE VALIDATE;

# 특정 백업 검증
RMAN> VALIDATE BACKUPSET 12345;

# 데이터파일 손상 블록 검사
RMAN> VALIDATE DATABASE;

권장 검증 일정

빈도 명령 목적

일일	CROSSCHECK BACKUP	파일 존재 확인
주간	RESTORE DATABASE VALIDATE	복구 가능 검증
월간	별도 서버에 실제 복구 테스트	진짜 확신

월간 실제 복구 테스트가 운영 환경의 진짜 안전장치입니다. 시뮬레이션과 실제는 다르고, 테스트를 안 하면 정말 필요한 순간에 못 합니다.

백업 상태 확인 쿼리

-- 최근 백업 이력
SELECT session_recid, input_type, status,
       TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI') AS start_at,
       elapsed_seconds / 60 AS elapsed_min,
       ROUND(input_bytes/1024/1024/1024, 2) AS input_gb,
       ROUND(output_bytes/1024/1024/1024, 2) AS output_gb
FROM   v$rman_backup_job_details
WHERE  start_time > SYSDATE - 7
ORDER  BY start_time DESC;

-- 마지막 성공 백업 시각
SELECT input_type,
       MAX(end_time) AS last_success
FROM   v$rman_backup_job_details
WHERE  status = 'COMPLETED'
GROUP  BY input_type;

운영 모니터링 대시보드에 두 쿼리를 자동 표시하면 백업 상태를 한눈에 파악할 수 있습니다.

자주 발생하는 트러블슈팅 5가지

함정 1: ORA-19809 - FRA 공간 부족

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim NN bytes disk space from MM limit

원인: Fast Recovery Area(FRA)에 백업/archive log가 가득 참.

해결:

-- 현재 사용량 확인
SELECT * FROM v$recovery_area_usage;

-- FRA 크기 확장
ALTER SYSTEM SET db_recovery_file_dest_size = 100G SCOPE=BOTH;

-- 또는 정리
RMAN> DELETE NOPROMPT OBSOLETE;
RMAN> DELETE NOPROMPT EXPIRED BACKUP;

함정 2: archive log 디스크 가득참 → DB 멈춤

archive log 백업과 정리가 안 되면 archive 디스크가 가득 차서 모든 트랜잭션이 중단됩니다.

# 응급: archive 백업 후 삭제
RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;

# 절대 금지: rm으로 archive 직접 삭제
# → RMAN 카탈로그 불일치 발생

리눅스 디스크 부족 가이드에서 다룬 케이스와 직접 연결됩니다.

함정 3: 컨트롤 파일 자동 백업 비활성화

CONFIGURE CONTROLFILE AUTOBACKUP OFF로 되어 있으면 컨트롤 파일 손실 시 복구 매우 어려워집니다. 반드시 ON.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

함정 4: BCT 미설정 → Level 1 백업 느림

Block Change Tracking이 꺼져 있으면 Level 1 백업이 전체 데이터파일을 스캔합니다. 백업 시간이 5~10배 더 걸립니다.

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/u01/oradata/bct/bct.log' REUSE;

함정 5: 백업 검증을 한 번도 안 함

진짜 사고는 "백업이 있다고 믿었는데 실제로는 복구 불가"인 경우입니다. 월 1회 별도 서버에 실제 복구 테스트를 표준에 포함시키세요.

운영 환경 권장 표준

최소 표준 체크리스트

[ ] CONFIGURE CONTROLFILE AUTOBACKUP ON
[ ] CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS
[ ] 일요일 Level 0 + 평일 Level 1 + 매시간 archivelog
[ ] Block Change Tracking 활성화
[ ] FRA 사용량 모니터링 (80% 임계값)
[ ] 백업 성공 알림 자동화
[ ] 주간 RESTORE DATABASE VALIDATE 실행
[ ] 월간 별도 서버에 실제 복구 테스트 ★

백업 모니터링 알림 스크립트

#!/bin/bash
# /home/oracle/scripts/backup_monitor.sh
# 24시간 이내에 백업이 없으면 알림

sqlplus -s / as sysdba << EOF
WHENEVER SQLERROR EXIT 1
SET HEADING OFF FEEDBACK OFF
SELECT CASE 
    WHEN MAX(end_time) < SYSDATE - 1 THEN 'ALERT'
    ELSE 'OK'
END FROM v$rman_backup_job_details WHERE status = 'COMPLETED';
EXIT;
EOF

if [ $? -ne 0 ]; then
    echo "Backup failed in last 24h" | mail -s "DB Backup Alert: $(hostname)" dba@company.com
fi

마무리

RMAN은 강력하지만 표준화되지 않은 RMAN은 사고의 원인이 됩니다. 핵심을 다시 정리하면:

CONFIGURE로 영구 표준 설정 — 매번 명령 입력 금지
일요일 Level 0 + 평일 Level 1 + 매시간 archivelog — 검증된 표준 패턴
Block Change Tracking 필수 — Level 1 백업 5~10배 빠름
검증은 백업만큼 중요 — 정기 VALIDATE + 월간 실제 복구 테스트
PDB 환경은 PDB 단위 백업 분리 — 유연성 극대화

운영 환경에서 RMAN 표준을 정착시키는 가장 좋은 방법은 이번 글의 스크립트와 체크리스트를 그대로 사내 표준으로 채택하는 것입니다. 본인 환경에 맞춰 일부 경로와 임계값만 조정하면 됩니다.

이로써 본 블로그의 30일 발행 캘린더의 마지막 글이자 오라클 운영 실무 시리즈의 마무리가 완성되었습니다. 백업과 복구는 DBA가 항상 마지막에 책임지는 영역입니다. 이 글이 본인의 운영 환경 표준화에 도움이 되었으면 합니다.

비슷한 RMAN 운영 사례, 더 좋은 패턴, 또는 까다로운 복구 경험이 있다면 댓글로 공유해 주세요.

저작자표시 (새창열림)

'DBA 실무 > Oracle(오라클)' 카테고리의 다른 글

[리눅스 운영] 디스크 용량 부족 (df 100%) 해결 - 5가지 원인과 체계적 진단법 (DBA 환경 특화) (0)	2026.06.29
[오라클 에러] ORA-01555 snapshot too old - 5가지 원인과 해결방법 (UNDO 일관성 읽기 모델 완벽 정리) (0)	2026.06.24
[오라클 운영] Oracle 12c 멀티테넌트(CDB/PDB) 운영 가이드 - 상태 관리부터 Unplug/Plug까지 (0)	2026.06.22
[오라클 에러] ORA-12154 TNS:could not resolve the connect identifier - 5가지 원인과 해결방법 (접속 에러 3종 비교) (0)	2026.06.19
[오라클 운영] ROLE 기반 권한 관리 완벽 가이드 - PL/SQL의 함정과 INVOKER rights까지 (0)	2026.06.17

현재글[오라클 운영] RMAN 백업과 복구 완벽 가이드 - 운영 환경 표준 패턴부터 5가지 복구 시나리오까지

소니 스토리 (Sony Story)

Sony Story 나의 소니 스토리 (BTS 성지 탐방, 공연, 예배)

소니스토리, CGNTV, DevExpress, BTS JIN, 우리말성경, 방탄석진, BTS, 방탄, 파이썬, python, 이재훈목사, 일요예배, 방탄소년단, 석진, 달려라석진, 주일예배, 영상예배, 예배영상, run jin, 온누리교회,

Today :
Yesterday :

« 2026/07 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31