13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[카테고리:] proxmox

  • [Proxmox VE] VM 백업 및 복구 완벽 가이드: 데이터 손실 방지 전략

    [Proxmox VE] VM 백업 및 복구 완벽 가이드: 데이터 손실 방지 전략

    목차

    [Proxmox VE] VM 백업 및 복구 완벽 가이드: 데이터 손실 방지 전략

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 Proxmox VE(Virtual Environment) 환경에서 VM(Virtual Machine) 백업과 복구에 대한 이야기를 좀 해볼까 합니다. 서버실에서 13년을 굴러보니, 데이터만큼 중요한 게 없더라고요. 한 번의 실수로 데이터가 날아가면 정말 아찔하죠. 특히 홈랩(Home Lab)을 운영하면서 이것저것 실험하다 보니 백업의 중요성을 뼈저리게 느끼게 됩니다. 😱

    저도 예전에 백업을 소홀히 했다가 중요한 설정 파일이나 프로젝트 데이터가 통째로 날아간 경험이 있거든요. 그때의 허탈함이란… 그래서 Proxmox VE VM 백업은 선택이 아니라 필수라고 항상 강조합니다. 오늘은 제가 직접 홈랩에서 Proxmox를 운영하며 겪었던 경험을 바탕으로, 어떻게 하면 안전하게 Proxmox 백업을 설정하고, 위기 상황에서 VM 복구를 할 수 있는지, 그 데이터 손실 방지 전략을 완벽하게 알려드릴게요. 저와 함께 Proxmox 스냅샷을 포함한 다양한 데이터 보호 방법을 알아봅시다!

    Proxmox VE VM 백업 및 복구 전체 아키텍처 다이어그램

    Proxmox 백업, 진짜 왜 중요할까요? (개념 설명)

    쉽게 말해, Proxmox VE 환경에서 VM 백업은 우리 집의 귀한 물건들을 금고에 넣어두는 것과 같습니다. 언제든 문제가 생기면 금고에서 다시 꺼내 쓸 수 있도록 말이죠. Proxmox는 기본적으로 아주 강력한 백업 기능을 제공하고 있거든요.

    VZDump: Proxmox의 핵심 백업 도구

    Proxmox에는 vzdump라는 백업 툴이 내장되어 있습니다. 이 툴로 VM(QEMU/KVM)과 LXC 컨테이너를 효율적으로 백업할 수 있거든요. 백업 시점에 VM의 모든 상태(디스크 이미지, 설정 파일 등)를 하나의 파일로 만들어주고, 나중에 복구할 때 사용하죠.

    스냅샷(Snapshot)과 백업(Backup)의 차이

    여기서 많은 분들이 헷갈리시는 게 스냅샷과 백업입니다. 저도 처음엔 이게 뭔가 싶었거든요. 간단히 비유하자면:

    • 스냅샷(Snapshot): 책갈피 같은 거예요. 특정 시점의 VM 상태를 빠르게 저장하고, 문제가 생겼을 때 그 시점으로 되돌아갈 수 있게 해줍니다. 하지만 스냅샷은 원본 VM과 같은 스토리지에 존재하기 때문에, 스토리지 자체가 손상되면 스냅샷도 같이 날아갈 위험이 있어요.
    • 백업(Backup): 책 전체를 복사해서 다른 안전한 장소에 보관하는 거라고 생각하시면 됩니다. 원본 VM과는 완전히 분리된 별도의 백업 스토리지에 저장되므로, 원본 VM이 손상되더라도 안전하게 복구할 수 있죠.

    결론적으로, 스냅샷은 빠른 롤백(Rollback)에 좋고, 백업은 데이터 손실 방지와 재해 복구(Disaster Recovery, DR)에 필수적입니다.

    어떤 백업 스토리지를 사용할까?

    Proxmox는 다양한 백업 스토리지를 지원하거든요. 제가 홈랩에서 주로 쓰는 방식은 NFS(Network File System)나 SMB/CIFS(Server Message Block/Common Internet File System) 공유 스토리지를 사용하는 겁니다. 아니면 Proxmox Backup Server(PBS)를 구축해서 쓰는 방법도 있는데, 이건 정말 끝판왕이라고 할 수 있죠.

    Proxmox VE VM 백업 및 복구 실전 구현 (단계별 가이드)

    자, 이제 실전입니다. 제가 직접 쓰는 방법들을 단계별로 보여드릴게요. Proxmox 웹 GUI를 주로 활용하겠지만, CLI(Command Line Interface) 명령어 몇 가지도 함께 알아두시면 좋습니다.

    1단계: 백업 스토리지 추가하기 (NFS 예시)

    가장 먼저 백업 파일을 저장할 공간을 Proxmox에 연결해야 합니다. 저는 NAS(Network Attached Storage)에 NFS 공유 폴더를 만들어서 사용하고 있거든요.

    1. Proxmox 웹 GUI에 접속합니다.
    2. 좌측 메뉴에서 Datacenter > Storage로 이동합니다.
    3. Add 버튼을 클릭하고 NFS를 선택합니다.

    4. 다음 정보를 입력합니다:

      • ID: backup-nfs (원하는 이름)
      • Server: 192.168.1.100 (NAS IP 주소)
      • Export: /volume1/proxmox-backup (NAS의 NFS 공유 경로)
      • Content: VZDump backup file (필수!)
    5. Add 버튼을 눌러 추가를 완료합니다.

    CLI로 직접 마운트하는 방법도 있어요. 예를 들어, /etc/fstab에 추가해서 부팅 시 자동 마운트되도록 설정할 수 있습니다.

    
# /etc/fstab
192.168.1.100:/volume1/proxmox-backup /mnt/pve/backup-nfs nfs defaults 0 0

    그리고 mount -a 명령어로 바로 적용해줍니다. 그 후 Proxmox GUI에서 Storage를 추가하면 되는데, 이 방법이 좀 더 안정적이더라고요.

    Proxmox VE 웹 GUI 백업 작업 설정 화면

    2단계: 백업 작업 생성 및 스케줄링

    스토리지를 연결했으니 이제 Proxmox 백업 작업을 만들어볼까요?

    1. Datacenter > Backup으로 이동합니다.
    2. Add 버튼을 클릭하여 새 백업 작업을 생성합니다.

    3. 백업 설정:

      • Node: 백업할 VM이 있는 Proxmox 노드 선택 (All도 가능)
      • Storage: 1단계에서 추가한 backup-nfs 선택
      • Schedule: Daily (매일), Weekly (매주) 등 원하는 주기로 설정합니다. 저는 새벽 2시에 매일 돌리도록 설정해놓았어요.
      • VMs: 백업할 VM 선택 (All 또는 특정 VM ID)
      • Mode: Snapshot (가장 권장하는 방식입니다. VM 운영 중에도 백업 가능)
      • Compression: Zstd (최신 알고리즘으로 압축률과 속도 모두 좋습니다)
      • Email notification: 백업 결과 알림을 받을 이메일 주소 설정 (필수!)
      • Retention: 백업본 유지 기간. 저는 보통 7일로 설정해서 일주일치 백업본을 가지고 있습니다.
    4. Create 버튼을 눌러 백업 작업을 완료합니다.

    이렇게 하면 설정한 스케줄에 따라 자동으로 Proxmox VE VM 백업이 진행돼요. 정말 편하더라고요!

    3단계: VM 복구하기

    불의의 사고로 VM이 날아갔다거나, 특정 시점으로 되돌리고 싶을 때 VM 복구는 필수입니다. Proxmox는 복구도 아주 간단하게 할 수 있게 해줍니다.

    1. 좌측 메뉴에서 Datacenter > Storage > backup-nfs (백업 스토리지를 선택)로 이동합니다.
    2. 중앙 패널에서 백업된 파일 목록을 볼 수 있어요. 복구하려는 VM의 백업 파일을 선택합니다.
    3. Restore 버튼을 클릭합니다.

    4. 복구 설정:

      • Target Storage: VM이 복구될 스토리지 선택 (예: local-lvm)
      • VM ID: 새 VM ID를 지정하거나, 기존 VM ID로 덮어쓸 수 있습니다. 기존 ID로 덮어쓸 경우 기존 VM은 삭제되니 주의하세요!
      • Start after restore: 복구 완료 후 바로 VM을 시작할지 여부
    5. Restore 버튼을 눌러 복구를 시작합니다.

    CLI로 복구하는 방법도 있어요. 만약 웹 GUI에 접근할 수 없는 상황이라면 유용하겠죠?

    
# 백업 파일 경로 확인 (예: /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2023_10_26-02_00_01.vma.zst)
# 새 VM ID 101로 복구 (기존 VM ID와 겹치지 않게)
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2023_10_26-02_00_01.vma.zst 101 --storage local-lvm

# 만약 기존 VM ID 100에 덮어쓰려면 (기존 VM 삭제 후)
# qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2023_10_26-02_00_01.vma.zst 100 --storage local-lvm --force

    --force 옵션은 기존 VM을 삭제하고 복구하는 거라서 정말 신중하게 사용해야 합니다!

    ⚠️ 주의사항 및 트러블슈팅: 삽질 경험 공유

    제가 13년 동안 삽질하면서 배웠던 Proxmox 데이터 보호에 대한 몇 가지 팁과 주의사항을 공유합니다. 홈랩이든 실제 서버든 똑같더라고요.

    백업 스토리지 용량 부족

    저도 처음엔 무작정 백업 돌렸다가 백업 스토리지가 꽉 차서 난리 났었죠. 😅 정기적으로 백업 스토리지 용량을 확인하고, Retention 정책을 잘 설정해서 오래된 백업본은 자동으로 삭제되도록 해야 합니다. 아니면 Proxmox Backup Server(PBS)를 쓰면 중복 제거(Deduplication) 기능 덕분에 용량 효율이 훨씬 좋아지더라고요. 이건 나중에 기회가 되면 더 자세히 다뤄볼게요.

    백업 일관성 (Consistency) 문제

    Snapshot 모드로 백업하면 VM이 실행 중인 상태에서 백업이 이루어지기 때문에 편리해요. 하지만 이 방식은 파일 시스템 일관성(Filesystem-consistent)은 보장하지만, 애플리케이션 일관성(Application-consistent)은 보장하지 못할 수 있거든요. 예를 들어, 데이터베이스 서버 같은 경우 백업 시점에 트랜잭션이 진행 중이었다면, 복구 후 데이터베이스에 문제가 생길 수도 있습니다. 중요한 서비스라면 백업 전에 잠시 서비스를 중단하거나, VM 내부에서 VSS(Volume Shadow Copy Service) 등을 활용하는 방법을 고려해야 합니다.

    네트워크 대역폭과 복구 시간

    백업이나 복구 시 네트워크 대역폭이 충분하지 않으면 시간이 오래 걸릴 수 있어요. 특히 대용량 VM을 복구할 때는 정말 답답하더라고요. 10GbE(기가비트 이더넷) 같은 고속 네트워크를 구축해두면 훨씬 쾌적합니다.

    VM ID 충돌

    복구 시 새 VM ID를 지정하지 않고, 이미 사용 중인 ID로 복구하려고 하면 에러가 발생해요. qmrestore 명령어를 쓸 때는 반드시 기존에 사용하지 않는 VM ID를 지정하거나, 정말 덮어써야 할 경우에만 --force 옵션을 사용해야 합니다.

    백업 및 복구 결과 확인 (검증)

    백업이 잘 됐는지, 복구된 VM이 제대로 작동하는지 확인하는 게 진짜 중요해요. 저는 예전에 백업은 잘 했는데, 복구 테스트를 안 해봤다가 나중에 문제가 생겨서 애먹었던 적이 있거든요. 백업만큼이나 복구 검증도 필수입니다!

    1. 백업 로그 확인: Proxmox 웹 GUI의 Datacenter > Task Log에서 백업 작업의 성공 여부를 확인할 수 있습니다. 오류가 발생했다면 로그를 자세히 살펴보세요.
    2. 복구된 VM 정상 작동 확인: 복구된 VM을 시작하고, 서비스가 정상적으로 올라오는지, 네트워크 연결은 잘 되는지, 데이터는 모두 유효한지 꼼꼼히 확인해야 합니다. 가능하다면 주기적으로 복구 테스트를 진행해보는 게 좋습니다.

    Proxmox VE 백업 작업 로그 및 성공 기록 확인 화면

    Proxmox 백업 모드별 장단점 비교

    Proxmox에서 VM 백업 시 선택할 수 있는 주요 모드들의 장단점을 정리해봤습니다. 어떤 상황에 어떤 모드를 쓰는 게 좋을지 판단하는 데 도움이 되실 거예요.

    백업 모드 (Mode) 설명 장점 단점
    Snapshot VM이 실행 중인 상태에서 스냅샷을 찍고 백업합니다. VM 서비스 중단 없음, 가장 편리함. 애플리케이션 일관성 보장 어려움, 스냅샷 생성/삭제 오버헤드.
    Suspend VM을 잠시 일시 중지(Suspend)한 후 백업합니다. 파일 시스템 일관성 보장, 스냅샷보다 안전. VM 서비스가 잠시 중단됨 (수 초 ~ 수십 초).
    Stop VM을 완전히 중지(Stop)한 후 백업합니다. 가장 높은 데이터 일관성 보장. VM 서비스가 백업 시간 동안 완전히 중단됨.

    대부분의 홈랩이나 중요도가 아주 높지 않은 서비스는 Snapshot 모드로도 충분해요. 하지만 금융 시스템처럼 데이터 일관성이 절대적으로 중요한 곳에서는 Stop 모드를 고려하거나, VM 내부에서 정교한 백업 스크립트를 돌려야 하겠죠.

    Proxmox VE 백업 모드별 장단점 비교 인포그래픽

    마무리: 데이터 보호는 기본 중의 기본입니다!

    오늘은 Proxmox VE 환경에서 VM 백업 및 복구에 대해 자세히 알아봤습니다. 제가 13년간 서버실에서 일하며 느낀 점은, 기술이 아무리 발전해도 데이터 보호의 중요성은 변치 않는다는 거예요. 백업은 주기적으로, 복구는 빠르게! 이 두 가지 원칙만 잘 지키면 소중한 데이터를 안전하게 지킬 수 있습니다.

    오늘 다룬 내용이 여러분의 Proxmox 환경 데이터 보호 전략을 세우는 데 큰 도움이 되었기를 바랍니다. 다음번에는 Proxmox Backup Server(PBS)를 활용한 더 강력한 백업 전략이나, Proxmox 클러스터 구성에 대한 이야기로 찾아올게요. 혹시 궁금한 점이나, 제가 겪었던 삽질 경험 중 더 듣고 싶은 이야기가 있다면 언제든 댓글로 남겨주세요! 😊

  • [Proxmox] Proxmox 백업 자동화 완벽 가이드: PBS 및 스케줄 백업 활용

    목차

    백업 없이 운영하다가 날린 VM, 그 뼈아픈 경험 이야기

    솔직하게 고백하자면, 저도 한 번 날린 적 있습니다. 홈랩에서 열심히 세팅해 둔 VM(가상 머신) 하나가 스토리지 장애로 그냥 사라져버렸거든요. 백업? 당연히 없었죠. ‘홈랩인데 뭐 어때’ 라고 생각했던 게 화근이었습니다. 그 이후로 저는 Proxmox 백업 자동화를 진지하게 구축하기 시작했고, 지금은 매일 밤 자동으로 백업이 돌아가는 걸 보면서 마음이 편안해지는 사람이 됐습니다 ㅎㅎ.

    이 글은 Proxmox VE(Virtual Environment)를 운영하면서 Proxmox 백업 자동화를 아직 제대로 구성하지 못하신 분들을 위한 실전 가이드입니다. PBS(Proxmox Backup Server)를 활용한 자동화 방법부터, 스케줄 백업 설정, 그리고 실제 운영에서 겪은 삽질까지 전부 공유해 드릴게요.

    ▲ Proxmox VE와 PBS(Proxmox Backup Server)가 연동된 전체 백업 아키텍처 구성도. VM과 CT(컨테이너)가 PBS로 자동 백업되는 흐름을 보여줍니다.

    Proxmox 백업의 두 가지 방식: 어떤 걸 써야 할까?

    Proxmox VE에서 백업을 설정할 때 처음에 헷갈리는 게 바로 이 부분이에요. 백업 저장소를 어디로 잡느냐에 따라 Proxmox 백업 자동화 방식이 완전히 달라지거든요.

    구분 로컬/NFS/CIFS 백업 PBS(Proxmox Backup Server) 백업
    저장 방식 전체 이미지 파일 (.vma) 증분 백업 (변경분만 저장)
    중복 제거 ❌ 없음 ✅ 청크 기반 중복 제거
    암호화 제한적 ✅ 클라이언트 사이드 암호화 지원
    복원 속도 보통 빠름 (증분 복원 가능)
    스토리지 효율 낮음 매우 높음
    구축 난이도 쉬움 중간 (별도 서버 필요)

    쉽게 말해서, 로컬 백업은 간단하지만 디스크를 많이 잡아먹고, PBS는 증분 백업과 중복 제거 덕분에 같은 공간에 훨씬 많은 백업 포인트를 유지할 수 있어요. 홈랩이라 스토리지가 넉넉하지 않다면 PBS가 훨씬 유리합니다.

    저는 처음에 NFS 공유 폴더에 그냥 백업했다가, 한 달도 안 돼서 디스크가 꽉 차는 걸 경험했거든요. 그 이후로 Proxmox Backup Server로 갈아탔고, 같은 공간에 훨씬 오래된 백업 포인트를 유지할 수 있게 됐습니다.

    PBS(Proxmox Backup Server) 설치 및 초기 설정

    PBS는 Proxmox VE와는 별도의 소프트웨어입니다. 전용 ISO를 받아서 별도 머신(물리 서버든, VM이든)에 설치하는 게 기본이에요. 저는 홈랩에서 오래된 미니 PC 한 대를 PBS 전용으로 쓰고 있습니다.

    1단계: PBS 설치

    Proxmox 공식 사이트(proxmox.com)에서 PBS ISO를 다운받아서 설치하면 됩니다. 설치 과정은 Proxmox VE와 거의 동일해서 어렵지 않아요. 설치 후 웹 UI는 기본적으로 https://[PBS-IP]:8007로 접속합니다.

    2단계: 데이터스토어(Datastore) 생성

    PBS에서 백업이 실제로 저장되는 공간을 데이터스토어라고 부릅니다. 웹 UI에서 만들 수도 있고, CLI로도 만들 수 있어요.

    # PBS 서버에서 실행
# /mnt/backup-pool 디렉토리를 데이터스토어로 생성
proxmox-backup-manager datastore create main /mnt/backup-pool

# 생성된 데이터스토어 목록 확인
proxmox-backup-manager datastore list

    3단계: 사용자 및 토큰 생성 (API Token)

    Proxmox VE가 PBS에 접속할 때 사용할 API 토큰을 만들어야 합니다. 보안상 root 계정 대신 전용 사용자를 만드는 걸 권장해요.

    # PBS 서버에서 실행
# 백업 전용 사용자 생성
proxmox-backup-manager user create backup-user@pbs --password 'YourSecurePassword'

# 데이터스토어에 대한 권한 부여 (DatastoreBackup 역할)
proxmox-backup-manager acl update /datastore/main --auth-id 'backup-user@pbs' --role DatastoreBackup

# API 토큰 생성
proxmox-backup-manager user generate-token backup-user@pbs mytoken

    ⚠️ 중요! 토큰 값은 생성 시 한 번만 표시되니까 반드시 메모해 두세요. 저도 처음에 그냥 닫았다가 다시 만들었거든요 ㅎㅎ.

    Proxmox VE에 PBS 스토리지 연결하기

    이제 Proxmox VE 쪽에서 PBS를 백업 저장소로 등록해야 합니다.

    웹 UI로 연결하는 방법

    1. Proxmox VE 웹 UI 접속 → Datacenter 선택
    2. 왼쪽 메뉴에서 Storage 클릭
    3. Add 버튼 → Proxmox Backup Server 선택
    4. PBS 서버 IP, 포트(8007), 앞서 만든 사용자명과 토큰 값 입력
    5. 데이터스토어 이름 입력 후 저장

    CLI로 연결하는 방법

    # Proxmox VE 노드에서 실행
# PBS 스토리지를 /etc/pve/storage.cfg에 추가
pvesm add pbs pbs-backup \
  --server 192.168.1.100 \
  --datastore main \
  --username backup-user@pbs \
  --token mytoken \
  --tokenid 'backup-user@pbs!mytoken'

# 연결 확인
pvesm status

    연결이 성공하면 Proxmox VE 스토리지 목록에 PBS가 표시됩니다. 여기서 핑거프린트(Fingerprint) 불일치 오류가 나는 경우가 있는데, 이건 아래 트러블슈팅 섹션에서 다룰게요.

    ▲ Proxmox VE 웹 UI에서 PBS 스토리지를 연결하고 백업 작업을 설정하는 화면. Storage 메뉴에서 Proxmox Backup Server 타입을 선택해 연동합니다.

    Proxmox 스케줄 백업 설정: 자동화의 핵심

    이제 진짜 핵심입니다. 수동으로 백업 버튼 누르는 건 언젠가 반드시 까먹게 되어 있어요. Proxmox 스케줄 백업을 설정해두면 정해진 시간에 알아서 백업이 돌아갑니다.

    백업 작업(Backup Job) 생성

    Proxmox VE 웹 UI에서 Datacenter → Backup 메뉴로 이동하면 백업 작업을 만들 수 있어요.

    1. Add 버튼 클릭
    2. 노드(Node), 스토리지(Storage, 아까 연결한 PBS 선택), VM 선택
    3. 스케줄(Schedule) 설정
    4. 백업 모드(Mode) 선택
    5. 보존 정책(Retention) 설정

    스케줄 문법 이해하기

    Proxmox의 스케줄은 systemd 타이머 문법을 사용합니다. 처음엔 낯설 수 있는데, 익숙해지면 굉장히 직관적이에요.

    # 자주 쓰는 스케줄 예시
daily          # 매일 00:00
daily 02:00    # 매일 새벽 2시
weekly         # 매주 월요일 00:00
monthly        # 매월 1일 00:00
sat 03:00      # 매주 토요일 새벽 3시
*/2:00         # 2시간마다

# CLI로 백업 작업 생성 예시
pvesh create /cluster/backup \
  --storage pbs-backup \
  --schedule 'daily 02:00' \
  --mode snapshot \
  --vmid 100,101,102 \
  --mailnotification always \
  --mailto '[email protected]'

    백업 모드(Mode) 선택 기준

    • Snapshot 모드: VM이 실행 중인 상태에서 백업. 서비스 중단 없음. 가장 많이 씀.
    • Suspend 모드: 백업 중 VM을 일시 정지. 데이터 일관성이 높지만 잠깐 서비스 중단.
    • Stop 모드: VM을 완전히 끄고 백업. 가장 안전하지만 다운타임 발생.

    💡 팁: 데이터베이스가 돌아가는 VM이라면 Snapshot 모드만으로는 데이터 일관성이 보장되지 않을 수 있어요. 이 경우 QEMU Guest Agent를 설치하면 스냅샷 전에 파일시스템을 freeze(동결)해줘서 훨씬 안전합니다.

    보존 정책(Retention Policy) 설정

    백업을 얼마나 오래 보관할지 정하는 게 보존 정책입니다. PBS에서는 굉장히 세밀하게 설정할 수 있어요.

    # PBS 데이터스토어에 보존 정책 설정
proxmox-backup-manager datastore update main \
  --keep-last 3 \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3

# 위 설정의 의미:
# keep-last 3   : 최신 백업 3개는 무조건 보관
# keep-daily 7  : 일별 백업을 7일치 보관
# keep-weekly 4 : 주별 백업을 4주치 보관
# keep-monthly 3: 월별 백업을 3개월치 보관

    이 설정 덕분에 같은 스토리지 공간으로 훨씬 오랜 기간의 백업 히스토리를 유지할 수 있습니다. 증분 백업 + 중복 제거 + 보존 정책, 이 세 가지가 Proxmox Backup Server의 핵심 강점이에요.

    ⚠️ 실제로 겪은 트러블슈팅 모음

    이론은 이론이고, 실제로 설정하다 보면 별의별 문제가 다 생기더라고요. 제가 겪은 것들을 공유합니다.

    문제 1: 핑거프린트(Fingerprint) 불일치 오류

    PBS 스토리지를 추가할 때 이런 오류가 나는 경우가 있어요.

    TASK ERROR: fingerprint 'XX:XX:...' does not match

    PBS 서버에서 핑거프린트를 직접 확인해서 Proxmox VE 설정에 넣어주면 해결됩니다.

    # PBS 서버에서 실행
proxmox-backup-manager cert info | grep Fingerprint

# 출력된 핑거프린트를 복사해서
# Proxmox VE의 스토리지 설정에 fingerprint 항목에 붙여넣기

    문제 2: 백업 중 ‘lock timeout’ 오류

    VM 여러 개를 동시에 백업할 때 간혹 발생합니다. 기본적으로 Proxmox는 VM당 하나의 백업만 허용하는데, 이전 백업이 비정상 종료되면 락(Lock) 파일이 남아있을 수 있어요.

    # 특정 VM의 락 파일 확인 (VM ID 100 예시)
ls /run/lock/qemu-server/lock-100.conf

# 락 파일 제거 (백업이 실제로 안 돌아가고 있을 때만!)
rm /run/lock/qemu-server/lock-100.conf

    문제 3: 스냅샷 백업 시 디스크 공간 부족

    Snapshot 모드로 백업할 때 임시 스냅샷을 위한 여유 공간이 필요합니다. 스토리지가 꽉 차있으면 백업이 실패해요. 저장소에 최소 20% 정도 여유 공간을 확보해 두는 게 좋습니다.

    문제 4: PBS 가비지 컬렉션 미실행으로 인한 공간 낭비

    PBS에서 오래된 백업을 삭제해도 실제 디스크 공간이 바로 회수되지 않아요. 가비지 컬렉션(Garbage Collection)을 주기적으로 실행해야 합니다.

    # PBS 서버에서 가비지 컬렉션 수동 실행
proxmox-backup-manager garbage-collection start main

# 스케줄 설정 (매주 일요일 새벽 4시)
proxmox-backup-manager datastore update main \
  --gc-schedule 'sun 04:00'

    저도 이걸 몰라서 한동안 PBS 디스크가 예상보다 빨리 차는 걸 보고 의아했었는데, 가비지 컬렉션 설정하고 나서 해결됐습니다.

    ▲ PBS 웹 대시보드에서 백업 작업 현황, 스토리지 사용량, 보존 정책 적용 결과를 한눈에 확인할 수 있습니다.

    백업 검증: 백업했다고 끝이 아닙니다

    이게 진짜 중요한데 많이들 놓치는 부분이에요. 백업은 복원이 되어야 의미가 있습니다. 백업 파일이 존재한다는 것과, 그 백업으로 실제로 복원이 된다는 건 다른 얘기거든요.

    백업 무결성 검증 (Verify)

    PBS는 백업 데이터의 무결성을 검증하는 기능을 내장하고 있습니다.

    # PBS 서버에서 특정 데이터스토어 검증
proxmox-backup-manager verify-job create \
  --store main \
  --schedule 'weekly' \
  --ignore-verified true \
  --outdated-after 30

# 수동 검증 실행
proxmox-backup-manager verify-job run verify-job-id

    복원 테스트

    저는 분기에 한 번씩은 실제로 VM을 복원해보는 테스트를 합니다. Proxmox VE 웹 UI에서는 간단하게 할 수 있어요.

    1. Proxmox VE 웹 UI → 해당 노드 → PBS 스토리지 선택
    2. 복원하고 싶은 백업 포인트 선택
    3. Restore 버튼 클릭
    4. 복원할 VM ID와 스토리지 지정 후 실행

    CLI로도 복원할 수 있습니다.

    # VM 백업 복원 (VM ID 100, 새 VM ID 200으로 복원)
qmrestore pbs-backup:vm/100/2024-01-15T02:00:00Z 200 \
  --storage local-lvm \
  --force

# CT(LXC 컨테이너) 백업 복원
pct restore 201 pbs-backup:ct/101/2024-01-15T02:00:00Z \
  --storage local-lvm \
  --force

    VM 백업 전략: 어떻게 구성하면 좋을까?

    마지막으로 제가 실제로 운영 중인 VM 백업 전략을 공유할게요. 홈랩 기준이지만 소규모 운영 환경에도 참고하실 수 있을 거예요.

    ▲ VM 중요도에 따라 차등화된 백업 전략 인포그래픽. 중요 서비스는 매일, 개발/테스트 VM은 주 단위로 백업 주기를 다르게 설정합니다.

    제가 쓰는 3-2-1 백업 전략

    • 3: 데이터 복사본 3개 유지
    • 2: 2가지 다른 미디어/스토리지에 저장
    • 1: 1개는 오프사이트(다른 물리적 위치)에 보관

    홈랩에서 완전한 3-2-1을 구현하기 어렵다면, 최소한 PBS 백업 + 외장 하드 또는 클라우드 스토리지(B2, S3 등)에 추가 백업을 유지하는 것을 권장합니다.

    VM 중요도별 백업 주기

    • 중요 서비스 VM (홈서버, NAS 등): 매일 새벽 2시, 7일치 보관
    • 일반 서비스 VM: 매일 새벽 3시, 3일치 보관
    • 개발/테스트 VM: 주 1회, 2주치 보관

    마무리: 백업은 습관입니다

    여기까지 따라오셨다면, 이제 Proxmox 백업 자동화의 기본 틀은 완성됐습니다. 🎉

    정리하자면:

    • ✅ PBS를 설치하고 Proxmox VE와 연동했습니다
    • ✅ 증분 백업과 중복 제거로 스토리지를 효율적으로 사용합니다
    • ✅ 스케줄 백업으로 매일 자동으로 백업이 돌아갑니다
    • ✅ 보존 정책으로 오래된 백업을 자동 정리합니다
    • ✅ 검증과 복원 테스트로 백업의 신뢰성을 확인합니다

    백업은 한 번 설정했다고 끝이 아니에요. 주기적으로 백업이 제대로 돌아가고 있는지, 복원은 실제로 되는지 확인하는 습관이 중요합니다. 저도 매월 PBS 대시보드를 한 번씩 들여다보고, 분기에 한 번은 복원 테스트를 하고 있어요.

    다음 글에서는 Proxmox VE 클러스터 구성과 고가용성(HA) 설정에 대해 다룰 예정입니다. PBS 백업이 잘 되어 있으면 클러스터 구성도 훨씬 마음 편하게 할 수 있거든요. 기대해주세요!

    혹시 설정하다가 막히는 부분이 있으시면 댓글로 남겨주세요. 같이 해결해봐요 😊

    자주 묻는 질문 (FAQ)

    Q. PBS 서버는 반드시 별도 물리 서버여야 하나요?

    꼭 그렇지는 않습니다. Proxmox VE 위에 VM으로 PBS를 올릴 수도 있어요. 다만 해당 노드가 장애가 나면 백업 서버도 같이 다운된다는 단점이 있어서, 가능하면 별도 머신을 추천합니다.

    Q. 백업 중 VM 성능이 저하되나요?

    Snapshot 모드는 백업 중 성능 영향이 거의 없습니다. 다만 스토리지 I/O는 백업 중 증가할 수 있어요. 그래서 새벽 시간대에 스케줄을 잡는 게 좋습니다.

    Q. PBS 없이 로컬 백업만으로 충분하지 않나요?

    단순한 환경이라면 로컬 백업도 괜찮습니다. 하지만 VM이 5개 이상이거나, 스토리지 공간이 넉넉하지 않다면 Proxmox Backup Server의 증분 백업과 중복 제거 기능이 확실히 유리합니다.

  • [Proxmox] Proxmox VE Ceph 클러스터 구축 및 관리 완벽 가이드

    목차

    홈랩에 엔터프라이즈급 스토리지를? Proxmox Ceph 클러스터 도전기

    솔직히 말씀드리면, 처음 Proxmox VE에서 Ceph 클러스터를 구축하려고 했을 때 겁부터 먹었습니다. “분산 스토리지”라는 단어 자체가 주는 무게감이 있잖아요. 대기업 IDC에서나 쓰는 그런 거 아닌가 싶었거든요. 근데 막상 해보니까… 생각보다 훨씬 접근하기 좋더라고요. 물론 삽질은 좀 했습니다 ㅎㅎ.

    Proxmox Ceph 클러스터는 단순히 스토리지 용량을 늘리는 게 아니에요. VM(가상 머신)이나 컨테이너가 어느 노드에서 죽더라도 데이터가 살아있는, 진짜 고가용성(High Availability) 인프라를 만드는 핵심 기술이거든요. 이걸 홈랩에 구현할 수 있다는 게 Proxmox VE의 진짜 매력이라고 생각해요. 오늘은 제가 직접 구축하면서 배운 것들을 처음부터 끝까지 다 풀어드릴게요.

    ▲ Proxmox VE 3노드 Ceph 클러스터 전체 아키텍처 — Public Network, Cluster Network, OSD 구성을 한눈에 볼 수 있습니다.

    Ceph가 뭔지부터 제대로 이해하고 시작하자

    쉽게 말해, Ceph는 어떤 녀석인가요?

    Ceph를 한 줄로 설명하면 “여러 서버의 디스크를 하나의 거대한 스토리지 풀로 묶어주는 오픈소스 분산 스토리지 시스템”입니다. 쉽게 비유하자면, 서버 3대가 있으면 각 서버의 디스크를 전부 합쳐서 하나의 큰 창고처럼 쓰는 거예요. 게다가 데이터를 여러 곳에 복사해두기 때문에 서버 한 대가 꺼져도 데이터는 안전합니다.

    Proxmox VE는 Ceph를 웹 UI에서 직접 설치하고 관리할 수 있도록 통합해놨어요. 예전에 Ceph를 별도로 구성하던 시절을 생각하면 정말 편해진 거죠.

    핵심 구성 요소 이해하기

    구축 전에 이 개념들은 꼭 알고 시작하세요. 처음엔 저도 이게 뭔가 싶었는데, 알고 나면 구성이 훨씬 명확하게 보입니다.

    • MON (Monitor): 클러스터 상태를 감시하는 감시자. 클러스터 맵(어디에 데이터가 있는지 지도)을 관리합니다. 홀수 개로 운영해야 해요 (3개 권장).
    • OSD (Object Storage Daemon): 실제 데이터를 저장하는 데몬. 디스크 하나당 OSD 하나가 대응됩니다. 클러스터의 일꾼이라고 생각하시면 돼요.
    • MGR (Manager): 클러스터 모니터링과 플러그인 관리를 담당. 대시보드, Prometheus 연동 등이 여기서 나옵니다.
    • MDS (Metadata Server): CephFS(파일 시스템)를 쓸 때만 필요한 메타데이터 서버. 오늘 구성에서는 선택사항입니다.
    • Pool (풀): 데이터를 저장하는 논리적 구획. 복제 수(Replication Factor)를 풀 단위로 설정합니다.
    • PG (Placement Group): 데이터를 OSD에 분산 배치하는 단위. 너무 많거나 적으면 성능에 영향을 줍니다.

    네트워크 구성, 이게 제일 중요합니다

    여기서 중요한 포인트! Ceph는 네트워크를 두 개로 분리하는 걸 강력히 권장합니다.

    네트워크 종류 역할 권장 대역폭 비고
    Public Network (퍼블릭 네트워크) 클라이언트 ↔ Ceph 통신, MON 통신 1Gbps 이상 VM이 스토리지에 접근하는 경로
    Cluster Network (클러스터 네트워크) OSD 간 복제 및 리밸런싱 트래픽 10Gbps 권장 분리하면 성능 대폭 향상

    홈랩에서 10Gbps 스위치가 없다면 최소한 두 개의 물리 인터페이스로 분리만 해도 효과가 있어요. 저는 처음에 네트워크를 하나로 합쳐서 썼다가 OSD 리밸런싱 때 VM 네트워크가 뚝뚝 끊기는 걸 경험했거든요 ㅠㅠ.

    구축 환경 및 사전 준비

    최소 구성 요구사항

    Ceph 클러스터는 최소 3개 노드가 필요합니다. 이건 협상이 안 되는 부분이에요. MON이 과반수 투표로 클러스터 상태를 결정하기 때문에 짝수 노드는 스플릿 브레인(Split-Brain) 위험이 있거든요.

    • ✅ 노드 수: 최소 3개 (홀수 권장)
    • ✅ OS: Proxmox VE 7.x 또는 8.x
    • ✅ OSD용 디스크: 노드당 최소 1개 (OS 디스크와 별도)
    • ✅ 네트워크: 노드 간 통신 가능한 네트워크 (가급적 2개 분리)
    • ✅ RAM: OSD 하나당 약 1~2GB 여유 RAM 필요

    제 홈랩 구성은 이렇습니다:

    • 노드 3개: pve01, pve02, pve03
    • 각 노드 OSD 디스크: 500GB SSD × 2개
    • Public Network: 192.168.10.0/24
    • Cluster Network: 192.168.20.0/24

    Proxmox 클러스터 먼저 구성하기

    Ceph를 시작하기 전에 Proxmox VE 클러스터가 먼저 구성되어 있어야 합니다. 아직 안 하셨다면 pve01에서 시작하세요.

    # pve01에서 클러스터 생성
pvecm create my-homelab-cluster

# pve02, pve03에서 클러스터 참여
pvecm add 192.168.10.101  # pve01의 IP

# 클러스터 상태 확인
pvecm status

    클러스터가 정상이면 이제 Ceph 설치로 넘어갑니다.

    Proxmox Ceph 클러스터 단계별 구축

    ▲ Proxmox VE 웹 UI에서 Ceph 설치 마법사를 통해 직관적으로 구성할 수 있습니다. GUI와 CLI 모두 지원합니다.

    1단계: Ceph 패키지 설치

    모든 노드에서 아래 작업을 수행해야 합니다. Proxmox 웹 UI에서 각 노드 → Ceph → Install을 클릭해도 되고, CLI로 해도 됩니다. 저는 CLI가 더 빠르더라고요.

    # 모든 노드(pve01, pve02, pve03)에서 실행
# Proxmox VE 8.x 기준 (Ceph Reef/Quincy 지원)
pveceph install --version reef

# 설치 완료 후 확인
ceph --version

    💡 팁: Proxmox VE 8.x에서는 Ceph Reef(18.x)를 권장합니다. 버전은 Proxmox 버전에 맞게 선택하세요.

    2단계: Ceph 초기화 (pve01에서만)

    클러스터 초기화는 한 노드에서만 합니다. 여기서 네트워크 설정이 핵심이에요.

    # pve01에서만 실행
# Public Network와 Cluster Network를 분리해서 설정
pveceph init \
  --network 192.168.10.0/24 \
  --cluster-network 192.168.20.0/24

# 초기화 확인
ceph status

    3단계: MON (Monitor) 추가

    각 노드에 MON을 추가합니다. 3개 이상의 홀수로 유지하는 게 핵심이에요.

    # pve01에서 순서대로 실행
# pve01 MON 추가
pveceph mon create pve01

# pve02 MON 추가 (pve02에서 실행하거나 pve01에서 원격 실행)
pveceph mon create pve02

# pve03 MON 추가
pveceph mon create pve03

# MON 상태 확인
ceph mon stat

    4단계: MGR (Manager) 추가

    # 각 노드에 MGR 추가 (Active/Standby 구성)
pveceph mgr create pve01
pveceph mgr create pve02
pveceph mgr create pve03

# MGR 상태 확인
ceph mgr stat

    5단계: OSD 추가 — 진짜 데이터 저장소 만들기

    이 단계가 제일 중요합니다. OSD를 추가하기 전에 대상 디스크가 완전히 초기화되어 있어야 해요. 파티션이 남아있으면 추가가 안 됩니다.

    # 디스크 초기화 (주의: 데이터 전부 날아갑니다!)
# 각 노드에서 OSD용 디스크 확인
lsblk

# 디스크에 남은 파티션/서명 제거
wipefs -a /dev/sdb
wipefs -a /dev/sdc

# OSD 추가 (pve01의 /dev/sdb, /dev/sdc)
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# pve02에서도 동일하게
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# pve03에서도 동일하게
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# OSD 상태 확인
ceph osd stat
ceph osd tree

    ⚠️ 주의: wipefs 명령어는 되돌릴 수 없습니다. 반드시 올바른 디스크를 대상으로 하는지 lsblk로 두 번, 세 번 확인하세요. 저는 처음에 하마터면 OS 디스크를 날릴 뻔 했습니다 식은땀 났었어요.

    6단계: Pool (풀) 생성

    이제 실제 VM 디스크를 저장할 풀을 만들 차례입니다.

    # VM 디스크용 RBD(RADOS Block Device) 풀 생성
# size=3: 데이터를 3개 복사 (3노드에 각 1개씩)
# min_size=2: 최소 2개 복사본이 있어야 쓰기 허용
pveceph pool create vm-pool --add-storages

# 풀 상세 설정 (복제 수 조정)
ceph osd pool set vm-pool size 3
ceph osd pool set vm-pool min_size 2

# PG 수 설정 (OSD 수에 따라 조정 — OSD 6개 기준)
# 공식: (OSD 수 × 100) / 복제 수 → 가장 가까운 2의 제곱수
ceph osd pool set vm-pool pg_num 128
ceph osd pool set vm-pool pgp_num 128

# 풀 상태 확인
ceph osd pool ls detail

    💡 PG 수 계산 팁: OSD가 6개면 (6 × 100) / 3 = 200 → 2의 제곱수로 올림하면 256이 되지만, 홈랩 규모에서는 128도 충분합니다. 너무 많으면 오히려 오버헤드가 생겨요.

    7단계: Proxmox Storage에 Ceph 등록

    # Proxmox 스토리지로 등록 (이미 --add-storages 옵션으로 자동 등록됐을 수 있음)
# 웹 UI: Datacenter → Storage → Add → RBD

# CLI로 확인
pvesm status

    ⚠️ 실제로 겪은 트러블슈팅 모음

    문제 1: OSD가 계속 down/out 상태

    OSD를 추가했는데 계속 down 상태로 떠있더라고요. 원인을 찾아보니 디스크에 예전 Ceph 서명이 남아있었어요.

    # 해결 방법: 더 강력한 디스크 초기화
dd if=/dev/zero of=/dev/sdb bs=1M count=100
wipefs -a /dev/sdb

# 그래도 안 되면 sgdisk로 파티션 테이블 초기화
sgdisk --zap-all /dev/sdb

# 이후 OSD 재추가
pveceph osd create /dev/sdb

    문제 2: ceph status가 HEALTH_WARN — “too few PGs per OSD”

    PG 수가 OSD 대비 너무 적거나 많을 때 나오는 경고입니다. 이건 풀의 PG 수를 조정하면 됩니다.

    # 현재 PG 상태 확인
ceph osd pool ls detail

# PG 수 조정 (늘릴 때는 두 배씩)
ceph osd pool set vm-pool pg_num 256
ceph osd pool set vm-pool pgp_num 256

# PG 자동 조정 활성화 (Nautilus 이상)
ceph osd pool set vm-pool pg_autoscale_mode on

    문제 3: 클러스터 네트워크 쪽 OSD 통신 불량

    Cluster Network를 분리했는데 OSD 간 복제가 안 되는 경우가 있었어요. 방화벽 문제였습니다.

    # Ceph OSD 포트 허용 (6800-7300)
# pve 방화벽 설정 확인
cat /etc/pve/firewall/cluster.fw

# 임시로 방화벽 꺼서 테스트
pve-firewall stop

# 정상 확인 후 방화벽 규칙 추가
# /etc/pve/firewall/cluster.fw 에 추가:
# [RULES]
# IN ACCEPT -p tcp --dport 6800:7300 -s 192.168.20.0/24

    문제 4: VM 마이그레이션 시 느림

    Ceph 스토리지로 라이브 마이그레이션(Live Migration)을 했는데 엄청 느렸어요. 알고 보니 마이그레이션 네트워크가 Public Network를 타고 있어서였습니다. Proxmox에서 마이그레이션 전용 네트워크를 지정해주면 해결됩니다.

    # /etc/pve/datacenter.cfg 에서 마이그레이션 네트워크 설정
migration: secure
migration_unsecure: 192.168.20.0/24

    ✅ 클러스터 상태 검증 및 모니터링

    ▲ Ceph 클러스터가 정상 구성되면 HEALTH_OK 상태와 함께 OSD 트리, 풀 사용량을 실시간으로 확인할 수 있습니다.

    필수 확인 명령어

    # 전체 클러스터 상태 (이게 제일 중요)
ceph status
ceph health detail

# OSD 상태 및 트리 구조
ceph osd tree
ceph osd stat

# 풀 사용량
ceph df
ceph osd pool stats

# I/O 실시간 모니터링
ceph -w

# 성능 확인
rados bench -p vm-pool 10 write --no-cleanup
rados bench -p vm-pool 10 seq

    정상 상태 체크리스트

    • ✅ ceph status → HEALTH_OK 표시
    • ✅ MON 쿼럼(Quorum): 3/3 참여
    • ✅ OSD: all up, all in (예: 6/6 OSDs up)
    • ✅ PG: active+clean 상태
    • ✅ MGR: active 1개 + standby 2개

    Proxmox 대시보드에서도 확인

    웹 UI에서 Datacenter → Ceph 메뉴로 가면 OSD 상태, 풀 사용량, I/O 그래프를 한눈에 볼 수 있어요. 이게 진짜 편합니다. CLI로 하나씩 확인하던 시절이 생각나서 감동받았던 기억이 나네요.

    CephFS로 공유 파일시스템도 만들어보자 (보너스)

    VM 디스크(RBD) 외에도 CephFS(Ceph File System)를 구성하면 여러 VM이 동시에 마운트할 수 있는 공유 스토리지를 만들 수 있어요. Kubernetes의 PVC(Persistent Volume Claim)에도 활용할 수 있고요.

    # MDS(Metadata Server) 추가
pveceph mds create pve01
pveceph mds create pve02  # 스탠바이용

# CephFS 생성
pveceph fs create --name cephfs --add-storages

# 상태 확인
ceph fs status
ceph mds stat

    CephFS 마운트 설정은 다음 글에서 Kubernetes 연동과 함께 자세히 다룰 예정입니다!

    구성 옵션 비교 — 내 환경에 맞는 선택은?

    ▲ 환경별 Ceph 구성 전략 비교 — 홈랩, 소규모 사업장, 엔터프라이즈 환경에 따라 최적 구성이 다릅니다.

    구성 옵션 홈랩 (3노드) 소규모 프로덕션 엔터프라이즈
    복제 수 (size) 2~3 3 3+
    OSD 디스크 SATA SSD NVMe SSD NVMe + WAL 분리
    클러스터 네트워크 1Gbps 분리 10Gbps 25Gbps+
    MON 수 3 3~5 5
    BlueStore WAL/DB OSD와 동일 디스크 별도 NVMe 권장 별도 NVMe 필수

    홈랩에서는 복제 수를 2로 설정해서 실제 사용 가능 용량을 늘리는 분들도 있는데, 저는 개인적으로 3을 유지하는 걸 권장합니다. 노드 하나가 죽었을 때도 데이터 안전성이 보장되니까요.

    자주 묻는 질문 (FAQ)

    Q. Ceph는 2노드로 구성할 수 없나요?

    기술적으로 가능은 하지만 권장하지 않습니다. MON이 2개면 한 노드가 죽었을 때 쿼럼을 유지할 수 없어서 클러스터 전체가 멈춥니다. 최소 3노드를 유지하세요.

    Q. 기존 Proxmox에 Ceph를 나중에 추가해도 되나요?

    네, 됩니다! Proxmox 클러스터가 이미 구성된 상태에서 Ceph를 나중에 추가해도 전혀 문제없어요. 저도 그렇게 했거든요. 기존 VM들은 로컬 스토리지를 계속 쓰고, 새 VM부터 Ceph 풀을 지정하면 됩니다.

    Q. OSD 디스크는 HDD도 되나요?

    됩니다. 다만 HDD는 레이턴시(응답 지연)가 높아서 VM 성능에 영향을 줍니다. 가능하면 SSD를 권장하고, HDD를 써야 한다면 BlueStore의 WAL(Write-Ahead Log)과 DB를 별도 SSD에 올리는 구성을 고려해보세요.

    Q. 클러스터에 노드를 나중에 추가할 수 있나요?

    네, Ceph의 가장 큰 장점 중 하나가 바로 수평 확장(Horizontal Scaling)입니다. 노드를 추가하면 Ceph가 자동으로 데이터를 재분배(Rebalancing)합니다. 다만 리밸런싱 중에는 I/O가 좀 느려질 수 있어요.

    마무리 — Proxmox Ceph의 진짜 가치

    처음 Ceph를 공부할 때 “이게 홈랩에서 쓸 수 있는 건가?” 싶었는데, 이제는 제 인프라에서 없어서는 안 될 핵심이 됐습니다. Proxmox VE + Ceph 클러스터 조합이 주는 진짜 가치는 이거예요.

    • 🎉 진짜 고가용성: 노드 하나가 죽어도 VM이 살아있는 인프라
    • 🎉 스토리지 통합 관리: 웹 UI 하나로 모든 걸 관리
    • 🎉 무중단 확장: 서비스 중단 없이 디스크/노드 추가 가능
    • 🎉 오픈소스 무료: 엔터프라이즈급 기능을 라이선스 비용 없이

    물론 단점도 있어요. 초기 구성이 복잡하고, 리소스(특히 RAM)를 꽤 먹습니다. 그리고 문제가 생겼을 때 디버깅이 쉽지 않을 수 있고요. 하지만 한 번 제대로 구성해두면 그 안정성은 정말 믿음직스럽습니다.

    다음 글에서는 Ceph 클러스터 위에 Kubernetes를 올리고 CSI(Container Storage Interface) 드라이버로 연동하는 방법을 다룰 예정이에요. 이전에 Proxmox 기본 클러스터 구성 글도 참고하시면 이번 내용이 더 잘 이해되실 겁니다.

    궁금한 점이나 삽질 경험이 있으시면 댓글로 남겨주세요. 저도 아직 배우는 중이니까요 😄

  • [Proxmox] Proxmox VE 백업 및 복원 전략: 안전한 가상 환경 운영 가이드

    [Proxmox] Proxmox VE 백업 및 복원 전략: 안전한 가상 환경 운영 가이드

    목차

    백업 없는 서버는 시한폭탄이나 마찬가지입니다

    13년 동안 인프라를 운영하면서 가장 많이 들은 말이 뭔지 아세요? “백업은 있는데 복원은 해본 적이 없어요.” 이거거든요. 솔직히 저도 초반에 그랬습니다. 백업 스크립트 돌려놓고 ‘됐겠지’ 하고 넘어갔다가… 실제로 장애가 났을 때 복원이 안 되는 경험을 한 번 해보고 나서야 정신이 번쩍 들었죠.

    Proxmox VE(프록스목스 가상 환경) 환경에서 VM(가상 머신)이나 LXC 컨테이너를 운영 중이라면, Proxmox VE 백업 전략은 선택이 아니라 필수입니다. 홈랩이든 소규모 프로덕션이든 마찬가지예요. 오늘은 제가 실제로 구성하고 운영 중인 Proxmox VE 백업 및 복원 전략을 처음부터 끝까지 풀어드리겠습니다.

    Proxmox VE 백업 전략 전체 아키텍처 구성도 — VM, 로컬 스토리지, NAS, 클라우드 백업 흐름

    ▲ Proxmox VE 백업 전략의 전체 구성도 — VM 백업, 스냅샷, 외부 스토리지까지 한눈에 볼 수 있습니다.

    Proxmox VE 백업 방식, 뭐가 다른 건가요?

    Proxmox VE에서 제공하는 데이터 보호 방식은 크게 세 가지입니다. 처음 접하면 헷갈리는데, 쉽게 정리해드릴게요.

    1. 스냅샷 (Snapshot) — 빠르지만 독립적이지 않다

    스냅샷은 특정 시점의 VM 상태를 기록해두는 기능입니다. 쉽게 말해서, 게임의 세이브 포인트 같은 거예요. 디스크 상태뿐 아니라 RAM 상태까지 저장할 수 있어서 그 순간 그대로 돌아올 수 있습니다. 단, 스냅샷은 원본 스토리지에 의존하기 때문에 스토리지 자체가 날아가면 함께 사라집니다. 이 점을 반드시 기억해야 해요.

    2. 백업 (Backup/vzdump) — 진짜 의미의 백업

    Proxmox VE의 vzdump 도구를 사용해서 VM이나 LXC의 전체 이미지를 별도 파일로 추출하는 방식입니다. 이 파일은 독립적으로 존재하기 때문에 원본이 날아가도 복원이 가능합니다. 저장 형식은 .vma(VM용) 또는 .tar(LXC용)이고, 압축 옵션을 선택할 수 있습니다.

    3. 복제 (Replication) — HA 구성을 위한 실시간 동기화

    Proxmox VE 클러스터 환경에서 노드 간에 ZFS 스냅샷 기반으로 데이터를 동기화하는 기능입니다. 고가용성(HA, High Availability) 구성에 주로 쓰이고, 단일 노드 홈랩에서는 크게 쓸 일이 없습니다.

    방식 독립성 속도 용도 권장 상황
    스냅샷 ❌ 원본 의존 ⚡ 매우 빠름 작업 전 임시 저장 업데이트, 설정 변경 전
    vzdump 백업 ✅ 독립적 🐢 느림 재해 복구(DR) 정기 백업, 장기 보관
    복제 ✅ 노드 분리 ⚡ 빠름(증분) HA 구성 클러스터 환경

    실전 구현: vzdump로 VM 백업 설정하기

    자, 이제 실제로 설정해봅시다. Proxmox VE 웹 UI와 CLI 양쪽 다 설명드릴게요. 저는 주로 CLI를 쓰는 편인데, 자동화하기 훨씬 편하거든요.

    백업 스토리지 추가

    먼저 백업 파일을 저장할 스토리지를 지정해야 합니다. 웹 UI 기준으로는 Datacenter → Storage → Add에서 추가할 수 있어요. NFS나 SMB/CIFS, 로컬 디렉토리 등 다양한 방식을 지원합니다.

    CLI로 NFS 스토리지를 추가하는 예시입니다:

    # NFS 백업 스토리지 추가
pvesm add nfs backup-nfs \
  --server 192.168.1.100 \
  --export /mnt/nas/proxmox-backup \
  --content backup \
  --maxfiles 3

# 추가된 스토리지 확인
pvesm status

    여기서 --maxfiles 3은 백업 파일을 최대 3개까지 보관하고, 초과하면 오래된 것부터 자동 삭제한다는 뜻입니다. 스토리지가 부족할 때 꼭 설정해줘야 해요. 저 처음에 이거 안 해놨다가 NAS가 꽉 차서 백업이 실패하는 상황을 겪었거든요.

    수동 백업 실행 (CLI)

    # 특정 VM 백업 (VM ID: 100)
vzdump 100 --storage backup-nfs --compress zstd --mode snapshot

# 모든 VM 백업
vzdump --all --storage backup-nfs --compress zstd --mode snapshot

# LXC 컨테이너 백업 (CT ID: 200)
vzdump 200 --storage backup-nfs --compress zstd --mode suspend

    백업 모드(--mode) 옵션이 중요합니다. 세 가지가 있어요:

    • snapshot: VM을 계속 실행하면서 스냅샷 기반으로 Proxmox VE 백업을 진행. 서비스 중단 없음. 권장
    • suspend: 백업 중 VM을 일시 정지. 데이터 일관성은 좋지만 서비스 잠깐 중단
    • stop: VM을 완전히 중지 후 백업. 가장 안전하지만 다운타임 발생

    자동 백업 스케줄 설정

    Proxmox VE 웹 UI에서 Datacenter → Backup → Add로 스케줄을 만들 수 있습니다. 하지만 저는 설정 파일을 직접 확인하고 관리하는 걸 더 좋아해요. 설정 파일 위치는 여기입니다:

    # 백업 스케줄 설정 파일
cat /etc/cron.d/vzdump

# 예시: 매일 새벽 2시에 모든 VM 백업
0 2 * * * root /usr/bin/vzdump --all --storage backup-nfs \
  --compress zstd --mode snapshot \
  --mailto [email protected] \
  --quiet 1

    웹 UI에서 만든 스케줄은 /etc/pve/jobs.cfg 파일에 저장됩니다. 확인해보면 이런 형태예요:

    vzdump: job-daily-backup
	compress zstd
	day mon,tue,wed,thu,fri,sat,sun
	enabled 1
	mailnotification always
	mode snapshot
	node pve-node01
	starttime 02:00
	storage backup-nfs
    Proxmox VE 웹 UI 자동 백업 스케줄 설정 화면 예시

    ▲ Proxmox VE 웹 UI에서 자동 백업 스케줄을 설정하는 화면 — 스토리지, 시간, 압축 방식을 직관적으로 설정할 수 있습니다.

    복원(Restore) 실전 가이드

    백업만큼 중요한 게 복원 연습입니다. 실제로 장애 상황에서 손이 떨리면서 복원 명령어 치는 것보다, 미리 한 번이라도 해봤냐 안 해봤냐가 엄청난 차이를 만들어요.

    웹 UI로 복원하기

    1. Proxmox VE 웹 UI 접속 → 왼쪽 패널에서 백업 스토리지 선택
    2. Content 탭 클릭 → 백업 파일 목록 확인
    3. 복원할 백업 파일 선택 → Restore 버튼 클릭
    4. 복원할 노드, VM ID, 스토리지 선택 후 Restore 실행

    CLI로 복원하기

    # 백업 파일 목록 확인
pvesm list backup-nfs

# VM 복원 (백업 파일에서 VM ID 101로 복원)
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2024_01_15-02_00_00.vma.zst 101

# 기존 VM을 덮어쓰면서 복원 (같은 ID 사용)
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2024_01_15-02_00_00.vma.zst 100 --force

# LXC 컨테이너 복원
pct restore 201 /mnt/pve/backup-nfs/dump/vzdump-lxc-200-2024_01_15-02_00_00.tar.zst \
  --storage local-lvm

    복원 후에는 반드시 VM을 시작해서 서비스가 정상 동작하는지 확인하세요. 저는 복원 테스트할 때 항상 다른 VM ID로 먼저 복원해보고, 내부에서 서비스 상태 확인한 다음에 실제 교체하는 방식을 씁니다.

    스냅샷 활용 전략 — 올바르게 쓰는 법

    스냅샷은 정말 편리한 기능인데, 잘못 쓰면 오히려 독이 됩니다. 제가 봐온 가장 흔한 실수가 스냅샷을 백업 대용으로 쓰는 거예요.

    스냅샷 생성 및 관리

    # VM 스냅샷 생성 (RAM 상태 포함)
qm snapshot 100 pre-update-20240115 \
  --description "커널 업데이트 전 스냅샷" \
  --vmstate 1

# 스냅샷 목록 확인
qm listsnapshot 100

# 스냅샷으로 롤백
qm rollback 100 pre-update-20240115

# 스냅샷 삭제
qm delsnapshot 100 pre-update-20240115

    💡 팁: 스냅샷이 쌓이면 VM 성능에 영향을 줄 수 있습니다. 특히 QCOW2 포맷에서 스냅샷 체인이 길어지면 I/O 성능이 떨어지거든요. 작업이 끝나면 반드시 필요 없는 스냅샷은 지워주세요.

    스냅샷 vs 백업 — 언제 뭘 써야 하나

    • ✅ 스냅샷 사용 시점: 패키지 업데이트 전, 설정 변경 전, 테스트 작업 전 (단기 롤백 목적)
    • ✅ 백업 사용 시점: 정기적 데이터 보호, 장기 보관, 다른 서버로 이전, 재해 복구(DR, Disaster Recovery)

    ⚠️ 트러블슈팅 — 제가 직접 겪은 문제들

    자, 이제 진짜 중요한 부분입니다. Proxmox VE 백업 설정하면서 제가 삽질했던 경험들을 공유할게요.

    문제 1: 백업 중 “lock file exists” 오류

    백업이 중간에 실패하면 락 파일이 남아서 다음 백업도 실패하는 경우가 있습니다.

    # 락 파일 확인
ls /var/run/vzdump.lock

# 강제 삭제 (프로세스가 없을 때만!)
rm /var/run/vzdump.lock

# vzdump 프로세스 확인
ps aux | grep vzdump

    문제 2: NFS 스토리지 백업 실패

    NFS 마운트 포인트 권한 문제로 백업이 실패하는 경우가 많습니다. NFS 서버 설정에서 no_root_squash 옵션이 빠져 있으면 root 권한으로 쓰기가 안 돼요.

    # NFS 서버 측 /etc/exports 설정 예시
/mnt/nas/proxmox-backup 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

# NFS 서버에서 exports 재적용
exportfs -ra

# Proxmox에서 마운트 상태 확인
mount | grep nfs
df -h

    문제 3: 스냅샷 상태에서 백업 실패

    VM에 스냅샷이 남아 있는 상태에서 mode=snapshot으로 백업하면 오류가 나는 경우가 있습니다. 특히 QCOW2 포맷에서 발생하는데, 이럴 때는 mode=suspend나 mode=stop을 시도해보세요.

    문제 4: 백업 파일 무결성 검증

    백업 파일이 제대로 됐는지 확인하는 방법도 알아두면 좋습니다.

    # 백업 파일 무결성 검사
vzdump --verify /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2024_01_15-02_00_00.vma.zst

# zstd 압축 파일 테스트
zstd --test /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2024_01_15-02_00_00.vma.zst
    Proxmox VE 백업 무결성 검증 및 복원 테스트 결과 대시보드

    ▲ 백업 무결성 검증 및 복원 테스트 결과 확인 — 정기적인 복원 테스트가 진짜 재해 복구의 핵심입니다.

    3-2-1 백업 규칙 — 홈랩에도 적용하세요

    인프라 업계에서 오랫동안 통용되는 백업 황금 규칙이 있습니다. 3-2-1 규칙이에요.

    • 📁 3: 데이터 복사본을 최소 3개 보관
    • 💾 2: 2가지 이상의 서로 다른 미디어/스토리지에 저장
    • 🌍 1: 1개는 오프사이트(원격 위치)에 보관

    홈랩 기준으로 현실적인 구성을 제안드리면:

    복사본 위치 방법
    원본 Proxmox 노드 로컬 스토리지 운영 중인 VM 자체
    2번째 로컬 NAS vzdump → NFS/SMB 백업
    3번째 클라우드 또는 외장 드라이브 rclone으로 클라우드 동기화

    클라우드 동기화는 rclone을 이용하면 편리합니다. Backblaze B2나 AWS S3 같은 저렴한 오브젝트 스토리지와 연동할 수 있거든요.

    # rclone으로 백업 파일 클라우드 동기화 예시
rclone sync /mnt/pve/backup-nfs/dump/ remote:proxmox-backup/ \
  --include "*.vma.zst" \
  --min-age 1h \
  --log-file /var/log/rclone-backup.log

# cron에 등록 (매일 새벽 4시 실행)
echo "0 4 * * * root rclone sync /mnt/pve/backup-nfs/dump/ remote:proxmox-backup/ --include '*.vma.zst' --min-age 1h" >> /etc/cron.d/rclone-backup

    재해 복구(DR) 시나리오별 대응 전략

    마지막으로, 실제 장애 상황별로 어떻게 대응해야 하는지 정리해드릴게요. 이걸 미리 문서화해두면 실제 장애 시 훨씬 침착하게 대응할 수 있습니다.

    시나리오 1: VM 데이터 손상 (단일 VM 문제)

    1. 해당 VM 중지
    2. 최신 백업 파일 확인: pvesm list backup-nfs
    3. 새 VM ID로 복원 후 데이터 확인
    4. 문제없으면 기존 VM 삭제 후 ID 교체

    시나리오 2: Proxmox 노드 장애 (하드웨어 교체 필요)

    1. 새 하드웨어에 동일 버전 Proxmox VE 설치
    2. 백업 스토리지(NAS) 연결 및 스토리지 추가
    3. 모든 VM을 백업에서 순차 복원
    4. 네트워크 설정 재확인 및 서비스 점검

    시나리오 3: 스토리지 전체 장애

    1. 클라우드 또는 외장 드라이브에 보관된 3번째 백업 사용
    2. 새 스토리지 준비 후 백업 파일 복사
    3. Proxmox에서 스토리지 재구성 후 복원 진행
    Proxmox VE 재해 복구 전략 3-2-1 백업 규칙 인포그래픽

    ▲ 재해 복구 전략 요약 인포그래픽 — 3-2-1 백업 규칙과 시나리오별 대응 흐름을 한눈에 정리했습니다.

    자주 묻는 질문 (FAQ)

    Q. 백업 중에 VM을 사용해도 되나요?

    네, mode=snapshot 옵션을 사용하면 백업 중에도 VM이 계속 실행됩니다. 다만 데이터베이스 서버처럼 트랜잭션이 많은 경우엔 애플리케이션 레벨의 백업도 병행하는 걸 권장합니다.

    Q. 압축 형식은 뭘 써야 하나요?

    Proxmox VE 7.x 이상에서는 zstd를 추천합니다. gzip보다 훨씬 빠르면서 압축률도 비슷하거든요. 구버전에서는 lzo가 속도가 빠른 편입니다.

    Q. 백업 파일 크기가 너무 큰데 줄일 방법이 있나요?

    VM 내부에서 불필요한 파일을 정리하고 디스크 빈 공간을 0으로 채운 후 백업하면 압축률이 올라갑니다. Linux VM 기준으로 dd if=/dev/zero of=/tmp/zero.file; rm /tmp/zero.file 실행 후 백업해보세요.

    마무리 — 백업은 문화입니다

    오늘 Proxmox VE 백업과 복원 전략을 처음부터 끝까지 다뤄봤는데요. 핵심만 다시 정리하면:

    • ✅ 스냅샷은 단기 롤백, vzdump 백업은 장기 보관용으로 구분해서 사용하세요
    • ✅ 3-2-1 규칙을 홈랩에도 적용하세요 — 클라우드 동기화가 생각보다 저렴합니다
    • ✅ 복원 테스트를 정기적으로 해보세요 — 최소 분기에 한 번은 실제로 복원해보는 걸 강력 추천합니다
    • ✅ 백업 알림 설정을 꼭 해두세요 — 실패했는데 모르고 있는 게 제일 위험합니다

    혹시 Proxmox VE 클러스터 환경에서의 복제(Replication) 설정이나 Proxmox Backup Server(PBS) 연동에 대해 궁금하신 분들은 다음 글에서 자세히 다룰 예정이니 기대해주세요. PBS는 중복 제거(deduplication) 기능이 있어서 스토리지 효율이 훨씬 좋거든요.

    13년 동안 서버 운영하면서 배운 가장 중요한 교훈 하나를 드리고 마칠게요. “백업은 있는데 복원은 안 된다”는 건 백업이 없는 것과 같습니다. 오늘 바로 복원 테스트 한 번 해보시는 거 어떨까요? 🎉

  • [Proxmox] Proxmox VE ZFS 스토리지 최적화: 성능과 안정성 동시 확보 가이드

    [Proxmox] Proxmox VE ZFS 스토리지 최적화: 성능과 안정성 동시 확보 가이드

    목차

    ZFS를 Proxmox에 올리면 생기는 일

    홈랩을 운영하다 보면 어느 순간 이런 생각이 드시죠. “스토리지 관리 좀 제대로 해보고 싶다.” 저도 그랬거든요. 처음엔 그냥 ext4 파티션에 LVM(논리 볼륨 관리자) 얹어서 쓰다가, 어느 날 디스크 하나가 조용히 세상을 떠나면서 VM 이미지를 통째로 날린 경험이 있습니다. 그날 이후로 ZFS(Zettabyte File System)를 진지하게 공부하기 시작했어요.

    Proxmox VE ZFS 조합은 사실 홈랩 커뮤니티에서 꽤 오래된 조합입니다. Proxmox VE가 ZFS를 기본 지원하기 시작한 이후로, 별도의 커널 모듈 컴파일 없이도 ZFS를 바로 쓸 수 있게 됐거든요. 근데 막상 써보면 “설치는 쉬운데, 최적화는 어디서부터 시작해야 하지?” 하는 막막함이 있더라고요. 오늘은 그 막막함을 같이 해소해 보겠습니다.

    Proxmox VE ZFS 스토리지 아키텍처 전체 계층 구조 다이어그램

    ▲ Proxmox VE + ZFS 스토리지 구성 전체 아키텍처 — VM/CT 레이어부터 ZFS 풀(Pool), 물리 디스크까지의 계층 구조를 보여줍니다.

    ZFS가 뭔지 먼저 짚고 가겠습니다

    쉽게 말해서 ZFS는 “똑똑한 파일 시스템”입니다

    일반 파일 시스템과 ZFS의 가장 큰 차이점은, ZFS가 파일 시스템과 볼륨 관리자를 동시에 담당한다는 점이에요. 기존에는 파티션 → LVM → 파일 시스템 이렇게 레이어가 쌓였다면, ZFS는 이걸 하나로 통합해서 관리합니다.

    핵심 기능만 짚어볼게요:

    • Copy-on-Write(CoW, 쓰기 시 복사): 데이터를 덮어쓰지 않고 항상 새 블록에 씁니다. 시스템이 갑자기 꺼져도 데이터가 깨지지 않아요.
    • Checksum(체크섬, 데이터 무결성 검증): 모든 블록에 체크섬이 붙어 있어서, 읽을 때마다 데이터가 정상인지 자동으로 확인합니다. Silent Data Corruption(무음 데이터 손상)을 잡아내는 거죠.
    • Snapshot(스냅샷): 순간적으로 파일 시스템 상태를 저장합니다. Proxmox에서 VM 백업할 때 이게 핵심이에요.
    • RAID-Z(레이드-Z): 소프트웨어 RAID를 ZFS 레벨에서 처리합니다. 하드웨어 RAID 컨트롤러 없이도 충분한 안정성을 확보할 수 있어요.
    • ARC(Adaptive Replacement Cache, 적응형 교체 캐시): RAM을 읽기 캐시로 활용합니다. 메모리가 많을수록 성능이 올라가요.

    Proxmox VE에서 ZFS 스토리지를 쓰면 좋은 이유

    솔직히 말하면, Proxmox + ZFS 조합의 가장 큰 장점은 스냅샷 기반 백업이 기가 막히게 편하다는 겁니다. VM을 백업할 때 ZFS 스냅샷을 찍으면 거의 순간적으로 완료되거든요. 100GB짜리 VM이라도 스냅샷 자체는 1초도 안 걸립니다. 실제 데이터 복사가 아니라 메타데이터만 기록하는 방식이라서요.

    항목 기존 LVM + ext4 ZFS
    데이터 무결성 파일 시스템 레벨만 블록 레벨 체크섬
    스냅샷 속도 데이터 크기에 비례 거의 즉각적
    RAID 관리 별도 mdadm 필요 ZFS 내장
    압축 지원 안 함 투명 압축 지원
    RAM 요구량 낮음 높음 (ARC 때문에)
    설정 복잡도 낮음 중간~높음

    Proxmox VE ZFS 풀(Pool) 구성하기

    1단계: ZFS 풀 생성 전 디스크 확인

    먼저 사용할 디스크들을 확인합니다. 중요한 건 ZFS는 반드시 디스크 전체를 넘겨줘야 한다는 거예요. 파티션 위에 ZFS를 올리는 것도 기술적으로는 가능하지만, 권장하지 않습니다. 저도 처음에 파티션 위에 올렸다가 나중에 풀 교체하는 데 고생했거든요.

    # 현재 연결된 디스크 목록 확인
lsblk -d -o NAME,SIZE,MODEL,SERIAL

# 디스크 상태 확인 (스마트 정보)
smartctl -a /dev/sdb

# ZFS에서 사용할 디스크 ID 확인 (권장: ID 방식으로 지정)
ls -la /dev/disk/by-id/ | grep -v part

    💡 팁: ZFS 풀 생성 시 /dev/sdb 같은 경로 대신 /dev/disk/by-id/ 아래의 ID를 사용하세요. 재부팅 후 디스크 순서가 바뀌어도 안전합니다.

    2단계: ZFS 풀 생성

    Proxmox에서 ZFS 풀을 만드는 방법은 두 가지입니다. GUI로 하거나 CLI로 하거나. 저는 CLI를 선호해요. 정확히 뭘 하는지 눈에 보이니까요.

    # 미러(Mirror, RAID-1과 유사) 풀 생성 예시 — 디스크 2개
zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  -O dnodesize=auto \
  rpool mirror \
  /dev/disk/by-id/ata-디스크1_시리얼 \
  /dev/disk/by-id/ata-디스크2_시리얼

# RAID-Z1 풀 생성 예시 — 디스크 3개 이상
zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  -O dnodesize=auto \
  datapool raidz1 \
  /dev/disk/by-id/ata-디스크1_시리얼 \
  /dev/disk/by-id/ata-디스크2_시리얼 \
  /dev/disk/by-id/ata-디스크3_시리얼

    여기서 각 옵션이 뭔지 짚어볼게요:

    • ashift=12: 4KB 섹터 디스크에 맞는 설정. 요즘 HDD/SSD 대부분이 4KB 섹터 또는 그 이상이라서 거의 필수입니다. 풀 생성 후 변경 불가니까 처음에 꼭 확인하세요.
    • compression=lz4: LZ4 압축 활성화. CPU 부하가 거의 없으면서 10~30% 정도 공간을 아낄 수 있어요.
    • atime=off: 파일 접근 시간 기록 비활성화. I/O 성능 향상에 도움이 됩니다.
    • xattr=sa: 확장 속성을 inode에 저장. 성능 향상에 기여해요.
    • dnodesize=auto: dnode 크기 자동 조정. 대용량 파일 시스템에 유리합니다.

    3단계: Proxmox에 ZFS 스토리지 등록

    풀을 만들었으면 Proxmox가 이걸 스토리지로 인식하게 해줘야 합니다.

    # /etc/pve/storage.cfg 에 추가하거나
# Proxmox GUI: Datacenter > Storage > Add > ZFS 선택

# CLI로 추가하는 방법
pvesm add zfspool datapool-storage \
  --pool datapool \
  --content images,rootdir \
  --sparse 1

    GUI에서 하시면 Datacenter → Storage → Add → ZFS 선택하고 풀 이름 입력하면 됩니다. 훨씬 직관적이에요.

    Proxmox VE 웹 GUI ZFS 스토리지 추가 설정 화면

    ▲ Proxmox VE 관리 콘솔에서 ZFS 풀을 스토리지로 등록하는 화면 — 풀 이름, Content 타입, Sparse 옵션 등을 설정합니다.

    ZFS 성능 최적화 핵심 설정

    ARC 메모리 설정 — 제일 중요합니다

    ZFS의 ARC(Adaptive Replacement Cache)는 기본적으로 사용 가능한 RAM의 절반 정도까지 사용하려고 합니다. 홈랩이나 소규모 서버에서는 이게 VM들이 쓸 메모리를 잡아먹는 문제가 생겨요. 저도 처음에 이 설정 안 하고 쓰다가 “왜 VM이 이렇게 느리지?” 하면서 한참 삽질했습니다.

    # 현재 ARC 사용량 확인
cat /proc/spl/kstat/zfs/arcstats | grep -E '^(size|c_max|c_min|hits|misses)'

# ARC 최대 크기 제한 설정 (예: 8GB로 제한)
# /etc/modprobe.d/zfs.conf 파일 생성/편집
cat > /etc/modprobe.d/zfs.conf << 'EOF'
options zfs zfs_arc_max=8589934592
EOF

# 즉시 적용 (재부팅 없이)
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

# 변경 확인
cat /sys/module/zfs/parameters/zfs_arc_max

    ⚠️ 주의: ARC를 너무 작게 설정하면 ZFS 성능이 크게 떨어집니다. 일반적으로 전체 RAM의 20~25% 정도는 ARC에 남겨두는 걸 권장해요. 16GB RAM이면 최소 4GB는 ARC에 할당하는 게 좋습니다.

    L2ARC와 ZIL/SLOG 설정 — SSD 있으면 써먹어야죠

    SSD가 여분으로 있다면 L2ARC(Level 2 ARC, 2차 읽기 캐시)와 SLOG(Separate Intent Log, 분리 의도 로그)로 활용할 수 있습니다.

    # L2ARC 추가 (읽기 캐시, SSD 권장)
zpool add datapool cache /dev/disk/by-id/ssd-캐시디스크_시리얼

# SLOG/ZIL 추가 (쓰기 캐시, 저지연 SSD 권장)
# 미러 구성을 강력히 권장 (SLOG 손실 시 데이터 손실 위험)
zpool add datapool log mirror \
  /dev/disk/by-id/ssd-slog1_시리얼 \
  /dev/disk/by-id/ssd-slog2_시리얼

# 현재 풀 구성 확인
zpool status datapool

    💡 팁: SLOG는 반드시 미러로 구성하세요. SLOG 디스크가 고장나면 최근 쓰기 데이터가 날아갈 수 있거든요. 비용이 두 배가 되더라도 미러가 맞습니다.

    ZFS 데이터셋 최적화 설정

    Proxmox에서 VM 이미지를 저장하는 데이터셋은 별도로 최적화해 주는 게 좋아요. VM 워크로드 특성에 맞게요.

    # VM 이미지용 데이터셋 최적화
# recordsize를 VM 디스크 블록 크기에 맞게 조정
zfs set recordsize=64K datapool/images

# 또는 데이터베이스 VM이 많다면
zfs set recordsize=16K datapool/images

# 압축 설정 (lz4가 성능/압축률 균형이 좋음)
zfs set compression=lz4 datapool

# 현재 데이터셋 속성 확인
zfs get all datapool | grep -E '(compression|recordsize|atime|sync)'

# sync 설정 (주의: disabled는 데이터 손실 위험 있음)
# VM이 많고 성능이 중요하다면 standard 유지 권장
zfs set sync=standard datapool/images

    Scrub(스크럽, 데이터 무결성 검사) 자동화

    ZFS의 핵심 기능 중 하나가 스크럽이에요. 모든 데이터 블록을 읽어서 체크섬을 검증하는 작업인데, 주기적으로 해줘야 Silent Data Corruption을 조기에 발견할 수 있습니다.

    # 수동으로 스크럽 실행
zpool scrub datapool

# 스크럽 진행 상황 확인
zpool status datapool

# 자동 스크럽 설정 (Proxmox는 기본적으로 월 1회 cron 설정됨)
# /etc/cron.d/zfsutils-linux 확인
cat /etc/cron.d/zfsutils-linux

# 직접 cron 설정 (매월 1일 새벽 2시)
crontab -e
# 아래 내용 추가:
# 0 2 1 * * /sbin/zpool scrub datapool

    ⚠️ 실제로 겪은 문제들과 해결법

    문제 1: VM 성능이 생각보다 안 나온다

    ZFS를 처음 올렸을 때 “왜 이렇게 느리지?” 하는 경험을 많이들 하세요. 저도 그랬는데, 원인이 몇 가지 있더라고요.

    원인 및 해결책:

    1. ashift 설정 오류: zpool status -v로 확인. 이미 풀이 생성됐다면 재생성 외에는 방법이 없어요. 처음부터 ashift=12를 꼭 넣어주세요.
    2. ARC 부족: arcstat 명령으로 hit ratio 확인. 70% 이하면 ARC가 부족한 겁니다.
    3. recordsize 불일치: VM 워크로드에 따라 recordsize를 조정하세요. 랜덤 I/O가 많은 DB 워크로드는 작은 recordsize가 유리합니다.
    # ARC 히트율 확인
arcstat 1 5

# ZFS I/O 통계 모니터링
zpool iostat -v datapool 2

# 상세 ZFS 통계
zfs-stats -a

    문제 2: 디스크 오류 발견 시 대응

    어느 날 아침에 zpool status를 실행했더니 DEGRADED 상태가 뜨는 경험을 한 적이 있습니다. 심장이 쿵 내려앉더라고요. 근데 ZFS가 있으니까 침착하게 대응할 수 있었어요.

    # 풀 상태 확인
zpool status -v datapool

# 오류 난 디스크 교체 후 resilvering(데이터 재동기화) 시작
# 1. 오류 디스크 오프라인 처리
zpool offline datapool /dev/disk/by-id/문제디스크_시리얼

# 2. 물리적으로 디스크 교체 후 새 디스크 지정
zpool replace datapool \
  /dev/disk/by-id/문제디스크_시리얼 \
  /dev/disk/by-id/새디스크_시리얼

# 3. resilvering 진행 상황 확인
zpool status datapool

    문제 3: 스냅샷이 쌓여서 공간이 부족해진다

    Proxmox 자동 백업 설정해 놓으면 스냅샷이 계속 쌓입니다. 어느 순간 “왜 공간이 이렇게 없지?” 하고 보면 스냅샷이 수십 개 쌓여 있는 경우가 있어요.

    # 스냅샷 목록 확인
zfs list -t snapshot -o name,used,creation | sort -k3

# 오래된 스냅샷 삭제
zfs destroy datapool/images/vm-100-disk-0@2024-01-01

# 특정 패턴의 스냅샷 일괄 삭제 (주의해서 사용!)
zfs list -t snapshot -H -o name | grep 'vm-100' | xargs -n1 zfs destroy

# Proxmox 백업 보존 정책 설정 (GUI 권장)
# Datacenter > Backup > 해당 작업 편집 > Keep 설정
    ZFS ARC 히트율 및 스토리지 I/O 성능 모니터링 대시보드

    ▲ ZFS ARC 히트율과 풀 I/O 성능 모니터링 — arcstat 및 zpool iostat 출력 결과를 시각화한 예시입니다. 히트율 80% 이상을 목표로 합니다.

    ZFS 스토리지 상태 검증하기

    일상적인 헬스체크 루틴

    이 명령어들은 저도 주기적으로 확인하는 것들이에요. 습관처럼 만들어 두면 정말 든든합니다.

    # 전체 풀 상태 한눈에 보기
zpool status

# 풀 사용량 확인
zpool list

# 데이터셋별 사용량 (스냅샷 포함)
zfs list -t all -o name,used,avail,refer,mountpoint

# 압축 효율 확인
zfs get compressratio datapool

# 전체 ZFS 이벤트 로그 확인
zpool events -v | tail -50

    성능 벤치마크 기준점 잡기

    최적화 전후를 비교하려면 기준점이 있어야 하죠. fio(Flexible I/O Tester)로 간단히 측정해 볼 수 있습니다.

    # fio 설치
apt install fio

# 순차 쓰기 테스트
fio --name=seqwrite \
  --filename=/datapool/testfile \
  --rw=write \
  --bs=1M \
  --size=4G \
  --numjobs=1 \
  --ioengine=libaio \
  --direct=1 \
  --group_reporting

# 랜덤 읽기 테스트 (4K 블록)
fio --name=randread \
  --filename=/datapool/testfile \
  --rw=randread \
  --bs=4K \
  --size=4G \
  --numjobs=4 \
  --ioengine=libaio \
  --direct=1 \
  --group_reporting

# 테스트 파일 정리
rm /datapool/testfile

    정리: ZFS 최적화 체크리스트

    Proxmox VE ZFS 최적화 핵심 설정 체크리스트 요약 인포그래픽

    ▲ Proxmox VE ZFS 최적화 핵심 설정 요약 — 풀 생성부터 ARC 튜닝, 스크럽 자동화까지 단계별 체크리스트입니다.

    지금까지 다룬 내용을 정리해 보겠습니다. 처음엔 복잡해 보여도, 하나씩 따라가면 충분히 할 수 있어요.

    필수 설정 체크리스트

    • ✅ ashift=12 — 풀 생성 시 반드시 지정
    • ✅ compression=lz4 — 성능 영향 없이 공간 절약
    • ✅ atime=off — 불필요한 I/O 제거
    • ✅ ARC 크기 제한 — VM 메모리와 균형 맞추기
    • ✅ 정기 스크럽 — 월 1회 이상 실행
    • ✅ 디스크 ID 방식 사용 — 재부팅 후 안정성 확보
    • ✅ 스냅샷 보존 정책 — 디스크 공간 관리
    • ✅ SLOG 미러 구성 — SLOG 사용 시 필수

    자주 묻는 질문 (FAQ)

    Q. ZFS는 ECC 메모리가 없으면 위험한가요?
    A. ECC 메모리가 없어도 ZFS를 쓸 수 있습니다. 다만 메모리 오류로 인한 데이터 손상 가능성이 이론적으로 존재해요. 홈랩 수준에서는 크게 걱정 안 해도 되지만, 프로덕션 환경이라면 ECC를 권장합니다.

    Q. ZFS 풀 크기를 나중에 늘릴 수 있나요?
    A. 네, 가능합니다. 미러 풀은 동일한 크기의 디스크 쌍을 추가해서 확장할 수 있어요. RAID-Z는 같은 VDEV(가상 디바이스) 내에서 디스크 추가가 어렵고, 새 VDEV를 추가하는 방식으로 확장합니다.

    Q. 압축을 켜면 CPU 사용률이 많이 올라가나요?
    A. lz4 압축은 CPU 영향이 매우 적습니다. 요즘 프로세서에서는 거의 체감이 안 될 정도예요. 오히려 I/O 양이 줄어서 전체 성능이 올라가는 경우도 있어요.

    마무리하며

    Proxmox VE ZFS 조합은 한번 제대로 세팅해 두면 정말 든든합니다. 디스크 하나가 죽어도 침착하게 교체하고 resilvering 기다리면 되고, 실수로 VM 날려도 스냅샷에서 복구하면 되고. 처음 세팅이 좀 복잡해 보이지만, 그 이후의 편안함은 진짜 다르더라고요.

    물론 ZFS가 만능은 아닙니다. 메모리를 많이 먹고, 설정이 복잡하고, 한번 만든 풀 구조를 바꾸기 어렵다는 단점도 있어요. 그래도 데이터 안정성과 스냅샷 편의성을 생각하면, 홈랩에서 ZFS를 선택하지 않을 이유가 없다고 생각합니다.

    다음 글에서는 Proxmox VE의 백업 자동화와 원격 ZFS 복제(Replication)를 다뤄볼 예정이에요. 오늘 설정한 ZFS 풀을 활용해서 다른 서버로 데이터를 자동으로 복제하는 방법인데, 이것도 꽤 유용하더라고요. 기대해 주세요!

    궁금한 점이나 다른 삽질 경험이 있으시면 댓글로 공유해 주세요. 같이 해결해 봐요!

  • [Proxmox] Proxmox 클러스터 HA 설정: 고가용성 구성 완벽 가이드 2026

    [Proxmox] Proxmox 클러스터 HA 설정: 고가용성 구성 완벽 가이드 2026

    목차

    서버가 꺼졌을 때, 그 순간을 대비해야 합니다

    몇 년 전 일이에요. 새벽 3시에 전화가 울렸습니다. 운영 중인 VM(가상머신)이 돌아가던 물리 서버 하나가 갑자기 다운됐다는 알림이었거든요. 그때 HA(High Availability, 고가용성) 설정이 없었더라면… 생각만 해도 식은땀이 납니다. 다행히 Proxmox 클러스터 HA 덕분에 VM들이 자동으로 다른 노드로 이전됐고, 서비스 중단 시간은 2분도 안 됐어요.

    이 글은 바로 그 경험을 바탕으로 씁니다. Proxmox VE 클러스터 고가용성(HA) 설정을 처음 해보시는 분들, 혹은 설정은 해봤는데 뭔가 불안한 분들을 위한 2026년 기준 실전 가이드예요. 홈랩에서도, 소규모 프로덕션 환경에서도 충분히 적용 가능한 내용으로 가득 채웠으니 끝까지 읽어보세요.

    Proxmox VE 클러스터 HA 전체 아키텍처 다이어그램

    ▲ Proxmox VE 3노드 클러스터 HA 전체 구성도 — 각 노드 간 Corosync 통신, 공유 스토리지, 펜싱 장치 연결 구조를 보여줍니다.

    Proxmox 클러스터 HA, 쉽게 말하면 이겁니다

    처음 Proxmox를 접하시는 분들은 클러스터니 HA니 하는 말들이 좀 낯설 수 있어요. 저도 처음엔 그랬거든요. 하나씩 풀어볼게요.

    클러스터(Cluster)란?

    쉽게 말해서, 여러 대의 물리 서버(노드)를 하나처럼 묶어서 관리하는 구성이에요. Proxmox에서는 최소 3대의 노드가 있어야 제대로 된 클러스터를 구성할 수 있어요. 2대로도 가능하긴 한데, 쿼럼(Quorum, 의사결정 정족수) 문제가 생겨서 실무에서는 권장하지 않습니다.

    HA(High Availability, 고가용성)란?

    클러스터 위에서 동작하는 기능인데요. 특정 노드가 장애가 나면 그 위에서 돌아가던 VM이나 컨테이너를 자동으로 다른 노드에서 재시작해주는 거예요. 사람이 개입하지 않아도 된다는 게 핵심이죠.

    구성 요소 역할 없으면?
    Corosync 노드 간 클러스터 통신 및 하트비트(heartbeat) 관리 노드 상태 파악 불가
    Pve-cluster (pmxcfs) 클러스터 파일시스템, 설정 동기화 설정 불일치 발생
    HA Manager VM/CT 자동 복구 로직 담당 자동 페일오버(failover) 불가
    Fencing (펜싱) 장애 노드를 강제로 격리하는 메커니즘 스플릿 브레인(split-brain) 위험
    공유 스토리지 노드 간 VM 디스크 이미지 공유 HA 적용 대상 VM 제한

    여기서 펜싱(Fencing)이 제일 중요한데, 많은 분들이 이걸 빼먹고 설정하다가 나중에 낭패를 보더라고요. 장애 노드가 실제로 죽었는지, 아니면 네트워크만 끊긴 건지 확인하고 강제로 전원을 끄거나 격리하는 장치예요. 없으면 같은 VM이 두 노드에서 동시에 실행되는 최악의 상황이 생길 수 있거든요.

    사전 준비: Proxmox 클러스터 구성 전 필수 체크사항

    본격적인 설정 전에 체크해야 할 항목들이 있어요. 이거 안 하고 넘어가면 나중에 반드시 삽질하게 됩니다. 제가 보장합니다 ㅎㅎ.

    • 노드 수: 최소 3개 (홀수 권장 — 쿼럼 계산 때문에)
    • Proxmox VE 버전: 모든 노드가 동일한 버전이어야 함 (2026년 기준 PVE 8.x)
    • 네트워크: 클러스터 통신용 전용 네트워크 분리 권장 (1Gbps 이상)
    • 시간 동기화: NTP 설정 필수 — 시간이 틀리면 Corosync가 미칩니다
    • 공유 스토리지: Ceph, NFS, iSCSI 등 — HA가 적용될 VM 디스크는 반드시 공유 스토리지에 있어야 해요
    • 호스트명/DNS: 각 노드의 호스트명이 서로 해석 가능해야 함

    저는 홈랩에서 pve-node1, pve-node2, pve-node3 이렇게 3대로 구성하고 있고, 클러스터 통신은 별도의 10.10.10.0/24 네트워크를 사용해요. 이거 분리 안 하면 VM 트래픽이랑 섞여서 하트비트 지연이 생기거든요.

    단계별 실전 구성: Proxmox 클러스터 HA 설정하기

    1단계: 클러스터 생성 (첫 번째 노드에서)

    pve-node1에서 클러스터를 생성합니다. GUI로 해도 되지만, CLI가 훨씬 빠르고 정확해요.

    # pve-node1에서 실행
pvecm create my-homelab-cluster --link0 10.10.10.1

# 클러스터 상태 확인
pvecm status

    --link0 옵션에는 클러스터 통신 전용 NIC의 IP를 넣어주세요. 메인 IP 쓰셔도 되긴 하는데, 분리하는 게 훨씬 안정적이더라고요.

    2단계: 나머지 노드 합류

    # pve-node2에서 실행
pvecm add 10.10.10.1 --link0 10.10.10.2

# pve-node3에서 실행
pvecm add 10.10.10.1 --link0 10.10.10.3

# node1에서 전체 노드 확인
pvecm nodes

    합류할 때 SSH 비밀번호 입력을 요구하는데, 이건 정상이에요. Proxmox가 SSH로 접속해서 인증서를 교환하는 과정이거든요.

    3단계: 공유 스토리지 설정 (Ceph 기준)

    저는 홈랩에서 Proxmox 내장 Ceph를 쓰는데, 설정이 생각보다 간단해졌어요. 특히 PVE 8.x부터는 GUI에서 거의 다 됩니다.

    # 각 노드에서 Ceph 패키지 설치
pveceph install --version reef

# Ceph 초기화 (node1에서)
pveceph init --network 10.10.20.0/24

# 모니터 데몬 추가 (각 노드에서)
pveceph mon create

# OSD(Object Storage Daemon) 추가 — /dev/sdb는 Ceph 전용 디스크
pveceph osd create /dev/sdb

# Ceph 풀(pool) 생성
pveceph pool create vm-pool --pg_num 128

# Proxmox 스토리지로 등록
pvesm add rbd ceph-storage --monhost 10.10.20.1,10.10.20.2,10.10.20.3 \
  --pool vm-pool --username admin --krbd 0

    Ceph 말고 NFS나 iSCSI를 쓰셔도 됩니다. 중요한 건 모든 노드에서 접근 가능한 공유 스토리지여야 한다는 거예요.

    4단계: 펜싱(Fencing) 설정

    이게 진짜 중요한데 많이들 건너뛰더라고요. 펜싱 없이 HA 쓰면 스플릿 브레인(split-brain) 상황에서 데이터 손상이 생길 수 있어요.

    가장 흔히 쓰는 방법은 IPMI/iDRAC/iLO 같은 BMC(Baseboard Management Controller, 원격 서버 관리 컨트롤러)를 이용한 펜싱이에요.

    # fence-agents 설치
apt install fence-agents

# 펜싱 테스트 (node2의 IPMI로 상태 확인)
fence_ipmilan -a 192.168.1.102 -l admin -p yourpassword -o status

    홈랩처럼 IPMI가 없는 환경이라면 WoL(Wake-on-LAN)이나 스마트 플러그를 이용한 펜싱도 가능해요. 완벽하진 않지만 없는 것보단 낫거든요.

    Proxmox HA Manager 설정 화면 및 리소스 그룹 구성

    ▲ Proxmox VE GUI의 HA Manager 화면 — 리소스 그룹 설정, VM 상태, 펜싱 구성을 한눈에 확인할 수 있습니다.

    5단계: HA 리소스 그룹 및 VM 등록

    드디어 본론이에요! HA 매니저에 VM을 등록해봅시다.

    # HA 그룹 생성 (특정 노드에 우선순위 부여)
ha-manager groupadd prod-group \
  --nodes "pve-node1:3,pve-node2:2,pve-node3:1" \
  --restricted 0 \
  --nofailback 0

# VM 100번을 HA 리소스로 등록
ha-manager add vm:100 \
  --group prod-group \
  --max_restart 3 \
  --max_relocate 2

# HA 상태 확인
ha-manager status

# 특정 VM의 HA 설정 확인
ha-manager config vm:100

    여기서 --max_restart는 같은 노드에서 재시작 시도 횟수, --max_relocate는 다른 노드로 이전 시도 횟수예요. 너무 크게 잡으면 장애 상황에서 복구가 지연될 수 있으니 적당히 설정하세요.

    GUI로 하시려면 Datacenter → HA → Add 메뉴에서 쉽게 할 수 있어요. 저도 처음 설정할 때는 GUI로 감 잡고, 이후에는 CLI로 자동화하는 편이에요.

    6단계: HA 서비스 활성화 확인

    # HA 관련 서비스 상태 확인
systemctl status pve-ha-lrm  # Local Resource Manager
systemctl status pve-ha-crm  # Cluster Resource Manager
systemctl status corosync
systemctl status pve-cluster

# 클러스터 전체 상태 한 번에 확인
pvecm status
ha-manager status

    ⚠️ 실제로 겪은 Proxmox HA 트러블슈팅 사례들

    설정하다 보면 반드시 뭔가 꼬이는 순간이 와요. 제가 겪은 것들 공유할게요.

    문제 1: 쿼럼 손실 (Quorum Lost)

    노드 하나 내렸더니 클러스터 전체가 멈춰버린 적 있었어요. 3노드 중 1개만 내렸는데도요.

    # 쿼럼 상태 확인
pvecm status | grep Quorum

# 긴급 상황에서 쿼럼 강제 설정 (절대 프로덕션에서 함부로 쓰지 마세요!)
# 이건 정말 최후의 수단입니다
pvecm expected 1

    원인은 Corosync 링크 설정이 잘못돼 있었어요. /etc/corosync/corosync.conf에서 링크 주소가 메인 IP로 잡혀있던 거였죠. 클러스터 전용 IP로 수정하고 나서 해결됐습니다.

    문제 2: VM이 HA 대상이 안 되는 경우

    VM 디스크가 로컬 스토리지에 있으면 HA 등록 자체가 안 돼요. 반드시 공유 스토리지로 이전해야 합니다.

    # VM 100의 디스크를 로컬에서 Ceph로 마이그레이션
qm move-disk 100 scsi0 ceph-storage --delete 1

# 마이그레이션 후 디스크 위치 확인
qm config 100 | grep scsi

    문제 3: 펜싱 실패로 HA가 동작 안 하는 경우

    이건 진짜 당황스러웠어요. 노드가 죽었는데 VM이 다른 노드로 안 넘어가는 거예요. 로그 확인해보니 펜싱 에이전트가 응답을 못 받아서 HA 매니저가 안전하게 대기 중인 거였어요.

    # HA 매니저 로그 확인
journalctl -u pve-ha-crm -f
journalctl -u pve-ha-lrm -f

# 펜싱 에이전트 직접 테스트
fence_ipmilan -a [IPMI_IP] -l [USER] -p [PASS] -o status

# 수동 펜싱 (테스트용)
fence_ipmilan -a [IPMI_IP] -l [USER] -p [PASS] -o reboot

    결국 IPMI 비밀번호가 변경됐던 게 문제였어요. 펜싱 설정도 업데이트해주니까 바로 해결됐습니다. 이런 거 있을 줄은… ㅎㅎ

    문제 4: 시간 동기화 문제

    # NTP 상태 확인
timedatectl status
chronyc tracking

# /etc/chrony/chrony.conf 설정
pool ntp.ubuntu.com iburst
pool time.cloudflare.com iburst

# chrony 재시작
systemctl restart chronyd

    HA 동작 검증: 실제로 노드를 꺼봤습니다

    설정만 하고 테스트 안 하면 진짜 장애 때 믿을 수 없잖아요. 저는 분기마다 한 번씩 의도적으로 노드를 내려서 HA가 제대로 동작하는지 확인해요.

    1. 테스트할 노드에서 실행 중인 HA VM 확인
    2. 해당 노드의 전원을 강제로 차단 (graceful shutdown이 아닌 hard power off)
    3. HA 매니저가 장애를 감지하고 VM을 다른 노드에서 재시작하는 시간 측정
    4. 서비스 가용성 확인
    # 다른 노드에서 HA 복구 과정 실시간 모니터링
watch -n 2 'ha-manager status; echo "---"; pvecm status'

# VM ping 테스트로 다운타임 측정
ping -i 0.5 [VM_IP] | ts '%H:%M:%.S'

# 복구 후 VM이 어느 노드에서 실행 중인지 확인
qm status 100
pct status 200
    Proxmox HA 페일오버 테스트 결과 대시보드

    ▲ HA 페일오버 테스트 결과 — 노드 장애 감지부터 VM 재시작 완료까지 약 90초 소요, ping 손실 패킷 수와 복구 타임라인을 시각화한 모니터링 화면입니다.

    제 환경에서는 보통 60~120초 안에 VM이 다른 노드에서 살아납니다. 이 시간은 fence_delay, ha-manager의 타임아웃 설정에 따라 달라지는데, 너무 짧게 잡으면 일시적인 네트워크 끊김에도 불필요한 페일오버가 발생하니 주의하세요.

    VM 백업과 HA: 같이 챙겨야 합니다

    HA가 있다고 백업을 소홀히 하면 안 돼요. HA는 하드웨어 장애에 대한 자동 복구지, 데이터 손실에 대한 보호는 아니거든요. 스토리지 자체가 날아가면 HA도 소용없습니다.

    # Proxmox Backup Server(PBS)를 이용한 자동 백업 설정
# /etc/pve/jobs.cfg에 추가되거나 GUI에서 설정 가능

# vzdump으로 VM 백업 (CLI)
vzdump 100 --storage pbs-storage --mode snapshot --compress zstd

# 백업 스케줄 확인
pvesched list

    저는 Proxmox Backup Server(PBS)를 별도 머신에 구축해서 매일 새벽 2시에 자동 백업 돌리고 있어요. VM 백업 관련해서는 별도 글로 자세히 다룰 예정이니 참고해 주세요.

    정리: Proxmox 클러스터 HA 완성 체크리스트

    Proxmox 클러스터 HA 설정 체크리스트 및 아키텍처 요약 인포그래픽

    ▲ Proxmox VE 클러스터 HA 구성 완료 체크리스트 — 클러스터 생성부터 펜싱, 공유 스토리지, HA 리소스 등록, 백업까지 단계별 요약 인포그래픽입니다.

    단계 항목 상태
    1 3개 이상 노드 준비, 동일 PVE 버전 ✅ 필수
    2 클러스터 전용 네트워크 분리 ✅ 강력 권장
    3 NTP 시간 동기화 설정 ✅ 필수
    4 공유 스토리지 구성 (Ceph/NFS/iSCSI) ✅ 필수
    5 펜싱 에이전트 설정 및 테스트 ✅ 필수
    6 HA 그룹 및 리소스 등록 ✅ 필수
    7 실제 페일오버 테스트 ✅ 필수
    8 VM 백업 스케줄 설정 ✅ 강력 권장

    마치며: 장애는 반드시 옵니다

    13년 동안 인프라 일을 하면서 배운 게 있다면, 장애는 일어나지 않는 게 아니라 언제 일어나느냐의 문제라는 거예요. Proxmox 클러스터 HA는 그 순간을 위한 보험이에요.

    처음 설정할 때는 복잡해 보이지만, 한 번 제대로 구성해두면 정말 든든합니다. 새벽 3시 전화 받고도 “어, 자동으로 넘어갔네” 하고 다시 잘 수 있거든요. 그 경험, 정말 소중하더라고요.

    궁금한 점이 있으시면 댓글로 남겨주세요. 다음 글에서는 Proxmox에서 Ceph 스토리지 세부 튜닝과 PBS(Proxmox Backup Server) 구축을 다룰 예정이에요. 이 두 가지가 HA랑 같이 있으면 진짜 완성된 인프라가 됩니다. 기대해 주세요! 🎉

    자주 묻는 질문 (FAQ)

    Q. Proxmox HA는 몇 대부터 가능한가요?

    기술적으로는 2대도 가능하지만, 쿼럼 구성을 위해 최소 3대를 강력히 권장합니다. 2대 구성은 한 노드가 죽으면 쿼럼을 잃어 클러스터가 동작을 멈춰요. QDevice(외부 쿼럼 장치)를 쓰면 2노드도 어느 정도 보완이 가능하더라고요.

    Q. 펜싱 장치가 없으면 HA를 쓰면 안 되나요?

    공식적으로는 펜싱 없이도 동작하지만, 프로덕션 환경에서는 절대 권장하지 않아요. 펜싱 없이 HA를 쓰면 스플릿 브레인 상황에서 데이터 손상이 발생할 수 있거든요. 홈랩이라면 소프트웨어 펜싱이나 스마트 플러그로라도 구성하세요.

    Q. HA VM의 라이브 마이그레이션(Live Migration)과 HA 페일오버의 차이는?

    라이브 마이그레이션은 VM이 실행 중인 상태에서 다운타임 없이 다른 노드로 이전하는 거예요. HA 페일오버는 노드 장애 시 VM을 다른 노드에서 재시작하는 거라 약간의 다운타임이 발생해요. 라이브 마이그레이션은 계획된 유지보수에, HA는 비계획 장애 대응에 쓰입니다.

  • [Proxmox] GPU 패스스루 설정 완벽 가이드: 게임 및 AI 워크로드 최적화

    [Proxmox] GPU 패스스루 설정 완벽 가이드: 게임 및 AI 워크로드 최적화

    목차

    GPU 패스스루, 처음엔 저도 막막했습니다

    홈랩을 운영하다 보면 언젠가 한 번쯤 이런 생각이 드시죠. “Proxmox VE에서 GPU를 VM에 직접 붙여서 쓸 수 있지 않을까?” 저도 딱 그 생각으로 시작했거든요. RTX 3080을 꽂아놓고 VM 하나는 게임용, 다른 하나는 AI 학습용으로 쓰고 싶었는데… 처음엔 진짜 삽질 좀 했습니다 ㅎㅎ

    IOMMU 설정이 뭔지도 몰랐고, VFIO 드라이버가 왜 필요한지도 감이 없었어요. 근데 막상 해보니까 순서대로 따라가면 생각보다 어렵지 않더라고요. 오늘은 제가 직접 삽질하면서 정리한 Proxmox GPU 패스스루 설정 방법을 처음부터 끝까지 공유해드리려고 합니다. 게임 VM이든 AI 워크로드용 VM이든, 이 가이드 하나면 충분히 따라오실 수 있을 거예요.

    Proxmox VE GPU 패스스루 전체 아키텍처 다이어그램 - IOMMU와 VFIO를 통한 가상머신 GPU 할당 구조

    ▲ Proxmox VE에서 GPU 패스스루가 동작하는 전체 구조. 호스트 OS는 GPU를 직접 쓰지 않고, VFIO를 통해 VM에 전달합니다.

    GPU 패스스루(Passthrough)란 뭔가요?

    쉽게 말해서, 물리 GPU를 가상머신(VM)이 마치 실제 자기 하드웨어인 것처럼 직접 쓸 수 있게 해주는 기술이에요. 일반적인 가상화에서는 GPU를 소프트웨어로 에뮬레이션하거나, Virtio 같은 반가상화 드라이버를 써서 성능 손실이 꽤 있거든요.

    근데 Proxmox GPU 패스스루를 쓰면? 거의 베어메탈(Bare-metal, 운영체제 없이 하드웨어에 직접 설치한 환경) 수준의 GPU 성능이 나와요. 실제로 제가 테스트해봤을 때 3D Mark 점수가 네이티브 대비 98% 수준이 나왔거든요. 이거 처음 봤을 때 진짜 “오, 이게 되네” 싶었습니다.

    핵심 기술 두 가지만 기억하시면 됩니다:

    • IOMMU (Input-Output Memory Management Unit): CPU와 메인보드가 지원해야 하는 하드웨어 기능. Intel은 VT-d, AMD는 AMD-Vi라고 부릅니다. 쉽게 말해 “VM이 특정 하드웨어만 독점적으로 쓸 수 있게 격리해주는 기능”이에요.
    • VFIO (Virtual Function I/O): Linux 커널의 드라이버 프레임워크. 실제 GPU 드라이버 대신 이 녀석이 GPU를 잡아서 VM에게 넘겨주는 역할을 합니다.

    이 두 가지가 핵심이에요. IOMMU가 하드웨어 레벨 격리를 해주고, VFIO가 그 격리된 장치를 VM에 연결해주는 구조죠.

    사전 준비: 하드웨어 호환성 확인

    설정 들어가기 전에 먼저 체크해야 할 것들이 있어요. 여기서 막히면 아무것도 안 되거든요. 저도 처음에 이 확인을 건너뛰었다가 몇 시간 날린 적 있습니다 ㅠㅠ

    필수 확인 사항

    1. CPU 가상화 지원 확인: Intel VT-d 또는 AMD-Vi 지원 여부
    2. 메인보드 BIOS에서 IOMMU 활성화: 대부분 “Intel Virtualization for Directed I/O” 또는 “AMD IOMMU” 옵션으로 있음
    3. GPU 종류 확인: NVIDIA의 경우 Consumer GPU(RTX/GTX)는 Code 43 오류 이슈가 있어서 추가 설정 필요 (뒤에서 다룰게요)
    4. GPU가 별도 IOMMU 그룹에 있는지 확인: 같은 그룹에 다른 중요한 장치가 묶여 있으면 복잡해집니다

    IOMMU 그룹 확인하는 명령어는 이거예요. Proxmox 호스트에서 실행하시면 됩니다:

    #!/bin/bash
# IOMMU 그룹별 장치 목록 확인
for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'IOMMU Group %s ' "$n"
  lspci -nns "${d##*/}"
done

    실행하면 이런 식으로 나와요. GPU가 혼자 또는 HDMI 오디오 장치랑만 같은 그룹에 있으면 이상적입니다:

    IOMMU Group 14 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3080] [10de:2206]
IOMMU Group 14 01:00.1 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef]

    Proxmox VE GPU 패스스루 설정: 단계별 가이드

    자, 이제 본격적으로 Proxmox GPU 패스스루 설정을 시작해볼게요. Proxmox VE 8.x 기준으로 작성했습니다. 7.x도 거의 동일한데, 일부 파일 경로가 다를 수 있어요.

    1단계: GRUB 부트로더에 IOMMU 활성화

    먼저 Proxmox 호스트의 GRUB 설정을 수정해야 해요. /etc/default/grub 파일을 열어서 수정합니다:

    # Intel CPU의 경우
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

# AMD CPU의 경우
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

    💡 팁: iommu=pt 옵션(Passthrough mode)을 꼭 같이 넣어주세요. 이게 있어야 IOMMU를 사용하지 않는 장치들의 성능 저하를 막을 수 있거든요. 저도 처음엔 이걸 빠뜨렸다가 네트워크 속도가 뚝 떨어지는 경험을 했습니다.

    # GRUB 업데이트
update-grub

    2단계: VFIO 커널 모듈 로드 설정

    /etc/modules 파일에 VFIO 관련 모듈을 추가해줍니다:

    vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

    3단계: GPU를 VFIO에 바인딩

    이게 핵심이에요. GPU의 PCI ID를 확인해서 VFIO 드라이버가 이 GPU를 잡도록 설정합니다.

    먼저 GPU의 PCI ID를 확인합니다:

    lspci -nn | grep -i nvidia
# 또는 AMD GPU의 경우
lspci -nn | grep -i amd

    출력 예시:

    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [10de:2206]
01:00.1 Audio device [0403]: NVIDIA Corporation HD Audio [10de:1aef]

    여기서 [10de:2206]과 [10de:1aef]가 PCI ID예요. 이걸 /etc/modprobe.d/vfio.conf 파일에 등록합니다:

    options vfio-pci ids=10de:2206,10de:1aef disable_vga=1

    그리고 NVIDIA 드라이버가 먼저 GPU를 잡아버리지 못하도록 블랙리스트에 등록합니다. /etc/modprobe.d/blacklist.conf에 추가:

    blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm

    설정 적용 후 재부팅합니다:

    update-initramfs -u -k all
reboot

    재부팅 후 VFIO가 GPU를 제대로 잡았는지 확인:

    lspci -nnk -d 10de:2206
# Kernel driver in use: vfio-pci 라고 나오면 성공!
    Proxmox VE 웹 인터페이스 VM 하드웨어 설정 화면 - GPU PCI 패스스루 설정 옵션

    ▲ Proxmox VE 웹 인터페이스에서 VM에 GPU를 PCI 장치로 추가하는 화면. “All Functions”와 “Primary GPU” 옵션 설정이 핵심입니다.

    4단계: Proxmox VM 설정

    이제 VM에 GPU를 붙일 차례예요. Proxmox 웹 UI에서 해도 되고, 명령어로 해도 됩니다. 저는 명령어가 더 정확해서 선호하는 편이에요.

    VM 설정 파일 /etc/pve/qemu-server/[VM ID].conf에 다음 내용을 추가합니다:

    # 기본 VM 설정
cpu: host,hidden=1,flags=+pcid
bios: ovmf
machine: q35

# GPU 패스스루 설정 (VMID 100 기준)
hostpci0: 0000:01:00,allFunctions=1,pcie=1,rombar=1,x-vga=1

# 가상 디스플레이는 none으로 (GPU 직접 쓸 거니까)
vga: none

    ⚠️ 중요한 포인트! 몇 가지 옵션 설명드릴게요:

    • cpu: host,hidden=1: NVIDIA Consumer GPU의 Code 43 오류 방지. VM에게 가상화 환경임을 숨겨줍니다
    • bios: ovmf: UEFI 펌웨어. GPU 패스스루에는 OVMF(Open Virtual Machine Firmware)가 거의 필수에요
    • machine: q35: PCIe 지원이 되는 칩셋 에뮬레이션 타입
    • allFunctions=1: GPU와 HDMI 오디오 등 연관 함수를 모두 같이 패스스루

    5단계: Windows VM에서 드라이버 설치

    VM을 부팅하면 처음에는 디스플레이가 안 보여서 당황할 수 있어요. 이건 정상입니다! 처음 부팅 때는 Proxmox 웹 콘솔(noVNC)로 접속해서 Windows를 설치하고, 이후 NVIDIA 드라이버를 설치하면 돼요.

    Windows 설치 후 장치 관리자에서 GPU가 제대로 잡혔는지 확인하고, NVIDIA 공식 사이트에서 드라이버를 받아 설치합니다. 드라이버 설치 완료 후 재부팅하면 GPU가 정상 작동하는 걸 확인할 수 있어요.

    ⚠️ 삽질 모음: 이런 문제들 겪으실 수 있어요

    제가 진짜 고생했던 문제들이에요. 미리 알고 계시면 시간을 많이 아낄 수 있습니다.

    문제 1: NVIDIA Code 43 오류

    Consumer GPU(RTX/GTX 시리즈)는 VM 환경을 감지하면 드라이버가 Code 43 오류를 내뿜어요. NVIDIA가 의도적으로 막아놓은 거거든요 (Quadro나 Tesla는 이런 제한 없어요).

    해결 방법: 위에서 언급한 hidden=1 옵션에 더해서, VM 설정 파일에 다음을 추가합니다:

    args: -cpu 'host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_vendor_id=NvidiaFTW,kvm=off'

    hv_vendor_id 값은 아무 문자열이나 넣어도 되는데, 12자 이내여야 해요. 이렇게 하면 VM이 가상화 환경임을 NVIDIA 드라이버가 눈치채지 못합니다.

    문제 2: IOMMU 그룹 분리 문제 (ACS Override)

    가끔 GPU가 다른 장치들이랑 같은 IOMMU 그룹에 묶여 있는 경우가 있어요. 이럴 때 패스스루를 하면 같은 그룹의 다른 장치들도 VM에 넘겨야 하는 문제가 생기죠.

    해결 방법: ACS(Access Control Services) 오버라이드 패치를 사용합니다. Proxmox에서는 커널 파라미터로 해결할 수 있어요:

    # /etc/default/grub 수정
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

    ⚠️ 단, ACS 오버라이드는 보안상 위험이 있을 수 있으니 홈랩 환경에서만 사용 권장합니다.

    문제 3: 재부팅 후 VM이 GPU를 못 찾는 경우

    이건 VFIO 모듈이 NVIDIA 드라이버보다 늦게 로드되어서 생기는 문제예요. /etc/modprobe.d/vfio.conf에 다음을 추가하면 해결됩니다:

    softdep nvidia pre: vfio-pci
softdep nouveau pre: vfio-pci

    AI 워크로드 최적화: Proxmox에서 다르게 접근하기

    게임 VM은 단일 VM에 GPU 하나를 통째로 주면 끝인데, AI 워크로드 Proxmox 환경에서는 조금 다른 접근이 필요할 수 있어요. 특히 여러 VM이 GPU를 나눠 써야 하는 경우에는 MIG(Multi-Instance GPU)나 vGPU 같은 옵션도 고려해볼 수 있거든요.

    방식 성능 VM 수 적합한 용도 비고
    GPU 패스스루 ★★★★★ 1개 VM 독점 게임, 단일 AI 학습 무료, 설정 복잡
    vGPU ★★★★☆ 여러 VM 공유 AI 추론, VDI 라이선스 비용 발생
    MIG ★★★★☆ 최대 7개 분할 AI 추론, 멀티 테넌트 A100/H100만 지원
    소프트웨어 에뮬레이션 ★☆☆☆☆ 제한 없음 테스트 용도만 무료, 성능 매우 낮음

    AI 워크로드를 Proxmox에서 돌릴 때 제가 실제로 쓰는 설정을 공유드릴게요. GPU 패스스루 VM에서 CUDA 작업을 할 때 성능을 최대화하는 CPU 핀닝(CPU Pinning, 특정 VM의 CPU를 물리 코어에 고정하는 기술) 설정입니다:

    # VM 설정 파일에 추가
# 8코어 CPU 핀닝 예시 (물리 코어 0-7을 VM에 할당)
cpuunits: 1024
numa: 1

# 명령어로 CPU 핀닝 설정
qm set 100 --cpu host --cores 8 --sockets 1

# HugePages 설정 (메모리 성능 향상)
# /etc/sysctl.conf에 추가
vm.nr_hugepages = 4096
    Proxmox GPU 패스스루 AI 워크로드 성능 비교 벤치마크 - 네이티브 대비 95% 이상 성능 달성

    ▲ Proxmox GPU 패스스루 환경에서 AI 학습 워크로드 성능 비교. 패스스루 방식이 네이티브 대비 95% 이상의 성능을 보여줍니다.

    ✅ 설정 완료 후 검증 방법

    설정이 다 끝났다면 제대로 됐는지 확인해봐야죠. 제가 항상 하는 검증 순서를 알려드릴게요.

    호스트 측 검증

    # IOMMU가 활성화됐는지 확인
dmesg | grep -e DMAR -e IOMMU
# "IOMMU enabled" 메시지가 보이면 OK

# VFIO가 GPU를 잡았는지 확인
lspci -nnk | grep -A 3 "NVIDIA"
# "Kernel driver in use: vfio-pci" 가 나와야 함

# IOMMU 그룹 확인
find /sys/kernel/iommu_groups/ -type l | sort -V

    VM 내부(Windows) 검증

    1. 장치 관리자에서 GPU가 정상 인식되는지 확인 (노란 느낌표 없어야 함)
    2. GPU-Z 툴로 실제 GPU 정보가 올바르게 표시되는지 확인
    3. 3D Mark 벤치마크로 성능 측정 (네이티브 대비 95% 이상이면 성공)

    AI 워크로드 검증 (Linux VM)

    # NVIDIA 드라이버 및 CUDA 확인
nvidia-smi

# PyTorch에서 GPU 인식 확인
python3 -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

# GPU 메모리 대역폭 테스트
nvidia-smi dmon -s u

    🎉 드디어 됐다! 저도 처음 nvidia-smi에서 RTX 3080이 뜨는 거 봤을 때 얼마나 기뻤는지 모릅니다. 몇 시간의 삽질이 한 번에 보상받는 느낌이랄까요.

    마무리: Proxmox GPU 패스스루 설정 완벽 가이드

    Proxmox VE GPU 패스스루 설정 단계 요약 인포그래픽 - BIOS부터 VM 설정까지 5단계 과정

    ▲ Proxmox VE GPU 패스스루 설정 전체 과정 요약. BIOS → GRUB → VFIO → VM 설정 순서로 진행하면 됩니다.

    오늘 다룬 내용을 간단히 정리해드릴게요:

    • ✅ BIOS에서 IOMMU(VT-d/AMD-Vi) 활성화
    • ✅ GRUB에 intel_iommu=on iommu=pt 파라미터 추가
    • ✅ VFIO 모듈 등록 및 GPU PCI ID 바인딩
    • ✅ NVIDIA 드라이버 블랙리스트 처리
    • ✅ VM을 Q35 + OVMF 조합으로 설정
    • ✅ Consumer GPU는 hidden=1 + hv_vendor_id로 Code 43 우회

    솔직히 말씀드리면, GPU 패스스루는 처음 한 번 성공하고 나면 그다음부터는 별거 아니에요. 근데 그 처음 한 번이 진짜 험난하죠 ㅎㅎ 이 가이드가 그 험난한 여정을 조금이라도 줄여드렸으면 좋겠습니다.

    AI 워크로드로 활용하실 분들은 다음 단계로 Proxmox에서 Kubernetes 클러스터를 구성하고 GPU 노드를 연결하는 방법도 다룰 예정이에요. 그쪽이 진짜 재미있거든요. 그리고 vGPU 설정에 관심 있으신 분들은 이전 글에서 NVIDIA GRID 드라이버 설치 방법도 다뤘으니 참고해보세요.

    혹시 설정하다가 막히는 부분 있으시면 댓글로 남겨주세요. 제가 겪어본 삽질은 거의 다 공유해드릴 수 있을 것 같습니다 😄

    자주 묻는 질문 (FAQ)

    Q. RTX 4090도 Proxmox GPU 패스스루가 되나요?

    네, 됩니다! 다만 RTX 40 시리즈는 PCIe 5.0을 쓰는데, 메인보드와 Proxmox 버전에 따라 일부 추가 설정이 필요할 수 있어요. 기본 흐름은 동일합니다.

    Q. 하나의 GPU를 여러 VM이 동시에 쓸 수 있나요?

    일반 패스스루로는 불가능해요. 동시에 여러 VM이 쓰려면 NVIDIA vGPU(유료 라이선스) 또는 A100/H100의 MIG 기능을 사용해야 합니다.

    Q. 패스스루 후 호스트에서 GPU를 모니터로 쓸 수 있나요?

    VFIO에 바인딩된 GPU는 호스트에서 사용할 수 없어요. 보통 온보드 그래픽이나 별도 저가형 GPU를 호스트 디스플레이용으로 쓰고, 메인 GPU는 패스스루용으로 분리하는 방식을 많이 씁니다.

    Q. Proxmox 8 버전에서도 동일하게 적용되나요?

    네, 이 가이드는 Proxmox VE 8.x 기준으로 작성됐습니다. 7.x도 거의 동일하고, 6.x는 일부 모듈 이름이 다를 수 있어요.