Proxmox를 몇 주만 사용해도 가장 먼저 마주치는 한계는 스토리지입니다. 설치 직후 자동으로 잡힌 local과 local-lvm을 그대로 쓰다가 VM 디스크와 ISO, 백업이 한 디스크에 뒤섞이면 되돌릴 방법이 헷갈립니다. 반대로 스냅샷과 백업을 명확히 분리하고, 로컬 디스크·NAS·Proxmox Backup Server(PBS)를 어떤 기준으로 나눌지만 잡아 두면 작은 미니 PC도 안정적인 복구 루틴을 갖게 됩니다.
이번 글은 “어디에 무엇을 두고, 문제가 생기면 어떻게 되돌릴 것인가”라는 질문에 답하기 위한 실무적 기준을 정리합니다.
이 글의 흐름
- Proxmox 스토리지 유형과 역할 정리
- 스냅샷과 백업을 구분하는 사고방식
- 오프호스트 백업 타깃(NAS, PBS) 선택과 연결
- 복구를 설계하는 단계별 체크리스트
- 로컬 스토리지와 외부 스토리지의 실전 조합
이번 글에서 새로 나오는 용어
- 스토리지 풀 (Storage Pool): Proxmox가 특정 백엔드(LVM-Thin, LVM, ZFS, Directory, NFS, CIFS, PBS 등)를 추상화해 관리하는 단위입니다. 풀마다 지원 콘텐츠가 다르므로, 예를 들어
local(Directory)은 ISO·백업 전용,local-lvm(LVM-Thin)은 VM 디스크/LXC 루트 전용입니다. - 씬 프로비저닝 (Thin Provisioning): VM에 지정한 논리 용량과 별개로 실제 사용량만 물리 디스크에 쓰도록 하는 방식입니다. 덕분에 여러 VM이 하나의 풀을 공유할 수 있지만, 사용률이 100%에 근접하면 메타데이터 풀이 먼저 고갈되어 쓰기 실패와 VM 정지가 발생합니다.
- Proxmox Backup Server(PBS): 델타 블록 전송, 콘텐츠 주소 기반 중복 제거, 암호화, 백업 무결성 검증을 제공하는 Proxmox 전용 증분 백업 서버입니다.
- 복구 드라이 런 (Dry Run): 운영 VM을 건드리지 않고 격리된 스토리지나 테스트 VM에 백업을 복구해 부팅·서비스 체크까지 반복 연습하는 절차입니다.
전제 확인
- Proxmox 8.x 단일 호스트 기준으로 설명합니다. 클러스터·Ceph 환경이라면 추가 고려가 필요합니다.
- 기본 네트워크 브릿지(
vmbr0)를 이미 구성했고, UI 경로(Datacenter > Storage,Datacenter > Backup)를 방문해 본 독자를 가정합니다.
읽기 카드
- 예상 소요 시간: 20분
- 사전 준비: Proxmox에서 VM 또는 LXC를 하나 이상 생성해 본 경험
- 읽고 나면: 스냅샷·백업·오프호스트 저장소를 언제 어떻게 조합해야 하는지 그림을 그릴 수 있습니다.
Proxmox 스토리지 구성을 보는 기본 관점
Proxmox 설치 직후에는 두 개의 스토리지 풀이 기본 제공됩니다.
- local: ISO, 템플릿, 백업 파일을 담는 Directory 타입. VM 디스크는 저장할 수 없습니다.
- local-lvm: VM 디스크와 LXC 루트를 담는 LVM-Thin 풀.
두 풀은 억지로 섞이지 않지만, 물리 디스크가 하나라면 결국 용량과 장애 범위를 공유한다는 점이 문제입니다. 즉 ISO를 무한히 쌓으면 local-lvm까지 여유가 좁아지고, 디스크가 죽으면 두 풀이 동시에 사라집니다. 따라서 아래 원칙을 먼저 세웁니다.
- 운영 VM/LXC 디스크는 빠른 SSD에 둔다. 실시간 워크로드는 지연 시간이 중요합니다.
- ISO·템플릿은 용량보다 관리가 쉽도록
local에 둔다. 필요하면 NFS/SMB 공유를 추가해 여러 호스트에서 재사용합니다. - 백업은 호스트 밖으로 내보낸다. 최소한 다른 디스크, 가능하면 다른 장비나 NAS에 둡니다.
Proxmox UI의 Datacenter > Storage에서 LVM-Thin, ZFS, Directory, NFS, CIFS, PBS 등 다양한 타입을 추가할 수 있으므로, 물리 디스크와 네트워크 스토리지의 조합을 미리 설계하는 것이 중요합니다.
스냅샷과 백업을 구분하는 사고방식
많은 입문자가 “스냅샷이 있으니 백업은 나중에”라고 생각했다가 디스크 장애에서 그대로 무너집니다. 둘의 목적과 동작 범위를 표로 먼저 정의하면 판단이 빨라집니다.
| 항목 | 스냅샷 | 백업 |
|---|---|---|
| 저장 위치 | 같은 풀(LVM-Thin, ZFS 등) | 다른 디스크/NAS/PBS |
| 생성 속도 | 초·분 단위 | 분·시간 단위 |
| 장애 내성 | 풀/호스트 장애 시 같이 소실 | 호스트를 잃어도 유지 |
| 사용례 | 업데이트 직전 즉시 롤백 | 디스크 손실, 랜섬웨어, 새 하드웨어 복구 |
| 주의점 | 많은 체인을 쌓으면 성능 저하, 용량 급증 | 복구 시간(RTO)와 백업 주기(RPO)를 명시해야 함 |
스냅샷: 같은 스토리지 내 실험용 되돌리기
- LVM-Thin은 Copy-on-Write 방식으로 변경 블록을 따로 저장합니다. 스냅샷 체인이 깊어질수록 각 쓰기마다 메타데이터 블록을 여러 번 참조하므로 지연 시간이 누적됩니다.
- ZFS는 읽기 전용 시점 스냅샷을 유지합니다. 스냅샷이 많아져도 쓰기 성능 영향이 작지만, 스냅샷이 참조하는 블록은 삭제 전까지 해제되지 않습니다.
- 실행 중인 VM을 찍으려면 qemu-guest-agent, Windows VSS, DB 전용 쿼지스 스크립트 등 응용 프로그램 일관성을 보장할 도구가 필요합니다.
백업: 다른 스토리지로 데이터를 이동
- vzdump: 로
.vma.zst파일을 만들거나 PBS로 증분 블록을 전송합니다. - NAS (NFS/SMB): Proxmox에서 많이 쓰는 네트워크 백업 저장소입니다. 가능하면 하이퍼바이저와 전원/네트워크 경로를 분리해 같은 사고로 함께 손상되지 않게 두십시오.
- 백업이 끝났다고 끝이 아니라, 주기적인
proxmox-backup-client verify또는 복구 테스트가 필요합니다. - PBS 증분 백업은 모든 이전 백업 체인에 의존하므로, 풀 백업과 증분 백업 파일 전체를 보호해야 합니다.
실무 기준으로는 VM마다 마지막 스냅샷 1~2개, 백업은 최소 일 1회를 기본선으로 두고, SLA가 더 빡빡한 워크로드만 추가 백업을 붙입니다.
오프호스트 백업 타깃 선택 순서
- 외장 SSD/HDD (오프라인/회전 보관): Proxmox 호스트 USB에 연결해
Directory타입으로 마운트합니다. 백업이 끝나면 분리해 다른 장소에 보관하면 “오프라인”/“오프사이트” 조건을 동시에 만족시킬 수 있습니다. 같은 책상 위에 두면 여전히 동일 사고 범위입니다. - NAS (NFS/SMB): Synology, TrueNAS, Unraid 등으로 별도 스토리지를 구성하고
Datacenter > Storage > Add > NFS/SMB에서 연결합니다. NAS는 별도 전원·디스크를 갖지만, 동일 멀티탭/UPS에 꽂혀 있으면 번개·정전으로 동시에 날아갈 수 있습니다. - Proxmox Backup Server: 추가 미니 PC나 x86 박스에 PBS ISO를 설치하고, 초기 셋업 후
Datacenter > Storage > Add > Proxmox Backup Server에서 API URL과 인증서를 등록합니다. 이후 VM 백업 작업을 PBS 대상으로 돌리면 증분, 중복제거, 무결성 점검이 자동화됩니다.
선택 요령은 백업을 망가뜨릴 수 있는 사람·사고의 범위를 운영 호스트와 겹치지 않게 분리하는 것입니다. NAS라면 최소한 다른 방, 다른 멀티탭(또는 별도 UPS)에 연결하고, PBS라면 관리 계정과 암호화 키를 별도 장소에 보관해 “백업 서버 + 키 동시 손실”을 막습니다.
복구를 설계하는 단계별 체크리스트
- 중요 워크로드 우선순위: “Reverse Proxy > App > DB > Windows 테스트”처럼 재가동 순서를 정하고 RTO/RPO를 붙입니다.
- 스토리지 타입 기록: LVM-Thin, ZFS, Ceph를 구분해둬야 복구 시 같은 타입으로 되돌릴지, 변환이 필요한지 판단이 쉽습니다.
- 스냅샷 정책: “앱 서버는 배포 전 수동 스냅샷 1개 유지”, “테스트 VM은 자동 스냅샷 금지”처럼 체인 길이와 보유 기간을 제한합니다.
- 백업 일정 + 보존 주기:
Datacenter > Backup또는 PBS 스케줄에서 주기(예: 매일 02), 보존(예: 7일), 모드(stop/snapshot)를 명시합니다. - 검증 & 드라이 런: 분기마다 최신 백업을 새 VM ID에 복구해 부팅/헬스체크까지 완료하고, 실제 복구에 걸린 시간을 기록합니다.
예시 체크리스트를 간단한 표로 남기면 대응 속도가 빨라집니다.
| 워크로드 | 스토리지 | 스냅샷 정책 | 백업 일정 | 목표 RTO/RPO | 마지막 드라이 런 |
|---|---|---|---|---|---|
| reverse-proxy | LVM-Thin | 배포 전 수동 1개 | PBS 매일 02, 7일 보존 | 30분 / 24시간 | 2026-03-10 (22분) |
| app-server | LVM-Thin | 주 1회 수동 | PBS 매일 02, 14일 보존 | 60분 / 24시간 | 2026-03-10 (35분) |
| monitoring | LXC-Dir | 스냅샷 없음 | NAS 주 1회, 4주 보존 | 120분 / 72시간 | 2026-02-25 (40분) |
로컬 스토리지와 외부 스토리지를 조합하는 방법
1. 단일 NVMe + 외장 HDD (회전 보관)
- 운영 디스크: NVMe
local-lvm - ISO/템플릿: NVMe
local - 백업: USB 외장 HDD
Directory(백업 후 분리) - 장점: 초기 비용이 최소, 구성 단순
- 단점: 디스크를 매번 분리하지 않으면 여전히 동일 사고 범위, 수동 작업 필요
2. NVMe + SATA SSD + NAS
- 운영 디스크: NVMe LVM-Thin
- ISO/템플릿: SATA SSD
Directory - 백업: NAS NFS share
- 장점: 운영/미디어/백업이 서로 다른 물리 매체, NAS를 다른 방에 둘 수 있음
- 단점: NAS 비용과 네트워크 배선 필요
3. NVMe + PBS
- 운영 디스크: NVMe ZFS mirror (가능하다면) 또는 NVMe LVM-Thin
- 백업: 별도 미니 PC에 PBS 설치, 2.5" SSD 혹은 HDD 장착
- 장점: 증분 백업, 무결성 검증, 특정 VM만 빠르게 복구
- 단점: PBS 장비와 디스크 추가, 네트워크 2.5GbE 이상이면 효과 극대화
구성 선택은 예산과 공간에 따라 달라지지만, 운영 스토리지와 백업 스토리지가 물리적으로 분리되어 있는가만큼은 반드시 체크해야 합니다.
흔한 실수와 예방 팁
- 씬 풀을 90% 이상 채우기: LVM-Thin은 데이터 풀뿐 아니라 메타데이터 풀이 먼저 고갈될 수 있습니다.
Datacenter > Storage > local-lvm또는lvs -o+metadata_percent vg/lv명령으로 두 사용률을 모두 모니터링하고, 80% 근처에서 확장 또는 불필요한 스냅샷/ISO를 삭제합니다. - NAS를 단일 계정으로 공유: 백업용 공유는 읽기/쓰기 권한을 최소화하고, 일반 사용자 계정으로 재사용하지 않습니다. 랜섬웨어나 실수 삭제에 대비합니다.
- PBS를 운영 호스트와 같은 전원에 두기: 전원 분리와 UPS 구성 여부를 체크합니다. 특히 정전 시 동시에 꺼지면 장점이 사라집니다.
- 복구 테스트를 미루기: 최소 연 1회(가능하면 분기별) 실제 복구 과정을 밟아 보고, 예상보다 오래 걸리는 단계(예: NAS에서 복사 속도, PBS 검증 시간, 증분 체인 검증)를 기록합니다.
- 백업 실패 알림을 두지 않기:
Datacenter > Backup작업 로그, PBS 리포트, 혹은 외부 모니터링으로 실패 시 알림을 받아야 합니다. 실패 로그를 주간 점검 항목에 넣습니다.
마무리
스토리지를 제대로 나누고 스냅샷·백업·복구를 각각의 도구로 바라보는 순간, Proxmox 환경은 실험실을 넘어 운영 가능한 인프라로 변합니다. 로컬 SSD는 워크로드 성능을 책임지고, NAS나 PBS는 장비 손실에도 견디는 복구 지점을 제공합니다. 다음 글에서는 여기서 확보한 스토리지 기반을 토대로, 남는 미니 PC나 중고 하드웨어를 묶어 실제 self-hosted 웹 인프라를 구성하는 전체 흐름을 살펴보겠습니다.
💬 댓글
이 글에 대한 의견을 남겨주세요