[OPNsense 시리즈 6편] 백업·업데이트·복구 전략과 전용 하드웨어로 옮겨야 할 때

이제 VLAN까지 정리했다면 네트워크는 안정적일까요? 그렇지 않습니다. 설정 파일을 잘못 덮어쓰거나 Proxmox 호스트가 죽으면 방화벽도 같이 멈춥니다. 특히 "가상화된 방화벽"은 하이퍼바이저·스토리지·전원에 모두 의존하므로, 설계만큼이나 운영 절차가 중요합니다. 이 글에서는 OPNsense + Proxmox 조합을 운영하면서 꼭 챙겨야 할 백업·업데이트·복구 흐름을 정리하고, 언제 전용 하드웨어로 옮겨야 하는지 판단하는 체크리스트까지 제공합니다.

이 글의 흐름

어떤 징후가 보이면 운영 전략을 재정의해야 하는가
3-2-1 백업 계층과 저장 위치, RTO/RPO를 어떻게 설계할 것인가
백업을 전제로 안전한 업데이트·롤백 순서를 어떻게 잡을 것인가
장애 유형별 복구 플레이북과 체크리스트를 어떻게 준비할 것인가
언제 가상화 대신 전용 하드웨어로 옮겨야 하는가

이번 글에서 다루는 용어

구성 백업 (Configuration Backup): OPNsense의 전체 설정을 XML 또는 암호화된 .bak 파일로 내보낸 자료. 인증서·VPN 키까지 포함하므로 백업 키를 별도 보관해야 합니다.
스냅샷 (Snapshot): Proxmox가 VM의 디스크 상태를 시점별로 저장한 증분 데이터입니다. 원본 저장소가 손상되면 함께 사라지므로 오프사이트 백업과 함께 써야 합니다.
콜드 스탠바이 (Cold Standby): 평소에는 전원을 끄고 두지만 장애가 나면 부팅해 임시 방화벽 역할을 하는 예비 장비입니다. RTO에 부팅 시간(5~10분)이 포함된다는 점을 기억하세요.
RTO/RPO: 복구 목표 시간(Recovery Time Objective)과 데이터 손실 허용 범위(Recovery Point Objective). 예를 들어 RTO 15분, RPO 4시간이면 "15분 안에 서비스 재개, 최대 4시간 전 상태까지 되돌리기"를 의미합니다.
HA 페어 (High Availability Pair): 두 대 이상의 방화벽을 CARP/VRRP로 묶어 이중화한 구조입니다. 두 장비가 동일 VLAN에 있어야 하며, 상태 동기화를 위한 전용 링크가 필요합니다.

읽기 카드

예상 소요 시간: 17분

사전 준비: OPNsense 백업 메뉴, Proxmox 스냅샷 메뉴 사용 경험, 외부 저장공간 또는 Git/Cloud 드라이브 계정

읽고 나면: 어떤 파일을 어떤 주기로 백업하고, 업데이트 순서를 어떻게 잡으며, 전용 장비를 도입해야 하는 시점을 설명할 수 있습니다.

왜 다시 운영 전략을 점검해야 하는가

VLAN을 포함한 네트워크 설계가 끝났다고 해서 운영이 자동으로 안전해지지 않습니다. 다음 조건 중 하나라도 해당되면 백업·업데이트 정책이 필요합니다.

Proxmox 호스트 한 대가 모든 서비스와 방화벽을 동시에 담당한다.
인터넷 연결이 끊기면 원격 근무/서비스가 즉시 중단된다.
방화벽 규칙이 복잡해져서 실수 한 번에 전체 네트워크가 막힐 수 있다.

이 시점에서는 “무슨 일이 생길 수 있는가?”를 미리 열거하고, 각 시나리오에서 얼마의 RTO/RPO를 허용할지 정해야 합니다.

백업 전략: 무엇을 어디에 저장할까

백업은 3-2-1 원칙(3개의 사본, 2개의 다른 매체, 1개는 오프사이트)을 만족하도록 세 층으로 나누면 관리가 쉬워집니다.

계층	저장 위치	권장 주기	목표 RTO/RPO	주의할 점
OPNsense 구성 백업	Git/비공개 클라우드, 암호화된 `.bak`	방화벽 규칙 변경 시마다 + 주 1회	RTO 10분 / RPO 1일	복호화 키를 백업과 분리 보관, 복원 테스트는 테스트 VM에서 먼저 수행
Proxmox VM 백업 (PBS/NAS)	Proxmox Backup Server, ZFS 스냅샷, 외부 NAS	최소 일 1회, 변경량 많으면 4시간 간격	RTO 30분 / RPO 4~24시간	스냅샷만으로는 호스트 장애 대응 불가 → PBS 또는 외부 스토리지 필수
문서화·Runbook·스위치 설정	Git, 위키, 비공개 문서 저장소	변경 즉시 커밋	RTO 영향 없음 / RPO 0	VLAN ID·포트 매핑·복구 절차를 최신 상태로 유지, 접근 권한 관리

아래 D2 다이어그램은 백업 계층 사이의 흐름을 표현합니다.

Tip: XML 백업만으로는 RTO를 줄이기 어렵습니다. 월 1회 이상 PBS 또는 NAS에서 전체 복구 리허설을 진행해 "백업을 복원할 때 어떤 입력이 필요한지"를 미리 확인하세요. 암호화된 백업의 복호화 키는 별도의 비밀 저장소에 기록합니다.

업데이트 순서와 롤백 포인트

업데이트는 항상 “백업 → 테스트 → 배포” 순서로 진행합니다. Proxmox와 OPNsense 모두 커널·패키지 업데이트가 잦으므로, 아래 순서를 매번 동일하게 반복하면 실수를 줄일 수 있습니다.

스냅샷/백업 확보: Proxmox에서 qm snapshot <VMID> pre-opnsense-update를 만들고, PBS 백업 작업이 최근 24시간 안에 성공했는지 확인합니다.
Proxmox 호스트 업데이트: apt update && apt full-upgrade 후 재부팅합니다. 이때 Proxmox UI 접근이 끊기므로 콘솔/IPMI를 확보합니다.
OPNsense 펌웨어 업데이트: System > Firmware > Updates에서 미세 버전을 먼저 적용하고, Major 업그레이드는 릴리스 노트를 확인한 뒤 진행합니다. IDS/IPS를 사용 중이면 Services > Intrusion Detection에서 룰셋 버전도 동기화합니다.
검증: Part 5에서 만든 테스트 절차(서비스/관리/게스트 → 인터넷, VLAN 간 차단, VPN 진입)를 동일하게 실행합니다. Firewall > Live View에 로깅이 켜져 있어야 검증 로그를 남길 수 있습니다.

롤백 포인트는 두 줄기로 잡습니다.

하이퍼바이저 레벨: qm rollback <VMID> pre-opnsense-update로 디스크 상태를 되돌릴 수 있도록 최신 스냅샷을 유지합니다. 단, 스냅샷을 너무 여럿 쌓으면 성능이 떨어지므로 업데이트 전후로 정리합니다.
방화벽 레벨: System > Configuration > Backups에서 최신 .bak 파일을 내려받고, 필요 시 opnsense-backup restore CLI로 즉시 복구합니다. SSH 콘솔 접근이 막히면 Proxmox 콘솔 또는 콜드 스탠바이 장비를 통해 작업합니다.

장애 유형별 복구 흐름

장애 시나리오는 크게 세 가지로 나눌 수 있습니다. 각 시나리오마다 "누가 어떤 도구로 무엇을 복구하는가"를 미리 문서화하면 현장에서 헤매지 않습니다.

설정 실수로 OPNsense만 먹통: Proxmox와 스위치는 정상이고, OPNsense 설정만 꼬였습니다.
Proxmox 호스트 다운: 하드웨어 문제나 커널 패닉 등으로 방화벽 VM까지 함께 멈췄습니다.
전체 전원/스토리지 장애: NAS, PBS까지 모두 접근 불가능한 상태입니다.

아래 D2 다이어그램은 장애별 대응 순서를 요약합니다.

복구 체크리스트

장애 유형	1단계	2단계	3단계
OPNsense 설정 오류	Proxmox 콘솔에서 메뉴 `1) Restore a configuration` 실행	최신 `.bak` 또는 XML을 선택하고 복원	재부팅 후 `Interfaces > Overview`에서 VLAN 상태 확인
Proxmox 호스트 다운	콜드 스탠바이(NUC/미니PC)에 OPNsense ISO + USB NIC 연결, 기본 WAN/LAN 구성	PBS/NAS에서 최신 VM 백업을 새로운 Proxmox 호스트나 스탠바이에 복원	스위치 트렁크 포트가 새 NIC와 매칭되는지 점검
전원/스토리지 장애	UPS/전원 라인을 분리해 원인 제거, 외부 SSD/클라우드에서 백업 다운로드	최소 구성(인터넷 게이트웨이 + 관리 VLAN)부터 복원	서비스 VLAN과 게스트 VLAN을 순차적으로 투입, 로그로 정책 검증

각 단계가 끝날 때마다 Runbook에 체크 표시를 남기고, 장애 후 회고(Postmortem)에 실제 RTO/RPO를 기록해 계획과의 차이를 분석합니다.

전용 하드웨어로 옮겨야 하는 시점

다음 조건에 하나라도 해당하면 OPNsense를 Proxmox 밖의 전용 장비로 분리하는 편이 낫습니다. 가상화 환경에서는 Proxmox 호스트 자체가 단일 장애 지점이 되기 때문에, 아래 항목을 정기 점검표에 포함하세요.

RTO가 수분 단위로 짧다: Proxmox가 재부팅되는 동안에도 인터넷/사내망이 살아 있어야 한다. VM 부팅 시간을 제거하려면 전용 장비가 필요합니다.
트래픽이 1Gbps를 넘어선다: 가상화 계층이 병목이 되어 CPU 오버헤드가 커집니다. 특히 IDS/IPS와 TLS 오프로딩을 동시에 쓰면 VirtIO NIC가 1Gbps를 넘기 어렵습니다.
이중화를 요구한다: VRRP/CARP 같은 HA 구성을 하려면 최소 2대의 물리 장비가 필요합니다. 가상화 환경에서도 가능하지만, 동일 하이퍼바이저에 2개의 방화벽 VM을 올리면 진정한 HA가 아닙니다.
보안 정책: 방화벽이 가상화 계층과 동일한 커널을 공유하는 것을 금지하거나, 감사 요건이 분리된 하드웨어를 요구합니다.
부팅 순서 의존성: Proxmox가 먼저 부팅되어야 OPNsense가 살아나고, OPNsense가 살아야 Proxmox에 외부 접속이 가능한 구조라면, 순환 의존을 끊기 위해 전용 장비가 필요합니다.

의사결정 표를 간단히 만들어 보자면 다음과 같습니다.

조건	가상 환경 유지	전용 하드웨어 필요
허용 다운타임이 30분 이상	✅
인터넷 중단이 5분 이하이어야 함		✅
트래픽이 1Gbps 이하	✅
IDS/IPS + 암호화 트래픽 2Gbps 이상		✅
예산/전력 제약이 크다	✅
별도 감사/보안 요건 존재		✅

흔한 실수

백업과 복원 테스트를 분리하지 않음: 백업 파일이 실제로 복원되는지 검증하지 않으면 장애 시 동작 보장이 없습니다.
업데이트 전 스냅샷을 만들지 않음: 스냅샷 없이 OPNsense를 업데이트하면, 오류 발생 시 수동으로 ISO를 부팅해 복구해야 합니다.
게스트 VLAN DNS를 내부 DNS로 지정: 게스트가 내부 호스트명을 그대로 조회할 수 있으므로 의미가 없습니다.
Proxmox와 OPNsense를 같은 UPS에만 의존: UPS가 꺼지면 둘 다 동시에 죽으므로, 최소한 방화벽은 다른 전원 경로를 두거나 콜드 스탠바이를 마련합니다.
전용 하드웨어로 옮길 계획 없이 확장: 트래픽이 늘어난 뒤에야 장비를 구하면 조달/설치 시간 동안 RTO를 충족하지 못합니다.

마무리

이 시리즈의 마지막 편에서는 "설계한 네트워크를 어떻게 지킬 것인가"에 집중했습니다. 마지막으로 운영 체크리스트를 다시 강조합니다.

백업 계층을 나눠라: OPNsense 설정, Proxmox VM 이미지, Runbook·문서를 서로 다른 저장소에 둡니다. 복호화 키와 Runbook은 별도 보관합니다.
업데이트 순서를 선형으로 잡아라: 백업 → Proxmox 업데이트 → OPNsense 업데이트 → 테스트 순서를 지키고, 매 단계 종료 후 스냅샷을 정리합니다.
복구 플레이북을 시험하라: 분기별로 콜드 스탠바이를 부팅해 보고, PBS 복원·XML 복원을 실제로 실행해 봅니다.
전용 하드웨어 도입 시점을 대비하라: RTO/RPO 요구사항과 트래픽이 늘어날수록 가상화 계층 밖으로 방화벽을 빼야 합니다.

이제 남은 일은 주기적으로 Runbook을 점검하고, 실제 복구 테스트를 수행하는 것입니다. 그래야 “가상화된 방화벽”이 실험 환경이 아니라 운영 환경의 한 축으로 자리 잡을 수 있습니다.