Physical Address
South Korea
ExaCC 백업 설계로 밤새던 날들, NetBackup RMAN 연동과 4가지 대안
“ExaCC 인프라를 구축하는데, 기존 넷백업(NetBackup)을 그대로 쓸 수 있나요?”
최근 ExaCC(Oracle Exadata Cloud at Customer)를 도입하는 프로젝트에서 DBA나 인프라 엔지니어분들에게 가장 많이 받는 질문 중 하나입니다.
ExaCC는 하드웨어만 고객사 전산실(온프레미스)에 들어와 있을 뿐, 가상화 레이어와 DB 관리는 OCI(Oracle Cloud Infrastructure) 웹 콘솔을 통해 제어되는 독특한 하이브리드 구조를 갖고 있습니다. 이렇다 보니 전통적인 인프라 환경에서 운영하던 백업 방식을 그대로 이식하려다가 설계 단계부터 혼선을 겪는 경우가 정말 많습니다.
결론부터 말씀드리면 ExaCC에서도 기존 베리타스 넷백업을 연동하여 사용할 수 있습니다. 다만 오라클의 원본 데이터 무결성을 보장해야 하므로, 모든 과정은 오라클의 백업 관리자인 RMAN(Recovery Manager)을 기반으로 수행됩니다.
오늘은 제가 실제 클라우드 전환 프로젝트 현장에서 ExaCC 백업 인프라를 구축하며 겪었던 수많은 시행착오와 성능 최적화 경험을 바탕으로, NetBackup-RMAN 연동 아키텍처의 핵심 디테일과 구체적인 구성법, 그리고 비즈니스 상황에 따라 선택할 수 있는 4가지 대안 아키텍처까지 가감 없이 공유해 드리겠습니다.
ExaCC 환경에서 NetBackup과 RMAN 연동의 핵심 원리
우선 엔지니어가 가장 먼저 머릿속에 넣어두어야 할 사실이 있습니다. 넷백업이 Exadata 내부의 데이터 파일 블록을 직접 들여다보고 복사하는 게 아니라는 점입니다. Exadata의 ASM(Automatic Storage Management) 볼륨에 저장된 데이터는 무조건 RMAN이라는 전용 관리자를 통해서만 안전하게 외부로 출력될 수 있습니다.
여기서 넷백업은 RMAN이 던져주는 데이터 스트림을 받아서 백업 전용 디스크 스토리지(Media Server)나 테이프로 밀어 넣어주는 MML(Media Management Layer) 역할을 수행합니다. 이를 위해 오라클은 외부 백업 소프트웨어와 통신할 수 있는 SBT(System Backup Tape) 인터페이스를 제공하며, 넷백업은 이 규격에 맞춘 전용 플러그인 라이브러리 파일(libobk.so)을 오라클 환경에 제공하여 연동하게 됩니다.
💡 현장 엔지니어의 실무 팁: 백업 전용 네트워크 분리는 필수입니다
실제 프로젝트 현장에서 흔히 하는 실수 중 하나는 서비스 네트워크(Client Network)를 통해 백업 데이터가 전송되도록 방치하는 것입니다. Exadata는 I/O 성능이 워낙 압도적이기 때문에, 백업이 시작되면 순간적으로 수십 Gbps의 트래픽이 터져 나옵니다. 이때 백업 트래픽이 서비스망을 타게 되면 실시간 대고객 서비스의 응답 속도가 튀는 대형 장애로 이어집니다. 따라서 반드시 ExaCC 내부의 백업 전용 네트워크 인터페이스(예: bondeth1)와 넷백업 미디어 서버 간의 전용 경로를 설계해야 밤에 발 뻗고 잘 수 있습니다. 자사에서 구성한 ExaCC 도 클라이언트망(운영망/백업망 VLAN ID 다르게 구성), 백업망, DR 망으로 구분하여 구성되어 있습니다.
넷백업 RMAN 연동을 위한 단계별 실무 구성 절차
ExaCC VM 클러스터의 각 노드(Cust VM)에서 넷백업을 통해 RMAN 백업을 수행하기 위한 구체적인 절차입니다. 실제 구축 시 아래 순서대로 차근차근 진행하시면 무리 없이 구성을 완료하실 수 있습니다.
단계 1: NetBackup Client 및 Oracle Agent 설치
ExaCC 가상머신의 각 노드에 root 권한으로 접속하여 NetBackup Client 패키지를 설치합니다. 이때 오라클 백업 인터페이스 연동을 위한 NetBackup for Oracle Agent 라이브러리가 누락 없이 포함되었는지 확인해야 합니다. 설치 후에는 마스터/미디어 서버와 ExaCC VM 간의 전용 백업 포트(vnetd, bpcd 등) 통신이 사내 방화벽에서 정상적으로 열려 있는지 네트워크 정합성 테스트를 반드시 선행해 주세요.
단계 2: SBT 라이브러리 경로 확인 및 명시
과거 온프레미스 환경에서는 $ORACLE_HOME/lib/libobk.so 파일을 넷백업 설치 경로로 심볼릭 링크 처리하는 방식을 자주 썼습니다. 하지만 ExaCC 환경에서는 오라클 패치나 버전 업데이트 시 독립성을 유지하기 위해 RMAN 스크립트 내에서 직접 라이브러리 파일 경로를 명시(Explicit Path)하는 방식을 강력히 권장합니다. 보통 64비트 환경의 라이브러리 경로는 다음과 같습니다.
/usr/openv/netbackup/bin/libobk.so64
단계 3: NetBackup 마스터 서버 정책(Policy) 정의
넷백업 관리 콘솔에서 새로운 백업 정책을 생성할 때, Policy Type은 반드시 ‘Oracle’로 선택해야 합니다. 이때 스케줄 유형은 두 가지를 모두 정의해야 정상 작동합니다.
- Automatic Backup 스케줄: 넷백업 스케줄러가 정해진 시간에 작동하여 ExaCC 내부의 쉘 스크립트를 원격 호출하는 스케줄
- Application Backup 스케줄: 오라클 내부 크론탭(Crontab)이나 스케줄러가 RMAN을 구동했을 때 백업 스트림을 받아주기 위해 대기하는 스케줄
단계 4: 프로덕션급 RMAN 백업 스크립트 작성
아래 스크립트는 실제 대용량 ExaCC 운영 환경에서 다중 채널을 할당하고, 백업 전용 네트워크 바인딩 옵션을 적용해 성능을 끌어올린 실무형 RMAN 스크립트 예시입니다. 작성 시 프로젝트의 담당 DBA분과 함께 검토하며 환경에 맞게 커스텀해야 하는것을 꼭 기억하셔야 합니다.
SQL
RUN {
# 1번 노드의 백업 전용 IP를 할당하여 채널 구동
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE'
PARMS 'SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so64, ENV=(NB_ORA_CLIENT=exacc-node1-bkup-ip, NB_ORA_SERV=nbu-master-server)';
# 2번 노드의 백업 전용 IP를 할당하여 채널 구동 (Exadata의 RAC 분산 백업 활용)
ALLOCATE CHANNEL ch02 TYPE 'SBT_TAPE'
PARMS 'SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so64, ENV=(NB_ORA_CLIENT=exacc-node2-bkup-ip, NB_ORA_SERV=nbu-master-server)';
# 데이터베이스 전체 백업(L0) 및 아카이브 로그 백업 동시 수행
BACKUP
INCREMENTAL LEVEL 0
DATABASE
FORMAT 'db_%U_%t'
PLUS ARCHIVELOG
FORMAT 'arch_%U_%t'
DELETE INPUT;
# 사용 완료된 채널 해제
RELEASE CHANNEL ch01;
RELEASE CHANNEL ch02;
}
⚠️ 트러블슈팅 경고: OCI 콘솔 자동 백업 기능과의 충돌을 주의하세요!
ExaCC 운영 중 엔지니어들이 가장 빈번하게 겪는 장애가 있습니다. 바로 OCI 콘솔에서 제공하는 ‘오브젝트 스토리지 자동 백업’과 사내 ‘넷백업 기반 수동 RMAN 백업’이 동시에 켜져 있을 때 발생합니다. 두 시스템이 서로의 존재를 모른 채 각자 아카이브 로그를 백업하고
DELETE INPUT명령으로 원본을 지워버리면, 한쪽 시스템은 필요한 아카이브 로그가 사라져 백업 본쇄(Chain Break) 현상이 일어납니다. 따라서 넷백업을 주 백업으로 사용할 계획이라면, OCI 콘솔의 아카이브 백업 주기와 데이터 보존 정책(Retention Policy)을 면밀히 조율하거나 한쪽을 정리해야 안전합니다.
NetBackup 외에 검토할 수 있는 4가지 대체 백업 아키텍처
기업의 데이터 보안 거버넌스, 보유 인프라 현황, 그리고 네트워크 환경에 따라 넷백업 외에 다른 대안을 선택하는 것이 더 유리할 수도 있습니다. 대표적인 4가지 방식을 비교해 드리겠습니다.
1. OCI 오브젝트 스토리지 백업 (클라우드 네이티브 연동)
오라클이 기본적으로 제공하며 가장 강력하게 권장하는 방식입니다. ExaCC 내부의 bkup_api 유틸리티가 OCI 가상 네트워크 인프라(FastConnect 또는 IPSec VPN)를 타고 OCI 리전의 Object Storage 버킷으로 데이터를 다이렉트 전송합니다.
- 장점: OCI 콘솔 UI에서 클릭 몇 번으로 주간/일간 백업 스케줄링과 보존 기간 설정을 완벽하게 자동화할 수 있습니다. 장애 시 특정 시점 복구(Point-in-Time Recovery)도 콘솔에서 직관적으로 제어 가능합니다.
- 단점: 페타바이트(PB) 급 대용량 데이터베이스의 경우, 온프레미스 전산실에서 클라우드 리전까지 연결된 전용선 대역폭이 병목 구간이 될 수 있습니다. 초기 전체 백업 시 상당한 네트워크 비용과 시간이 소요됩니다.
2. OCI 온프레미스 오브젝트 스토리지 백업 (Dedicated Region / PCA)
클라우드의 편리한 관리 UI는 누리고 싶지만, 금융·공공 기관처럼 법적 규제나 내부 보안 방침상 데이터를 외부 퍼블릭 클라우드에 저장할 수 없는 환경을 위한 대안입니다.
- 장점: 고객 전산실 내부에 함께 설치된 OCI Dedicated Region 인프라나 OCI PCA(Private Cloud Appliance)의 로컬 오브젝트 스토리지를 활용합니다. 데이터가 전산실 벽을 넘지 않으므로 컴플라이언스를 100% 충족하면서도 OCI 콘솔의 자동화 기능을 그대로 쓸 수 있습니다.
- 단점: 온프레미스 내부에 클라우드 스토리지 전용 인프라 자산이 먼저 대규모로 구축되어 있어야 하므로, 초기 도입 비용(CAPEX) 부담이 매우 큽니다.
3. ZDLRA (Zero Data Loss Recovery Appliance) 연동
오라클 데이터베이스 아키텍처에 완벽하게 맞춤 설계된 최상위 등급의 백업 전용 하드웨어 어플라이언스(ZDLRA)를 사내망에 두고 연동하는 방식입니다.
- 장점: 실시간 아카이브 전송(Real-time Redo Transport) 기술을 통해 변경 트랜잭션이 발생하는 즉시 ZDLRA로 복제됩니다. 스토리지 전면 장애가 발생해도 데이터 유실률을 ‘0(Zero)’에 가깝게 방어합니다. 또한 ‘영구 증분 백업(Incremental Forever)’을 지원하므로 매번 전체 백업을 받을 필요가 없어 ExaCC의 자원 소모를 극적으로 줄여줍니다.
- 단점: 하이엔드 전용 장비인 만큼 도입 및 유지보수 단가가 상상을 초월합니다. 오라클 전용 장비이기 때문에 이기종 DBMS나 일반 파일 백업용으로는 활용할 수 없다는 확장성의 한계가 있습니다.
4. 로컬 NFS / ZFS 스토리지 백업 (전통적 인프라 재활용)
고객 데이터센터 내에 이미 배치되어 있는 대용량 NAS 스토리지나 Oracle ZFS Storage Appliance를 NFS 프로토콜 기반으로 ExaCC 가상머신 OS 레이어에 직접 마운트하여 관리하는 고전적이고 확실한 방식입니다.
- 장점: 기존에 보유하고 있던 사내 유휴 스토리지 자산을 그대로 재활용하므로 추가적인 인프라 지출 비용이 발생하지 않습니다. 외부 통신이 전혀 필요 없는 완전한 폐쇄망 환경에서 가장 안정적으로 구동됩니다.
- 단점: OCI 콘솔의 스마트한 자동화 백업 제어 기능을 일절 활용할 수 없습니다. 크론탭 스케줄러 등록, 백업 파일 아카이빙 및 보존 주기 관리, 스토리지 용량 임계치 알람 스크립트 작성까지 모든 요소를 담당 DBA가 일일이 수동으로 구축하고 유지보수해야 하는 엄청난 공수가 따릅니다.
한눈에 보는 ExaCC 백업 전략 아키텍처 비교
기업의 비즈니스 도메인과 시스템의 중요도에 따라 최적의 아키텍처를 선택할 수 있도록 핵심 지표를 표로 요약했습니다.
| 백업 방식 | 데이터 저장 위치 | 관리 인터페이스 | 핵심 장점 | 주요 고려사항 |
| NetBackup (RMAN MML) | 사내 NBU 미디어 서버 | NetBackup Console + RMAN | 기존 통합 백업 체계 및 인프라 재활용 | SBT 라이브러리 연동 및 채널 최적화 필요 |
| OCI Object Storage | OCI 퍼블릭 클라우드 리전 | OCI 웹 콘솔 | 운영 편의성 극대화, 완전 관리형 | 클라우드 전용망 대역폭(FastConnect) 확보 필수 |
| OCI 온프레미스 스토리지 | 고객 데이터센터 내부 | OCI 웹 콘솔 | 보안 컴플라이언스 완벽 준수 | Dedicated Region 등 선행 인프라 투자 필요 |
| ZDLRA 어플라이언스 | 고객 데이터센터 내부 | RMAN + ZDLRA 전용 관리자 | 데이터 유실 Zero, 영구 증분 백업 | 하드웨어 도입 비용 부담 가중 |
| 로컬 NFS (ZFS 등) | 사내 NAS/ZFS 스토리지 | DBA 수동 쉘 스크립트 | 추가 인프라 비용 없음, 완전 독립 운영 | 자동화 기능 부재, 운영 공수 대폭 증가 |
마치며: 우리 시스템에는 어떤 백업이 정답일까?
ExaCC 백업 전략을 수립할 때 모든 상황에 완벽하게 들어맞는 단 하나의 정답은 존재하지 않습니다.
만약 기존에 기업 내부적으로 베리타스 넷백업을 전사 표준으로 채택하여 강력한 통합 모니터링 체계를 구축하고 있다면, 오늘 소개해 드린 RMAN SBT API 방식을 적용하는 것이 기존 운영 프로세스의 연속성 측면에서 가장 합리적입니다. 단, 앞서 강조해 드린 libobk.so64 연동과 백업 전용 네트워크 분리 설정을 꼼꼼하게 챙겨야 하겠죠.
반면, 인프라 관리 인력이 부족하고 운영 자동화를 통한 TCO(총소유비용) 절감이 최우선 과제라면 OCI 오브젝트 스토리지 기반의 클라우드 네이티브 자동 백업을 적극적으로 검토해 보시는 것을 추천합니다. 각 시스템의 목표복구시간(RTO)과 목표복구시점(RPO), 그리고 기업의 보안 가이드라인을 면밀히 분석하셔서 성공적인 ExaCC 백업 거버넌스를 구축하시길 응원합니다.
전문가의 인사이트 : 함께 읽어 보세요.
AWS ECS Anywhere 설치 및 하이브리드 VM 연동 가이드
참조 및 출처 URL:
https://docs.oracle.com/en/solutions/deploy-osb-catc/index.html
