ExaCC NetBackup RMAN 연동 및 4가지 대안

ExaCC 를 DB 서버로 사용하는 프로젝트에서 DBA 로 부터 항상 문의 받는 내용 중 하나는 데이터 백업을 어떻게 구성 해야 하는가? 하는 질문을 많이 받습니다. IDC 백업 운영 환경에 따라 다르겠지만 자사의 경우는 데이터 백업을 넷백업 소프트웨어로 구성합니다. ExaCC 는 오라클에서 제공하는 RMAN 소프웨어와 넷백업 솔루션을 사용하여 데이터 백업을 일반적으로 구성합니다. 이 방법 이외에 데이터 백업을 구성하는 몇 가지 방법에 대해서 정리해 보겠습니다.

Oracle Exadata Cloud at Customer(이하 ExaCC)는 온프레미스의 강력한 보안 통제권과 퍼블릭 클라우드의 유연한 관리 편의성을 동시에 제공하는 혁신적인 하이브리드 클라우드 플랫폼입니다. 그러나 하드웨어만 고객 데이터센터에 존재할 뿐 가상화 레이어와 데이터베이스 관리는 Oracle Cloud Infrastructure(OCI) 콘솔을 통해 제어된다는 독특한 아키텍처 때문에, 전통적인 인프라 환경에서 운영하던 백업 방식을 그대로 이식하려 할 때 많은 엔지니어들이 설계상의 혼선을 겪게 됩니다.

가장 많이 인입되는 질문 중 하나는 “ExaCC 환경에서도 기존 온프레미스 장비처럼 베리타스 넷백업(Veritas NetBackup)을 쓸 수 있는지, 그리고 이때 오라클 RMAN(Recovery Manager)을 반드시 통과해야 하는지”에 대한 여부입니다. 결론부터 말씀드리면, 네, 맞습니다. ExaCC에서도 넷백업을 연동할 수 있으며, 이 모든 과정은 오라클의 원본 데이터 무결성을 보장하기 위해 RMAN을 기반으로 수행됩니다.

오늘 작성한 글에서는 실제 클라우드 전환 프로젝트 현장에서 ExaCC 백업 인프라를 구축하며 겪었던 시행착오와 성능 최적화 경험을 바탕으로, NetBackup-RMAN 연동 아키텍처의 디테일과 이를 구현하기 위한 구체적인 구성법, 그리고 비즈니스 요구사항에 따라 선택할 수 있는 4가지 대체 백업 아키텍처를 상세하게 기술합니다.

1. ExaCC 환경에서 NetBackup과 RMAN 연동 아키텍처의 본질

엔지니어들이 가장 먼저 이해해야 할 핵심은 NetBackup이 Exadata 내부의 데이터 파일 블록을 직접 들여다보고 복사하는 것이 아니라는 점입니다. 오라클 데이터베이스, 특히 Exadata의 ASM(Automatic Storage Management) 볼륨에 저장된 데이터는 무조건 RMAN이라는 전용 관리자를 통해서만 안전하게 외부로 전달될 수 있습니다.

여기서 NetBackup은 RMAN이 던져주는 데이터 스트림을 받아서 테이프나 백업 전용 디스크 스토리지(Media Server)로 안전하게 밀어 넣어주는 Media Management Layer(MML) 역할을 수행합니다. 이를 위해 오라클은 외부 백업 소프트웨어와 통신할 수 있는 SBT(System Backup Tape) API 인터페이스를 제공하며, NetBackup은 이 인터페이스 규격에 맞춰 제작된 전용 공유 라이브러리(플러그인 파일인 libobk.so)를 오라클 환경에 제공하게 됩니다.

💡 실무 엔지니어의 한마디: 네트워크 분리의 중요성

실제 프로젝트 현장에서 흔히 하는 실수 중 하나는 서비스 네트워크(Client Network)를 통해 백업 데이터를 전송하도록 방치하는 것입니다. Exadata는 엄청난 I/O 성능을 자랑하므로 백업 시작 시 수십 Gbps의 트래픽이 순간적으로 터져 나옵니다. 이때 백업 트래픽이 서비스망을 타게 되면 실시간 대고객 서비스의 응답 속도가 급격히 떨어지는 장애로 이어집니다. 반드시 ExaCC 내부의 백업 전용 네트워크 인터페이스(예: bondeth1)와 넷백업 미디어 서버 간의 전용 경로를 설계해야 합니다.

2. NetBackup 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 파일을 넷백업 설치 경로로 심볼릭 링크 처리하는 방식을 많이 썼으나, OCI 및 ExaCC 환경에서는 오라클 패치나 버전에 따른 독립성을 유지하기 위해 RMAN 스크립트 내에서 직접 라이브러리 파일 경로 명시(Explicit Path) 방식을 권장합니다. 보통 64비트 환경의 라이브러리 경로는 다음과 같이 지정됩니다.

• /usr/openv/netbackup/bin/libobk.so64

단계 3: NetBackup 마스터 서버 정책(Policy) 정의

넷백업 관리 콘솔에서 새로운 백업 정책을 생성할 때, 반드시 Policy Type을 ‘Oracle’로 선택해야 합니다. 스케줄 유형은 두 가지로 나뉩니다. NetBackup 스케줄러가 정해진 시간에 작동하여 ExaCC 내부의 쉘 스크립트를 원격 호출하는 Automatic Backup 스케줄과, 오라클 내부의 crontab이나 스케줄러가 RMAN을 구동했을 때 백업 스트림을 받아주기 위해 대기하는 Application Backup 스케줄이 있습니다. 두 가지 스케줄이 정책 내에 모두 정의되어 있어야 정상 작동합니다.

단계 4: 프로덕션급 RMAN 백업 스크립트 작성

아래 스크립트는 실제 대용량 ExaCC 운영 환경에서 다중 채널을 할당하고 백업 전용 네트워크 바인딩 옵션을 적용해 성능을 극대화한 실무형 RMAN 스크립트 예시입니다. 아래 스크립트를 활용하여 DBA 와 같이 검토하여 스크립트 작성이 필요합니다. 꼭 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)';
    
    # 데이터베이스 전체 백업 및 아카이브 로그 백업 동시 수행
    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 콘솔을 통한 ‘오브젝트 스토리지 자동 백업’과 사내 ‘NetBackup 기반 수동 RMAN 백업’이 동시에 활성화되어 있을 때 발생합니다. 두 시스템이 서로의 존재를 모른 채 각자 아카이브 로그를 백업하고 DELETE INPUT 명령으로 지워버리면, 한쪽 시스템은 필요한 아카이브 로그가 사라져 백업 본쇄(Chain Break) 현상이 일어납니다. 따라서 넷백업을 주 백업으로 쓸 경우, OCI 콘솔의 아카이브 백업 주기와 상호 보존 정책(Retention Policy)을 면밀히 조율해야 합니다.

3. NetBackup 외 ExaCC에서 활용 가능한 4가지 데이터 백업 아키텍처

기업의 데이터 보안 거버넌스, 보유 인프라 현황, 네트워크 인프라 환경에 따라 NetBackup 외에도 다양한 대안을 검토할 수 있습니다. 각 방식의 메커니즘과 장단점을 비교해 보겠습니다.

① OCI 오브젝트 스토리지 백업 (OCI 퍼블릭 클라우드 연동)

오라클이 기본적으로 제공하며 가장 강력하게 권장하는 클라우드 네이티브 백업 방식입니다. ExaCC 내부의 bkup_api 유틸리티가 OCI 가상 네트워크 인프라(FastConnect 또는 IPSec VPN)를 타고 OCI 리전의 Object Storage 버킷으로 데이터를 다이렉트 전송합니다.

• 장점: OCI 콘솔 UI에서 마우스 클릭 몇 번으로 주간/일간 백업 스케줄링, 데이터 보존 기간 설정을 완벽하게 자동화할 수 있습니다. 장애 발생 시 특정 시점 복구(Point-in-Time Recovery)도 콘솔에서 직관적으로 제어 가능합니다.
• 단점: 테라바이트(TB) 단위를 넘어 페타바이트(PB) 급 대용량 데이터베이스의 경우 온프레미스 전산실에서 클라우드 리전까지 연결된 전용선 대역폭이 병목 구간이 될 수 있어, 초기 전체 백업 시 상당한 네트워크 비용과 시간이 소요될 수 있습니다.

② OCI 온프레미스 오브젝트 스토리지 백업 (Dedicated Region / PCA)

클라우드의 관리 편의성은 누리고 싶지만, 법적 규제나 내부 보안 방침상 금융·공공 데이터의 관외 반출(퍼블릭 클라우드 저장)이 엄격히 금지된 환경을 위한 솔루션입니다.

• 장점: 고객의 물리적 전산실 내부에 함께 설치된 OCI Dedicated Region 인프라나 OCI Private Cloud Appliance(PCA)의 로컬 오브젝트 스토리지를 활용합니다. 데이터가 전산실 벽을 넘지 않으므로 컴플라이언스 요건을 100% 충족하면서도 OCI 콘솔의 자동화 백업 UI를 그대로 쓸 수 있습니다.
• 단점: 온프레미스 내부에 클라우드 스토리지 전용 인프라 자산이 먼저 대규모로 구축되어 있어야 하므로, 초기 인프라 도입 비용(CAPEX) 부담이 큽니다.

③ ZDLRA (Zero Data Loss Recovery Appliance) 연동

오라클 데이터베이스 아키텍처에 완벽하게 맞춤 설계된 최상위 등급의 백업 전용 하드웨어 어플라이언스(ZDLRA)를 사내망에 두고 연동하는 방식입니다.

• 장점: 실시간 아카이브 전송(Real-time Redo Transport) 기술을 통해 변경 트랜잭션이 발생하는 즉시 ZDLRA로 복제되므로, 예기치 못한 스토리지 전면 장애 시에도 데이터 유실율을 ‘0(Zero)’에 가깝게 방어할 수 있습니다. 또한 영구 증분 백업(Incremental Forever) 아키텍처를 지원하여 매번 전체 백업을 받을 필요가 없으므로 ExaCC의 CPU 및 네트워크 자원 소모를 극적으로 줄여줍니다.
• 단점: 하이엔드 전용 장비인 만큼 도입 및 유지보수 단가가 매우 높으며, 오라클 전용 장비이므로 이기종 DBMS나 일반 파일 백업용으로는 활용할 수 없습니다.

④ 로컬 NFS / ZFS 스토리지 백업 (전통적 인프라 재활용)

고객 데이터센터 내에 이미 배치되어 있는 대용량 NAS 스토리지나 Oracle ZFS Storage Appliance를 NFS 프로토콜 기반으로 ExaCC 가상머신 OS 레이어에 direct 마운트하여 관리하는 고전적이고 확실한 방식입니다.

• 장점: 기존에 보유하고 있던 사내 유휴 스토리지 자산을 그대로 재활용할 수 있어 추가 인프라 지출 비용이 발생하지 않습니다. 외부 통신이 전혀 필요 없어 폐쇄망 환경에서 가장 안정적으로 구동됩니다.
• 단점: OCI 콘솔의 스마트한 백업 제어 기능을 일절 활용할 수 없습니다. 백업 스케줄러 등록(Linux Crontab 등 관리), 백업 파일 아카이빙 및 Retention 보존 주기 관리, 스토리지 파일시스템 full 임계치 알람 쉘 스크립트 작성 등 모든 운영 요소를 담당 DBA가 수동으로 구축하고 유지보수해야 하는 공수가 따릅니다.

4. 한눈에 보는 ExaCC 백업 전략 아키텍처 비교 요약

기업의 비즈니스 도메인과 시스템의 중요도에 따라 최적의 아키텍처를 선택할 수 있도록 핵심 지표를 매트릭스로 요약했습니다.

5. 실무 권장 제언

ExaCC 아키텍처에서 백업 전략을 수립할 때 만능의 단일 솔루션은 존재하지 않습니다. 기존에 기업 내부적으로 베리타스 넷백업을 전사 표준으로 채택하여 강력한 통합 모니터링 체계를 구축하고 있다면, 오늘 글에서 제시한 RMAN SBT API 방식을 적용하여 libobk.so64 연동과 백업 전용 분리 네트워크 설정을 최적화하는 것이 기존 운영 프로세스의 연속성 측면에서 가장 합리적입니다.

반면, 인프라 관리 인력이 부족하고 운영 자동화를 통한 TCO(총소유비용) 절감이 최우선 과제라면 OCI 오브젝트 스토리지 기반의 클라우드 네이티브 자동 백업을 적극 도입하는 것이 현명한 선택입니다. 각 시스템의 RTO(목표복구시간)와 RPO(목표복구시점), 그리고 보안 컴플라이언스 가이드라인을 면밀히 분석하여 최적의 ExaCC 백업 거버넌스를 성공적으로 구축하시길 바랍니다.

오늘 작성한 글이 ExaCC 백업을 구성하는데 조금이나마 도움이 되었으면 합니다.

전문가의 인사이트 : 함께 읽어 보세요.

AWS ECS Anywhere 설치 및 하이브리드 VM 연동 가이드

참조 및 출처 URL:

https://docs.oracle.com/en/solutions/deploy-osb-catc/index.html