오라클 ExaCC를 사내 NFS 스토리지에 백업할 때 엔지니어가 반드시 알아야 할 실전 트러블슈팅

Oracle Exadata Cloud@Customer(ExaCC)를 처음 도입했을 때만 해도 모든 게 장밋빛이었습니다. 클라우드의 편한 제어판을 쓰면서도 하드웨어는 우리 회사 전산실(IDC) 안에 두니 보안 걱정도 덜었죠. 기본 세팅대로 OCI 오브젝트 스토리지(Object Storage)에 백업을 올리려고 하니 곧바로 제동이 걸렸습니다.

금융권 컴플라이언스와 내부 데이터 보안 규정상 민감 데이터를 외부 클라우드로 내보내는 데 절차가 너무 까다로웠고, 매일 쏟아지는 수 테라바이트의 백업 트래픽 비용도 무시할 수 없었기 때문입니다.

결국 해결책은 하나였습니다. “사내 IDC에 굴러다니는 고성능 엔터프라이즈 NAS(NFS)를 ExaCC 백업 스토리지로 붙이자!”

단순히 마운트하고 OCI 콘솔에서 경로만 지정하면 끝날 줄 알았는데, 현업에서 마주친 프로토콜 충돌과 권한 오류 때문에 꼬박 며칠 밤을 새웠습니다. 저처럼 똑같이 고생할 엔지니어 분들을 위해, 실제 구축 절차와 필수 트러블슈팅 과정을 빠짐없이 공유합니다.

1. 시작 전 네트워크와 스토리지 밑작업: 길부터 제대로 닦자

ExaCC 노드는 트래픽 용도에 따라 네트워크 인터페이스가 복잡하게 쪼개져 있습니다. 대용량 백업 데이터가 실서비스 네트워크(Client IP)를 타고 흐르면 서비스 지연이 터집니다. 반드시 백업 전용 인터페이스(보통 bondeth1)를 타도록 경로를 분리해야 합니다.

• 네트워크 경로 확인: ExaCC DB 노드의 백업 전용 IP 대역 $\leftrightarrow$ IDC 내부 백업망 스위치 $\leftrightarrow$ NAS 백업 전용 인터페이스
• 방화벽 오픈: NFS 기본 포트인 2049(TCP), RPC 바인더 포트인 111(TCP/UDP) 양방향 오픈 필수
• NAS 스토리지 Export 정책: ExaCC는 RAC 환경이라 노드가 여러 대입니다. 클러스터를 이루는 모든 DB 노드(db01, db02 등)의 백업 IP를 스토리지 접근 허용 목록에 등록해야 합니다. 옵션은 rw, sync, no_root_squash를 반드시 챙겨두세요.

2. 수동 마운트 테스트 중 만난 복병: “Protocol not supported”

설정 파일(/etc/fstab)에 무턱대고 넣었다가 리부팅 시 부팅 지연이나 장애를 유발할 수 있습니다. 먼저 양쪽 DB 노드에서 디렉터리를 만들고 수동 마운트부터 시도했습니다.

Bash

# 양쪽 DB 노드 모두 동일하게 디렉터리 생성
sudo mkdir -p /mnt/nas_backup

오라클 가이드나 최신 문서만 믿고 야심 차게 NFS v4.1 옵션으로 마운트 명령어를 날렸습니다.

Bash

[root@db01 ~]# sudo mount -t nfs -o rw,bg,hard,nointr,rsize=1048576,wsize=1048576,proto=tcp,vers=4.1 10.65.0.160:/exacc_nas_bak /mnt/nas_backup
mount.nfs: Protocol not supported

왜 실패했을까?

원인은 허무하게도 버전 불일치였습니다. ExaCC 커널의 클라이언트는 v4.1을 요구하는데, 사내 IDC에 구축된 엔터프라이즈 레거시 NAS 스토리지는 펌웨어 기본값이 NFS v3 또는 v4.0까지만 켜져 있었던 겁니다.

해결 과정

터미널에서 스토리지 데몬이 지원하는 버전을 바로 조회했습니다.

Bash

rpcinfo -p 10.65.0.160 | grep nfs

결과를 확인해 보니 두 번째, 세 번째 컬럼에 3만 주르륵 뜨더군요. NAS 장비가 NFS v3만 지원하는 상태였습니다.

오라클 RMAN 엔진과 가장 궁합이 좋고 수십 년간 안정성이 검증된 NFS v3(vers=3)로 옵션을 낮춰 다시 실행하니 거짓말처럼 깔끔하게 마운트되었습니다.

Bash

# vers=3 옵션으로 안정적인 마운트 성공
sudo mount -t nfs -o rw,bg,hard,nointr,rsize=1048576,wsize=1048576,proto=tcp,vers=3 10.65.0.160:/exacc_nas_bak /mnt/nas_backup

보안 규정상 v4 계열을 써야 한다면 vers=4.0을 지정하거나, 버전 옵션 자체를 생략해 자동 협상(Negotiation)을 유도하는 것도 방법입니다.

3. 마운트는 됐는데 백업이 죽는다? “DBAAS-10102” 권한 에러

마운트가 끝나서 신나게 OCI 콘솔 백업을 돌렸더니 얼마 지나지 않아 아래와 같은 시뻘건 에러 메시지를 뱉어냈습니다.

Plaintext

DBAAS-10102 : Failed to create file or directory : /mnt/nas_backup/temp.txt. 
Given nasMountPoint /mnt/nas_backup is not writable 
CAUSE: The parent directory of file or directory might not have required permissions. 
ACTION: Fix the permissions on the required directories.

원인 파악

root 계정으로 마운트하면 기본적으로 마운트 디렉터리의 소유권이 root:root (권한 755)로 잡힙니다. 하지만 ExaCC 내부 백업 에이전트와 RMAN 엔진은 oracle 유저(oinstall 그룹) 권한으로 파일을 씁니다. 그러니 temp.txt 파일조차 만들지 못하고 터지는 것이죠.

여기에 NAS 스토리지 Export 정책에 root_squash가 걸려 있으면, 클라이언트 측 root가 아무리 권한을 바꾸려 해도 스토리지가 거부해 무용지물이 됩니다.

확실한 조치 방법

1단계: 디렉터리 소유권과 권한 변경

Bash

sudo chown -R oracle:oinstall /mnt/nas_backup
sudo chmod 775 /mnt/nas_backup

2단계: oracle 계정으로 직접 쓰기 테스트 (필수 검증)

root 권한으로 확인하면 안 됩니다. 반드시 oracle 계정으로 스위칭해서 파일을 만들고 지워봐야 합니다.

Bash

sudo -u oracle touch /mnt/nas_backup/temp.txt
sudo -u oracle rm /mnt/nas_backup/temp.txt

여기서 에러 없이 파일이 생성되고 지워진다면 권한 문제는 100% 해결된 것입니다.

(만약 소유권 변경 시 Operation not permitted가 뜬다면, 스토리지 관리자에게 연락해 ExaCC 백업 IP 대역에 no_root_squash 옵션을 부여해 달라고 요청해야 합니다.)

4. 재부팅에도 살아남는 영구 마운트(/etc/fstab) 설정

장비가 재부팅되어도 마운트가 풀리지 않도록 모든 RAC 노드의 /etc/fstab에 마운트 구문을 등록합니다. 옵션 하나하나가 RMAN의 안정성에 직결됩니다.

Plaintext

10.65.0.160:/exacc_nas_bak /mnt/nas_backup nfs rw,bg,hard,nointr,rsize=1048576,wsize=1048576,proto=tcp,vers=3 0 0

필수 마운트 옵션 한 줄 정리

• bg (Background): 부팅 시 NAS가 일시적으로 안 열려도 서버 부팅이 멈추지 않고 백그라운드에서 재시도합니다.
• hard: 네트워크가 튀었을 때 I/O를 즉각 포기하지 않고 대기하여 백업 파일 깨짐을 방지합니다.
• nointr: 백업 중 임의의 인터럽트 신호로 트랜잭션이 끊기는 현상을 막아줍니다.
• rsize=1048576,wsize=1048576: 버퍼 블록 크기를 1MB로 설정해 기가바이트 단위 RMAN 피스 전송 속도를 극대화합니다.

등록 후에는 반드시 언마운트 후 자동 마운트가 되는지 테스트해 보세요.

Bash

sudo umount /mnt/nas_backup
sudo mount -a
df -hT /mnt/nas_backup

5. OCI 콘솔과 CLI로 자동 백업 완성하기

OS 작업이 끝났으니 이제 오라클 클라우드 제어판에 NAS를 백업 타깃으로 등록할 차례입니다.

1) Backup Destination 생성

1. OCI 콘솔에 로그인하여 Oracle Database $\rightarrow$ Exadata Cloud@Customer로 이동합니다.
2. 좌측 메뉴에서 Backup Destinations를 누르고 Create Backup Destination을 클릭합니다.
3. Type은 Network File System (NFS)을 고르고, 이름(예: IDC_NAS_BACKUP_DEST)과 함께 앞서 작업한 로컬 경로인 /mnt/nas_backup을 입력합니다.
4. 생성이 완료되고 상태가 초록색 Active로 바뀌는지 확인합니다.

2) 자동 백업 정책 매핑 및 즉시 테스트

데이터베이스 상세 페이지로 들어가 Configure Automatic Backups를 활성화합니다.

• Backup Destination: 방금 만든 IDC_NAS_BACKUP_DEST 선택
• 보존 기간(Retention): 사내 백업 주기 규정에 맞게 설정 (예: 14일, 30일)
• 백업 윈도우: 업무 트래픽이 가장 적은 새벽 시간대 지정

저장 후 첫 백업 시간까지 기다릴 필요 없이 터미널에서 CLI로 즉시 수동 백업을 트리거해 검증합니다.

Bash

sudo dbaascli database backup --start --dbname <DB_NAME>

마운트 경로(/mnt/nas_backup) 밑에 DB 이름으로 디렉터리가 생성되면서 RMAN 백업 피스들이 차곡차곡 쌓이면 모든 구축이 성공적으로 끝난 것입니다.

실무 운영에서 뼈저리게 느낀 주의사항 2가지

1. RAC 노드 간 마운트 불일치 주의: ExaCC는 노드가 2개 이상인 클러스터입니다. 1번 노드만 마운트되고 2번 노드가 풀려 있으면, 노드 장애(Failover)가 발생하거나 2번 노드에서 백업 배치 프로세스가 돌 때 그대로 장애로 이어집니다.
2. NAS 용량 임계치(80%) 모니터링 필수: NAS 스토리지 용량이 100% 꽉 차면 백업만 실패하는 게 아닙니다. RMAN이 이전 아카이브 로그(Archive Log)를 삭제하지 못해 DB 노드의 FRA 영역이 가득 차고, 결국 데이터베이스 전체가 멈춰버리는(Hang) 대형 사고가 발생할 수 있습니다. 스토리지 사용량 알람은 꼭 걸어두시길 바랍니다.

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

내가 밤새며 찾아낸 ExaCC-NetBackup 타임아웃(Status 41) 장애의 범인과 해결책

참조 및 출처 URL:

https://docs.oracle.com/en/database/oracle/oracle-database/19/cwlin/about-nfs-storage-for-data-files.html