결론부터 말씀드리면, 절대 아닙니다. 오라클이 시스템 안정성을 위해 수행하는 백업과 우리가 실무 현장에서 진짜로 필요한 백업 사이에는 상상 이상으로 거대한 간극이 존재합니다. 실제로 이 사실을 모르고 있다가 담당자의 명령어 실수(Human Error)나 스크립트 꼬임 현상이 발생했을 때, “오라클에 백업본이 있으니 복구해달라”고 SR(Service Request)을 열었다가 피눈물을 흘리는 케이스를 여럿 보았습니다.

그렇다면 오라클 공식 기술 문서(Doc ID 2809393.1)와 실제 SR 상담 내용에 숨겨진 ExaCC OS 백업의 실체는 무엇일까요? 데이터 유실로 밤새 고통받지 않기 위해 엔지니어가 반드시 알아야 할 Dom0 /CBR 파일시스템의 비밀과 완벽한 방어 아키텍처를 낱낱이 파헤쳐 보겠습니다.

1. ExaCC 백업 구조의 본질: ASM과 OS는 사는 세상이 다르다

ExaCC는 일반적인 온프레미스 장비나 단순 가상화 서버와 완전히 다릅니다. 하드웨어와 하이퍼바이저 인프라는 오라클이 관리하고, 그 위에서 구동되는 게스트 운영체제(VM)와 데이터베이스는 고객이 책임지는 ‘공동 관리 모델(Shared Responsibility Model)’을 기반으로 작동하기 때문입니다.

이 구조적 특징 때문에 백업 영역 또한 철저하게 이원화되어 있습니다.

자동화된 데이터베이스 백업 (ASM 영역)

OCI(Oracle Cloud Infrastructure) 콘솔이나 내부 CLI 툴(dbaascli)을 통해 설정하는 정기 백업은 오직 데이터베이스 영역만을 타깃으로 합니다.

백업 대상: ASM(Automatic Storage Management) 디스크 그룹에 존재하는 +DATA 및 +RECO 영역 (DB 데이터 파일, 컨트롤 파일, 리두/아카이브 로그, TDE Wallet 등)
백업 특징: 매주 일요일 Full 백업, 매일 증분(Incremental) 백업이 수행되며 오브젝트 스토리지나 온프레미스 복구 어플라이언스(ZDLRA)로 전송됩니다.

운영체제 백업 (OS 영역 – DomU)

여기가 바로 오늘의 핵심입니다. 우리가 실제로 접속해서 쉘 스크립트를 짜고, 환경 설정을 바꾸고, 로그를 쌓는 게스트 가상 머신(DomU)의 로컬 파일시스템 영역입니다.

대상 범위: 루트 파일시스템(/), 사용자 홈 디렉터리(/home), 시스템 로그(/var/log), 그리고 그리드 인프라 및 오라클 DB 엔진이 설치되는 /u01 영역
관리 주체: 기본적으로 이 영역 내에 저장되는 고객 커스텀 파일 및 설정 파일의 백업 책임은 100% 고객(User)에게 있습니다. 오라클의 일일 DB 자동 백업 스케줄은 이 로컬 파일시스템을 전혀 추적하지 않습니다.

2. 오라클 SR로 확인한 Dom0 백업의 허와 실

그렇다면 오라클 SR을 통해 전달받는 *”매주 토요일 23:00 UTC에 Dom0에서 모든 가상 VM 백업을 수행한다”*는 답변의 진짜 의미는 무엇일까요? 실제 오라클 공식 SR 답변을 직관적으로 분석해 보겠습니다.

[Oracle SR 공식 답변]
“VM backups are scheduled to run every Saturday at 23:00 UTC on each Dom0, ensuring that all existing VMs are backed up. Once a new backup is completed, it overwrites the previous backup.”

이 짧은 문장 속에는 엔지니어가 놓쳐서는 안 될 치명적인 함정이 숨어 있습니다.

하이퍼바이저(Dom0) 레벨의 통백업

오라클 클라우드 운영팀(Cloud Operations)은 인프라 자체의 안정성을 위해 가상화 관리 계층인 Dom0(Hypervisor) 레벨에서 백업 스크립트를 돌립니다. 이때 하위에 매달려 있는 가상 VM(DomU)들의 시스템 가상 디스크(LVM 및 이미지 파일) 전체를 통째로 복사합니다.

따라서 구조적으로 스토리지 데이터 영역(ASM)을 제외한 VM 파일시스템 전체(/, /u01 등)가 백업되는 것은 맞습니다.

치명적인 한계: 덮어쓰기(Overwrite)와 단 1세대의 보관 주기

실무 운영 관점에서 보면 이 백업은 그야말로 시한폭탄과 같습니다. 오라클의 Dom0 백업은 보관 주기(Retention)가 딱 ‘1’로 설정되어 있기 때문입니다.

즉, 매주 토요일 밤에 새로운 주간 백업이 성공적으로 완료되는 순간, 지난주에 받아두었던 백업본은 물리적으로 완전히 삭제(Overwrite)됩니다.

인적 오류(Human Error) 추적 불가능: 예를 들어 수요일에 한 담당자가 실수로 OS 내의 중요 환경 설정 파일이나 배치 스크립트를 날렸다고 가정해 봅시다. 일주일간 이 사실을 인지하지 못하고 다음 주 월요일에 문제를 발견했다면 어떻게 될까요? 이미 지난 토요일 밤에 ‘파일이 삭제된 상태의 VM’이 백업되면서 이전 백업을 덮어써 버렸기 때문에 오라클 백업본을 통해서는 영구히 복구할 수 없습니다.
개별 파일 단위(File-level) 복구 불가: 이 백업은 하드웨어 전파괴나 하이퍼바이저 붕괴 시 시스템을 통째로 롤백하기 위한 ‘이미지 백업’입니다. “특정 경로의 파일 하나만 깨졌으니 꺼내달라”는 식의 세부 요청은 오라클 SR을 통해 지원받을 수 없습니다.

3. OS 백업 파일은 어디에 숨겨져 있을까?

보안이나 망 분리 관리를 담당하는 엔지니어라면 이 백업 데이터가 통신망을 타고 오라클 클라우드 본사 서버로 가는지, 아니면 우리 전산실 안에 머무르는지 파악하는 것이 무엇보다 중요합니다.

저장소 위치: ExaCC 장비 내부 (로컬 Compute Node)

결론부터 말씀드리면, 이 주간 OS 백업 데이터는 외부 오라클 클라우드(OCI) 공간으로 전송되지 않으며 ExaCC 물리 장비 내부(Compute 노드의 내부 로컬 로테이션 디스크 영역)에 저장됩니다.

ExaCC는 고객사 내부 망에 설치되는 장비입니다. 매주 수백 GB에 달하는 가상 VM 이미지들을 외부 퍼블릭 클라우드로 쏘아 올리면 고객사의 인터넷 대역폭이 고갈되는 대형 네트워크 장애가 발생하겠죠. 또한, “고객의 데이터와 시스템 형상은 고객사 보안 경계를 넘어가지 않는다”는 ExaCC의 대원칙에 따라 철저하게 로컬 장비 내부에 격리 보관됩니다.

세부 파일시스템 경로: `/CBR/backup/`

이 백업 파일들은 우리가 사용하는 일반 VM(DomU) 터미널에서는 아무리 찾으려 해도 보이지 않습니다. 하이퍼바이저 영역인 Dom0 OS에 root 계정으로 접근해야만 확인이 가능한 전용 격리 공간에 존재합니다.

물리적 파일시스템 영역: Dom0 내부의 CBR (Cloud Backup and Recovery) 전용 마운트 포인트
상세 경로 주소: /CBR/backup/ 또는 시스템 버전에 따라 /OVS/ 하위 디렉터리
저장 형태: 가상 머신의 각 가상 볼륨(Virtual Disk Image)을 tar.gz 압축 포맷이나 img 원본 바이너리 덤프 형태로 저장

Dom0의 /CBR 파일시스템은 고객 VM이 사용하는 스토리지 공간과 논리적·물리적으로 완전히 분리되어 있습니다. 고객 VM 내부의 용량이 꽉 차더라도 백업 영역에는 영향을 주지 않도록 정교하게 파티셔닝되어 있죠. 하지만 반대로 공간의 한계가 명확하기 때문에 오라클이 단 1세대만 보관(Overwrite)하는 정책을 고수하는 것이기도 합니다.

4. Doc ID 2809393.1 기반 권장 백업 아키텍처

오라클의 공식 기술 문서인 Doc ID 2809393.1 (“Exadata Cloud Compute Node Backup and Restore Operations”)을 보면, 오라클 역시 자신들이 해주는 Dom0 백업의 한계를 명확히 인정하고 있습니다. 그러면서 고객들에게 자체적인 OS 레벨 백업 계획을 수립할 것을 강력하게 권장(Best Practice)하고 있죠.

장비 전체의 물리적 장애(화재, 침수 등)나 운영자의 실수로부터 시스템을 완벽하게 방어하기 위해, 오라클 공식 문서 가이드라인에 따른 3가지 백업 아키텍처 전략을 반드시 실행해야 합니다.

전략 1: 파일 단위(File-level) Tar 백업 및 외부 NFS 반출

OS 환경 설정 정보와 업무용 커스텀 스크립트는 용량은 작지만 잃어버렸을 때 타격이 가장 큽니다. VM(DomU) 내부에서 주기적으로 백업을 수행해야 합니다.

대상 디렉터리 지정: 주요 설정 파일이 몰려 있는 /etc, 오라클 네트워크 환경 설정이 포함된 $ORACLE_HOME/network/admin, 그리고 자체 생성한 쉘 스크립트 경로를 타깃으로 잡습니다.
자동 스크립트 배포: 크론탭(Crontab)을 이용해 주간/일간 단위로 tar.gz 압축본을 생성합니다.
외부 스토리지 마운트: 생성된 압축 파일을 ExaCC 장비 내부가 아닌, 고객사가 기존에 보유하고 있던 사내 NAS/NFS 스토리지 영역으로 자동 전송(rsync 또는 cp) 처리합니다. 그래야 장비 전체가 다운되더라도 설정 원본을 지킬 수 있습니다.

전략 2: LVM(Logical Volume Manager) 스냅샷 활용

Doc ID 2809393.1에서 강조하는 기술적 핵심 중 하나는 OS가 구동 중인 실시간 상태에서 정성적인 백업을 받기 위해 LVM 스냅샷 기능을 적극 활용하라는 것입니다.

VM(DomU)의 볼륨 그룹에 여유 공간(Free Space)을 어느 정도 할당해 둔 상태에서, 중요 패치나 작업 직전에 LVM 스냅샷 명령어를 통해 동결된 시점의 OS 이미지를 로컬에 생성합니다. 작업이 실패하거나 롤백이 필요할 때 오라클 SR을 열고 하염없이 대기할 필요 없이, 엔지니어가 즉시 LVM 스냅샷 복구를 통해 몇 분 만에 서비스를 정상화할 수 있는 가장 확실한 무기입니다.

전략 3: OCI Object Storage 연동 (고객 소유 테넌시)

인터넷 망 또는 전용선 연결이 허용된 ExaCC 환경이라면, OCI CLI 툴을 DomU 내부에 설치하여 백업 파일을 고객 소유의 OCI 오브젝트 스토리지로 직접 업로드하는 파이프라인을 구축할 수 있습니다.

이 방식은 무제한에 가까운 보관 주기(Retention)를 고객사의 정책에 따라 자유롭게 제어(예: 30일 보관, 3개월 보관 등)할 수 있어, 가장 추천되는 모던 클라우드 백업 아키텍처입니다.

5. 결론: 우리 시스템은 정말 안전할까? 요약 체크리스트

오늘 살펴본 내용을 한 줄로 요약하면 다음과 같습니다.

“오라클이 매주 토요일 Dom0 /CBR 영역에 통백업을 해주긴 하지만, 단 1주일만 보관되고 개별 파일 복구도 불가능하므로 반드시 독자적인 OS 백업 시스템을 구축해야 한다.”

안정적인 인프라 운영을 위해, 지금 즉시 아래 체크리스트를 바탕으로 자사 시스템을 점검해 보시기 바랍니다.

우리 팀은 ExaCC VM(DomU) 내부의 /etc, /home, 커스텀 스크립트 경로에 대해 별도의 자체 백업을 수행하고 있는가?
생성된 OS 백업본이 ExaCC 내부 디스크가 아닌, 회사 사내 NAS나 외부 독립 스토리지로 정상 반출되고 있는가?
오라클 인프라 패치(OS 패치, GI/DB 패치) 진행 전, 롤백을 위한 수동 백업(LVM 스냅샷 등) 절차를 표준 운영 가이드(SOP)에 반영했는가?
오라클 My Oracle Support(MOS)에 접속하여 Doc ID 2809393.1 문서의 백업 스크립트 가이드를 다운로드하여 검토했는가?

철저하게 직접 관리하는 백업만이 예기치 못한 장애와 인적 오류 속에서 기업의 소중한 데이터 자산을 완벽하게 방어할 수 있는 유일한 열쇠입니다. 본 가이드를 바탕으로 사각지대 없는 Exadata 클라우드 운영 환경을 다져보시길 바랍니다.

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

docker? conda? 20년 차 엔지니어가 딱 정해주는 파이썬 가상환경 선택

참조 및 출처 URL:

https://docs.oracle.com/en/cloud/cloud-at-customer/exadata-cloud-at-customer/exacc/back-and-recover.html

“오라클이 해주니까 안전하다?” 자동 ExaCC OS backup의 치명적인 함정

오라클이 다 해준다? ExaCC OS 백업의 위험한 오해