13년차의 서버실

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

[태그:] VM 백업

  • [Proxmox] Proxmox Backup Server (PBS) vs. 스크립트 백업: 홈랩 비용 효율성 비교

    [Proxmox] Proxmox Backup Server (PBS) vs. 스크립트 백업: 홈랩 비용 효율성 비교

    홈랩 백업, 정말 고민되시죠? Proxmox Backup Server (PBS) vs. 스크립트 백업 비용 효율성 비교

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 가장 중요하게 생각하는 것 중 하나가 바로 백업(Backup)입니다. 아니, 중요하게 생각해야만 하는 것이죠. 처음엔 저도 ‘설마 내 데이터가 날아가겠어?’ 하는 안일한 생각으로 버텼습니다. 그러다 한 번 크게 데이터 유실(Data Loss)을 겪고 나서야 정신을 차렸죠. 그 이후로 백업은 제 홈랩 운영의 제1원칙이 되어 버렸습니다.

    특히 Proxmox VE(Virtual Environment)를 사용하시는 분들이라면, 가상 머신(VM)이나 컨테이너(LXC) 백업에 대한 고민이 많으실 거예요. 스냅샷(Snapshot)만 믿고 계신 건 아니겠죠? 스냅샷은 편리하지만, 물리적 저장 장치에 문제가 생기면 함께 날아간다는 치명적인 단점이 있습니다. 그래서 별도의 백업 솔루션이 필수적인데, 여기서 많은 분들이 Proxmox Backup Server (PBS)를 쓸지, 아니면 스크립트 기반의 백업을 직접 구현할지 고민하시더라고요. 저도 그랬거든요!

    오늘은 13년차 인프라 엔지니어의 경험을 바탕으로 이 두 가지 Proxmox 백업 전략의 비용 효율성(Cost Efficiency)을 비교 분석해보고, 홈랩 환경에서 어떤 선택이 더 현명할지 함께 이야기해보려 합니다. 특히 Proxmox Backup Server 비용에 대한 오해도 풀어드릴게요!

    Proxmox Backup Server와 스크립트 백업 아키텍처 비교 다이어그램

    Proxmox Backup Server와 기존 스크립트 백업 솔루션을 비교하는 개략적인 아키텍처 다이어그램입니다. 각 방식의 데이터 흐름과 구성 요소를 시각적으로 보여줍니다.

    Proxmox Backup Server (PBS)와 스크립트 백업, 뭐가 다를까요?

    우선 두 가지 방식의 핵심 개념부터 간단히 짚고 넘어가겠습니다. 쉽게 말해 이렇습니다.

    • Proxmox Backup Server (PBS): Proxmox 개발사에서 공식적으로 제공하는 전용 백업 솔루션이죠. Proxmox VE와 완벽하게 통합되어 VM, LXC 백업 및 복원을 쉽고 효율적으로 처리할 수 있도록 설계되었습니다.
    • 스크립트 백업 (Script Backup): rsync, dd, tar 같은 리눅스 명령어나 Proxmox VE 자체의 vzdump 명령어를 활용하여 직접 스크립트를 짜서 백업을 수행하는 방식입니다. 특정 백업 스토리지를 마운트해서 데이터를 밀어 넣는 형태가 되겠죠.

    PBS의 가장 큰 장점은 바로 중복 제거(Deduplication)와 증분 백업(Incremental Backup)입니다. 예를 들어, 제가 Ubuntu VM을 여러 개 돌리고 있는데, 얘네들이 대부분 비슷한 OS 파일을 가지고 있잖아요? PBS는 이 중복되는 블록을 한 번만 저장하고, 변경된 부분만 추가로 저장해서 저장 공간을 엄청나게 절약해줍니다. 그리고 백업 데이터의 무결성 검사(Data Integrity Check) 기능도 강력해서, 백업 데이터가 손상되지 않았는지 주기적으로 확인해주는 점도 정말 마음이 놓이더라고요.

    반면 스크립트 백업은 모든 것을 직접 제어할 수 있다는 장점이 있습니다. 원하는 대로 커스터마이징(Customizing)이 가능하고, 이미 있는 리소스(Resource)를 활용해서 추가적인 소프트웨어 설치 없이 바로 사용할 수 있거든요. 하지만 중복 제거 같은 고급 기능은 직접 구현하기 어렵고, 백업 데이터의 관리가 번거로울 수 있습니다.

    PBS, 직접 써보니 이렇더라고요! (실전 구현)

    제가 PBS를 처음 써봤을 때 느꼈던 감정은 ‘와, 이거 진짜 편하네!’ 였습니다. 사실 처음엔 PBS를 위한 별도의 서버나 VM을 구성해야 한다는 생각에 약간의 진입 장벽을 느꼈거든요. ‘그냥 vzdump로 NAS에 밀어 넣으면 안 되나?’ 싶었죠. 근데 PBS를 설치하고 Proxmox VE에 백업 스토리지로 연결해보니, 그 편리함에 금세 빠져들었습니다.

    설치 자체는 Proxmox VE와 마찬가지로 ISO 이미지를 통해 쉽게 할 수 있습니다. 혹은 기존 리눅스 서버에 패키지로 설치하는 것도 가능하더라고요. 저는 홈랩에서 쓰지 않는 미니 PC에 PBS를 설치하거나, Proxmox VE 위에 하나의 VM으로 올려서 사용하기도 했습니다. (물론 이 경우 백업 대상 VM과 동일한 물리 서버에 있으면 안 되겠죠?)

    # PBS 설치 후 Proxmox VE에서 백업 스토리지 추가하는 예시
    # Datacenter -> Storage -> Add -> Proxmox Backup Server 선택
    # ID: pbs-backup
    # Server: [PBS 서버 IP 또는 도메인]
    # Port: 8007 (기본값)
    # Username: root@pam
    # Password: [PBS root 비밀번호]
    # Datastore: [PBS 데이터스토어 이름, 예: mybackup]
    

    이렇게 PBS 스토리지를 Proxmox VE에 연결하고 나면, 백업 스케줄(Backup Schedule)을 설정하는 게 정말 간단해집니다. 웹 UI에서 몇 번의 클릭만으로 특정 VM이나 모든 VM을 원하는 주기로 백업하도록 설정할 수 있어요. 압축(Compression) 알고리즘 선택부터 보존 정책(Retention Policy) 설정까지 GUI(Graphical User Interface)로 모든 걸 처리할 수 있다는 게 가장 큰 장점이죠. 백업이 성공적으로 완료되면 Proxmox VE 로그에도 잘 남고요. ✅

    Proxmox Backup Server 웹 인터페이스 백업 스케줄 설정

    Proxmox Backup Server의 웹 인터페이스에서 백업 스케줄을 설정하는 화면입니다. 직관적인 GUI를 통해 쉽게 백업 정책을 관리할 수 있습니다.

    스크립트 백업, 장단점 명확합니다 (실전 구현)

    PBS가 나오기 전, 그리고 지금도 많은 분들이 스크립트 백업을 사용하고 계십니다. 저 역시 PBS를 알기 전에는 주로 vzdump 명령어를 활용한 스크립트 백업을 애용했었죠. 다음은 간단한 스크립트 백업 예시입니다.

    #!/bin/bash
    
    # 백업 대상 VM/LXC ID
    VM_IDS="100 101 102"
    
    # 백업 저장 경로 (NFS 또는 SMB 마운트된 디렉토리)
    BACKUP_DIR="/mnt/pve/nas_backup/vzdump"
    
    # 백업 파일 보존 일수
    RETENTION_DAYS=7
    
    # 백업 실행
    for VM_ID in $VM_IDS;
    do
      echo "$(date '+%Y-%m-%d %H:%M:%S') - Starting backup for VM/LXC $VM_ID..."
      vzdump $VM_ID --mode snapshot --compress zstd --storage local-lvm --dumpdir $BACKUP_DIR
      if [ $? -eq 0 ]; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup for VM/LXC $VM_ID completed successfully."
      else
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup for VM/LXC $VM_ID failed!" >&2
      fi
    done
    
    # 오래된 백업 파일 삭제 (보존 정책)
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Cleaning up old backup files..."
    find $BACKUP_DIR -type f -name "vzdump-*.vma.zst" -mtime +$RETENTION_DAYS -delete
    
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup script finished."
    

    이 스크립트를 cron에 등록해서 주기적으로 실행하면, 원하는 VM들을 백업할 수 있습니다. 장점은 명확해요. 자유로운 커스터마이징이 가능하고, 별도의 소프트웨어 설치 없이 Proxmox VE에 내장된 기능만으로 백업을 구현할 수 있다는 점이죠. 기존에 가지고 있던 NAS나 여분의 하드디스크를 마운트해서 백업 저장소로 활용하기도 좋습니다.

    하지만 단점도 있습니다. ⚠️

    • 중복 제거 기능 부재: VM이 많아질수록 백업 공간을 비효율적으로 사용하게 됩니다.
    • 수동 관리의 번거로움: 스크립트 오류, 저장 공간 부족, 백업 성공 여부 확인 등을 직접 관리하고 모니터링해야 합니다.
    • 복원 과정의 복잡성: PBS처럼 웹 UI에서 클릭 몇 번으로 복원하는 것이 아니라, 명령어를 사용해야 합니다.
    • 데이터 무결성 검사 부재: 백업 파일이 손상되었는지 주기적으로 확인하는 기능이 없습니다.

    특히 중복 제거 기능이 없다는 것은 Proxmox Backup Server 비용 측면에서 간과할 수 없는 부분입니다. 백업 데이터가 늘어나면 늘어날수록 더 많은 저장 장치(Storage)를 구매해야 할 수도 있거든요.

    스크립트 기반 백업 구성도 및 데이터 흐름

    스크립트 기반 백업의 구성도와 데이터 흐름을 보여주는 다이어그램입니다. Proxmox VE에서 백업 스크립트가 실행되어 외부 저장소로 데이터를 전송하는 과정을 나타냅니다.

    비용 효율성, 과연 어떤 선택이 현명할까요?

    자, 그럼 가장 중요한 비용 효율성 측면에서 PBS와 스크립트 백업을 비교해볼까요? 여기서 말하는 ‘비용’은 단순히 하드웨어 구매 비용뿐만 아니라, 시간(Time)과 노력(Effort)까지 포함한 개념입니다. 홈랩에서는 이 ‘시간’ 비용이 생각보다 훨씬 중요하거든요. 제 경험상 삽질하는 시간은 곧 기회비용입니다.

    기준 Proxmox Backup Server (PBS) 스크립트 백업
    초기 설정 시간 별도 서버/VM 구성 필요, Proxmox VE와 연동 용이 (중간) 스크립트 작성 및 테스트 필요 (중간~높음)
    운영 및 관리 시간 웹 UI 기반, 자동화된 스케줄, 모니터링 기능 (낮음) 스크립트 유지보수, 수동 모니터링 필요 (높음)
    저장 공간 효율성 강력한 중복 제거, 증분 백업으로 공간 절약 (매우 높음) 일반적인 압축만 가능, 중복 제거 부재 (낮음)
    하드웨어 비용 별도의 서버/VM 필요 (낮은 사양으로도 충분) (중간) 기존 저장 장치 활용 가능 (낮음)
    데이터 무결성 정기적인 무결성 검사 기능 내장 (매우 높음) 수동 검증 필요, 오류 시 발견 어려움 (낮음)
    복구 편의성 웹 UI에서 쉽고 빠르게 복원 가능 (매우 높음) 명령어 기반, 복잡할 수 있음 (낮음)

    결론부터 말씀드리면, 장기적인 관점에서 Proxmox Backup Server 비용은 스크립트 백업보다 더 효율적일 가능성이 높습니다.

    • 저장 공간 절약: PBS의 중복 제거 기능은 시간이 지남에 따라 엄청난 저장 공간을 절약해줍니다. 이는 곧 추가적인 하드디스크 구매 비용을 줄여준다는 의미입니다. 홈랩에서 데이터가 늘어나는 속도는 상상 이상이더라고요.
    • 시간 절약: 백업 스케줄 설정, 모니터링, 복원 과정의 편리함은 제 소중한 시간을 아껴줍니다. 이 시간을 새로운 기술을 배우거나, 다른 홈랩 프로젝트에 투자할 수 있죠. 삽질 경험을 줄여주는 것이 진정한 비용 절감입니다!
    • 안정성: 데이터 무결성 검사와 쉬운 복구는 만약의 사태에 대비한 훌륭한 보험입니다. 데이터 유실로 인한 정신적, 시간적 손실을 생각하면 PBS의 가치는 더욱 빛을 발합니다.

    물론 PBS를 위한 최소한의 하드웨어(저전력 미니 PC나 라즈베리 파이 같은 SBC에 외장 HDD 연결)는 필요합니다. 하지만 이 초기 투자는 위에서 언급한 장점들로 충분히 상쇄된다고 저는 확신합니다. 특히 홈랩 백업 솔루션을 고민하고 계시다면, PBS는 정말 훌륭한 선택지입니다. 💡

    Proxmox Backup Server와 스크립트 백업의 핵심 장단점 및 장기적인 비용 효율성을 비교하는 인포그래픽입니다.

    삽질 피하기! 제가 겪은 트러블슈팅 경험

    제가 PBS와 스크립트 백업을 사용하면서 겪었던 몇 가지 삽질 경험과 그 해결책을 공유해드릴게요. ⚠️

    1. 스크립트 백업의 저장 공간 부족 알림 부재: 처음 스크립트 백업을 쓸 때는 공간이 부족해지는 걸 모르고 있다가 백업이 실패하는 경우가 많았습니다. 해결책은 간단하더라고요. 디스크 사용량을 체크하는 스크립트를 추가하고, 특정 임계치(Threshold)를 넘으면 제게 이메일이나 메신저로 알림을 보내도록 설정했습니다.
    2. PBS 데이터스토어 용량 부족: PBS는 중복 제거가 강력하지만, 그래도 물리적인 용량은 한계가 있습니다. 특히 백업 데이터를 장기간 보존(Long-term Retention)하다 보면 용량이 차오르죠. PBS 웹 UI에서 데이터스토어 용량을 주기적으로 확인하고, 필요 없는 오래된 백업 스냅샷을 Prune(가지치기) 작업으로 정리해줘야 합니다.
    3. 네트워크 대역폭 문제: 백업은 생각보다 네트워크 자원을 많이 사용합니다. 특히 무거운 VM을 백업할 때, 홈랩 네트워크가 느려지거나 다른 서비스에 영향을 주는 경우가 있었어요. 백업 스케줄을 사용량이 적은 새벽 시간대로 조절하거나, PBS 서버와 Proxmox VE 간의 네트워크를 분리(Dedicate)하는 방법을 사용했습니다.
    4. 권한 문제: 스크립트 백업 시 vzdump 명령어가 특정 디렉토리에 접근하지 못하거나, 마운트된 NAS에 쓰기 권한이 없는 경우가 있었습니다. sudo 권한이나 파일 시스템 권한(chmod, chown)을 꼼꼼하게 확인하는 것이 중요합니다. PBS는 Proxmox VE와의 통합이 잘 되어있어서 이런 권한 문제는 거의 발생하지 않더라고요.

    이런 삽질들을 겪으면서 느낀 건, 결국 자동화되고 안정적인 시스템이 장기적으로 훨씬 이득이라는 점입니다. PBS는 이런 면에서 훌륭한 해결책을 제공해주더군요.

    Proxmox Backup Server 대시보드: 백업 성공률 및 데이터스토어 상태

    Proxmox Backup Server 대시보드에서 백업 성공률과 데이터스토어 상태를 한눈에 확인할 수 있는 스크린샷입니다.

    마무리: 나에게 맞는 백업 전략 찾기

    지금까지 Proxmox Backup Server (PBS)와 스크립트 백업의 장단점, 그리고 비용 효율성을 제 경험을 바탕으로 비교해봤습니다. 어떤 방식이 ‘절대적으로 좋다’고 단정하기는 어렵습니다. 홈랩 환경은 저마다 다르니까요.

    • 나는 최소한의 비용으로 바로 백업을 시작하고 싶다!
      : 기존에 여분의 저장 장치나 NAS가 있고, 스크립트 작성 및 관리에 익숙하시다면 스크립트 백업도 좋은 시작이 될 수 있습니다. 하지만 장기적인 관리 비용과 데이터 무결성에는 더 많은 노력을 기울여야 할 거예요.
    • 나는 백업에 시간을 많이 쓰고 싶지 않다. 안정적이고 효율적인 솔루션을 원한다!
      : PBS는 초기 설치에 약간의 리소스가 필요하지만, 일단 구축하고 나면 백업 관리의 대부분을 자동화해주고, 저장 공간을 효율적으로 사용하며, 강력한 데이터 무결성 검사 기능을 제공합니다. 장기적인 관점에서 Proxmox Backup Server 비용은 시간과 노력 측면에서 훨씬 합리적입니다.

    결론적으로 저는 PBS를 강력하게 추천합니다. 특히 홈랩에서 여러 VM과 LXC를 운영하며 VM 백업의 중요성을 느끼고 계시다면, PBS는 여러분의 소중한 데이터를 지켜주는 든든한 파트너가 될 것입니다. 🎉

    다음 글에서는 PBS를 처음 설치하고 Proxmox VE와 연동하는 구체적인 방법에 대해 다뤄볼 예정입니다. 기대해주세요!

  • [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    13년차 인프라 엔지니어의 Proxmox Backup Server (PBS) 삽질 & 활용기

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 Proxmox Backup Server (PBS), 줄여서 PBS에 대한 이야기를 해보려고 합니다. 사실 인프라 엔지니어에게 백업(Backup)은 아무리 강조해도 지나치지 않은 핵심 업무 중 하나잖아요? 저도 수많은 시스템을 운영하면서 “아차!” 싶었던 순간이 한두 번이 아니었습니다. 특히 홈랩에서 Proxmox VE(Virtual Environment)를 쓰면서 가상 머신(VM)이나 컨테이너(Container) 백업이 늘 고민이었는데, 이 PBS를 만나고 나서 드디어 마음의 평화를 찾았지 뭐예요? 🎉

    Proxmox VE를 사용하시는 분들이라면 기본적으로 제공되는 백업 기능도 꽤 유용하다는 걸 아실 거예요. 근데 이게 스케일이 커지거나, 데이터 중복 제거(Deduplication)나 증분 백업(Incremental Backup) 같은 고급 기능이 필요해지면 한계에 부딪히거든요. 그때 PBS가 진가를 발휘합니다. 오늘은 제가 직접 PBS를 설치하고, Proxmox VE와 연동해서 백업/복구 전략까지 세워본 경험을 솔직하게 공유해 드릴게요. 삽질 과정과 해결 팁도 아낌없이 풀어놓을 테니, 끝까지 함께해 주시면 분명 큰 도움이 되실 겁니다!

    Proxmox Backup Server의 전체 아키텍처는 Proxmox VE에서 PBS로 데이터를 보내고, PBS가 중복 제거 및 압축하여 백업 스토리지에 저장하는 과정을 시각적으로 보여줍니다.

    Proxmox Backup Server (PBS)란 무엇인가요?

    Proxmox Backup Server (PBS)는 Proxmox VE 환경에 최적화된 엔터프라이즈급 백업 솔루션입니다. 쉽게 말해, Proxmox VE 위에 돌아가는 수많은 VM이나 컨테이너의 데이터를 효율적으로 저장하고 관리하기 위해 태어난 녀석이라고 보시면 됩니다. 단순히 데이터를 복사해서 저장하는 것을 넘어, 여러 가지 똑똑한 기능들을 제공하죠.

    • 데이터 중복 제거 (Deduplication): 이게 PBS의 가장 강력한 기능 중 하나인데요. 동일한 데이터 블록이 여러 백업 이미지에 존재하더라도, PBS는 딱 한 번만 저장하고 나머지는 참조만 합니다. 덕분에 저장 공간을 엄청나게 절약할 수 있어요. 제가 직접 써보니, 특히 비슷한 OS 이미지로 여러 VM을 돌릴 때 그 효과가 대단하더라고요!
    • 증분 백업 (Incremental Backup): 첫 백업 이후에는 변경된 데이터 블록만 백업합니다. 이는 백업 시간을 단축시키고, 다시 한 번 저장 공간 효율성을 높여줍니다.
    • 데이터 무결성 검증 (Data Integrity Verification): 백업된 데이터가 손상되지 않았는지 정기적으로 검사할 수 있습니다. 백업은 저장하는 것만큼 ‘제대로 저장되었는지’ 확인하는 게 중요하잖아요? 이 기능 덕분에 안심하고 데이터를 맡길 수 있습니다.
    • 클라이언트-사이드 암호화 (Client-side Encryption): 백업 데이터는 클라이언트(Proxmox VE)에서 암호화되어 PBS로 전송됩니다. 덕분에 민감한 데이터도 안전하게 보관할 수 있죠.
    • 원격 동기화 (Remote Sync): 백업 데이터를 다른 PBS 서버로 동기화할 수 있어, 재해 복구(Disaster Recovery) 전략을 수립하는 데 아주 유용합니다.

    처음엔 그냥 NAS에 백업하면 되지 않나 싶었는데, PBS의 이런 기능들을 경험하고 나니 왜 전용 백업 솔루션이 필요한지 절실히 깨달았네요. 특히 중복 제거는 진짜 혁명적입니다. 💡

    Proxmox Backup Server 설치하기

    자, 그럼 이제 본격적으로 PBS를 설치해 볼까요? 저는 별도의 물리 서버나 가상 머신에 Proxmox Backup Server ISO 파일을 이용해서 설치하는 방법을 선호합니다. 안정적이고 깔끔하거든요. 여기서는 ISO를 이용한 설치 과정을 간략하게 설명해 드릴게요. (Proxmox VE 위에 컨테이너로 설치하는 방법도 있지만, 안정성을 위해 전용 OS 설치를 추천합니다.)

    1. ISO 다운로드 및 부팅: Proxmox 공식 웹사이트에서 PBS ISO 이미지를 다운로드하고, USB에 굽거나 VM에 마운트하여 부팅합니다.
    2. 설치 마법사 진행: 부팅 후 나타나는 설치 마법사를 따라 진행합니다.
      • Target Harddisk (대상 하드디스크): PBS가 설치될 디스크를 선택합니다. 저는 보통 OS용으로 작은 SSD 하나, 백업 데이터 저장용으로 큰 HDD/SSD를 따로 구성합니다.
      • Country (국가), Time zone (시간대): 대한민국, 서울을 선택해 줍니다.
      • Root Password (루트 비밀번호) & Email address (이메일 주소): 관리자 비밀번호를 설정하고, 알림을 받을 이메일 주소를 입력합니다.
      • Management Network Configuration (네트워크 설정): IP 주소, 넷마스크, 게이트웨이, DNS 서버를 설정합니다. 나중에 Proxmox VE에서 접근해야 하니, 고정 IP로 설정하는 것이 좋습니다.
    3. 설치 완료 및 재부팅: 모든 설정이 끝나면 설치가 시작되고, 완료되면 재부팅하라는 메시지가 나옵니다. 재부팅 후에는 웹 인터페이스에 접속할 수 있습니다.

    웹 인터페이스는 https://[PBS 서버 IP]:8007로 접속할 수 있습니다. 사용자 이름은 root이고, 비밀번호는 설치 시 설정한 비밀번호를 사용하면 됩니다. 처음 접속하면 왠지 모르게 뿌듯하더라고요! 🎉

    Proxmox Backup Server 웹 인터페이스에 로그인한 후의 대시보드 화면입니다. 시스템 상태와 저장소 현황을 한눈에 확인할 수 있습니다.

    Proxmox VE와 PBS 연동하기

    PBS를 설치했으니, 이제 Proxmox VE에서 이 녀석을 백업 저장소로 추가해야겠죠? 이 과정도 정말 간단합니다.

    1. Proxmox VE 웹 인터페이스 접속: 평소처럼 Proxmox VE 웹 관리 화면에 로그인합니다.
    2. 데이터센터(Datacenter) > 스토리지(Storage) 이동: 왼쪽 메뉴에서 Datacenter를 클릭하고, 그 아래의 Storage 탭으로 이동합니다.
    3. ‘추가(Add)’ 버튼 클릭 > ‘Proxmox Backup Server’ 선택: ‘Add’ 드롭다운 메뉴에서 ‘Proxmox Backup Server’를 선택합니다.
    4. 정보 입력: 다음 정보를 입력해 줍니다.
      • ID: 이 저장소의 이름을 지정합니다. (예: pbs-backup-storage)
      • Server: PBS 서버의 IP 주소 또는 도메인 이름을 입력합니다.
      • Username: root@pam (PBS의 기본 관리자 계정)
      • Password: PBS 설치 시 설정한 root 비밀번호
      • Datastore: PBS에서 생성된 데이터스토어 이름을 입력합니다. 기본값은 datastore1입니다. (PBS 웹 인터페이스의 ‘Datastore’ 메뉴에서 확인할 수 있습니다.)
      • Fingerprint (지문): PBS 서버의 SSH 지문입니다. 처음 연결할 때 자동으로 채워지거나, PBS 웹 인터페이스에서 확인할 수 있습니다. 보안을 위해 꼭 확인해 주세요.
    5. ‘추가(Add)’ 버튼 클릭: 모든 정보를 입력하고 ‘Add’ 버튼을 누르면 끝!

    제대로 연결되었다면, Proxmox VE의 스토리지 목록에 PBS가 나타나고, ‘Status’가 ‘Active’로 표시될 거예요. 이제 Proxmox VE의 VM이나 컨테이너를 백업할 때, 대상 저장소로 PBS를 선택할 수 있게 됩니다. ✅

    Proxmox VE에 Proxmox Backup Server를 스토리지로 추가하는 설정 화면입니다. Server IP, Username, Datastore 등의 정보를 입력하는 창이 보입니다.

    백업 전략 수립 및 실행

    저장소를 연결했으니, 이제 어떤 VM을 언제, 어떻게 백업할지 전략을 세울 차례입니다. Proxmox VE에서는 백업 스케줄을 아주 유연하게 설정할 수 있습니다.

    1. Datacenter > Backup (백업) 메뉴 이동: Proxmox VE 웹 인터페이스에서 ‘Datacenter’를 클릭하고 ‘Backup’ 탭으로 이동합니다.
    2. ‘Add (추가)’ 버튼 클릭: 새로운 백업 작업을 생성합니다.
    3. 백업 작업 설정:
      • Storage (저장소): 방금 추가한 PBS 저장소를 선택합니다. (예: pbs-backup-storage)
      • Schedule (스케줄): 백업이 실행될 시간을 설정합니다. 매일 새벽 2시, 매주 일요일 자정 등 원하는 대로 설정할 수 있습니다. (예: daily, weekly)
      • VMs (VM 선택): 백업할 VM이나 컨테이너를 선택합니다. ‘All’을 선택하거나 특정 VM ID를 지정할 수 있습니다.
      • Mode (모드): Snapshot을 선택하는 것이 일반적입니다. (VM이 실행 중인 상태에서 일관성 있는 백업을 생성할 수 있습니다.)
      • Compression (압축): 백업 데이터의 압축 방식을 선택합니다. 저는 보통 Zstandard (ZSTD)를 사용합니다. 빠르고 효율적이거든요.
      • Retention (보존 정책): 백업본을 얼마나 오래 보관할지 설정합니다. 예를 들어, ‘Keep last 7’로 설정하면 최근 7개의 백업본만 유지하고 오래된 것은 자동으로 삭제됩니다. 이 정책은 데이터스토어 용량 관리에도 아주 중요합니다.
      • Email notification (이메일 알림): 백업 성공/실패 여부를 이메일로 받아볼 수 있습니다. 중요한 기능이니 꼭 설정해 두세요!
    4. ‘Create (생성)’ 버튼 클릭: 백업 작업이 생성됩니다.

    이렇게 설정해두면, 정해진 시간에 PBS로 자동 백업이 진행됩니다. PBS 웹 인터페이스의 ‘Tasks’ 메뉴나 Proxmox VE의 ‘Task Log’에서 백업 진행 상황을 확인할 수 있습니다. 처음 백업이 성공했을 때의 그 쾌감이란! 💪

    데이터 복구, 이젠 걱정 마세요!

    백업은 언제나 ‘만약의 사태’를 대비하는 것이죠. 가장 중요한 건 백업된 데이터를 성공적으로 복구(Restore)할 수 있느냐입니다. PBS는 복구 과정도 직관적이고 빠릅니다.

    1. Proxmox VE 웹 인터페이스 접속: 복구할 VM이 있던 Proxmox VE 노드에 접속합니다.
    2. VM 선택 및 ‘백업(Backup)’ 탭 이동: 복구할 VM을 선택한 다음, ‘Backup’ 탭으로 이동합니다.
    3. 복구할 백업본 선택: PBS에 저장된 백업 목록이 나타납니다. 복구하고자 하는 특정 날짜와 시간의 백업본을 선택합니다.
    4. ‘복원(Restore)’ 버튼 클릭: 복원 옵션 대화 상자가 나타납니다.
      • Storage (저장소): 복원될 VM의 디스크가 저장될 Proxmox VE 스토리지(예: local-lvm)를 선택합니다.
      • VM ID: 기존 VM ID로 복원하거나, 새로운 VM ID를 지정하여 복원할 수 있습니다. 기존 VM이 손상된 경우 같은 ID로 복원하고, 테스트 목적으로 복원할 경우 새로운 ID로 복원하는 것이 일반적입니다.
      • Overwrite (덮어쓰기): 기존 VM이 있을 경우 덮어쓸지 여부를 결정합니다. 주의해서 사용해야 합니다!
    5. ‘복원(Restore)’ 버튼 클릭: 복구가 시작됩니다.

    복구 작업이 완료되면, 해당 VM이 Proxmox VE 목록에 나타나고, 정상적으로 부팅되는 것을 확인할 수 있습니다. 제가 실제로 몇 번 복구 테스트를 해봤는데, 정말 빠르고 안정적이더라고요. 특히 중복 제거 덕분에 복구 시간도 단축되는 느낌이었습니다. 👏

    ⚠️ 삽질 경험 & 트러블슈팅 팁

    제가 PBS를 사용하면서 겪었던 몇 가지 삽질 경험과 그 해결 팁을 공유해 드릴게요. 여러분은 저처럼 고생하지 마시라고요! ㅎㅎ

    • 방화벽 문제: Proxmox VE와 PBS가 서로 통신하려면 8007번 포트가 열려있어야 합니다. PBS 서버에 UFW(Uncomplicated Firewall)나 다른 방화벽이 설치되어 있다면, 꼭 8007번 포트를 허용해 주세요.
      sudo ufw allow 8007/tcp
      sudo ufw enable
      sudo ufw status
      

      저는 처음에 포트 열어주는 걸 깜빡해서 “왜 연결이 안 되지?” 하고 한참 헤맸거든요. 😅

    • Datastore(데이터스토어) 설정 오류: PBS 설치 후 Datastore를 생성하지 않거나, Proxmox VE에서 입력하는 Datastore 이름이 PBS의 Datastore 이름과 다르면 연결이 안 됩니다. PBS 웹 인터페이스에서 ‘Datastore’ 메뉴를 확인하고 정확한 이름을 입력해야 합니다. 기본값은 datastore1이지만, 직접 이름을 바꿨다면 그 이름을 써야 해요.
    • 스토리지 용량 부족: 아무리 중복 제거가 뛰어나도 백업본이 쌓이면 결국 용량이 부족해집니다. PBS 웹 인터페이스에서 ‘Datastore’ > ‘Prune & GC’ 탭을 활용하여 가지치기(Prune)와 가비지 컬렉션(Garbage Collection) 스케줄을 설정해 주세요. Prune은 오래된 백업본을 삭제하는 정책이고, GC는 삭제된 데이터 블록을 실제로 정리해서 공간을 회수하는 작업입니다. 이걸 안 해주면 삭제된 백업본이 실제 공간을 계속 차지하고 있을 수 있습니다.
    • 네트워크 대역폭 문제: 동시에 여러 VM을 백업하거나, 대용량 VM을 백업할 경우 네트워크 대역폭이 충분하지 않으면 백업 시간이 엄청나게 길어질 수 있습니다. 1Gbps 네트워크 환경이라면 큰 문제가 없지만, 가능하다면 백업 전용 네트워크를 구성하거나 10Gbps 네트워크를 고려해볼 만합니다.

    Proxmox Backup Server의 주요 기능인 데이터 중복 제거, 압축, 암호화, 데이터 무결성 검증을 시각적으로 요약한 인포그래픽입니다.

    마무리하며: PBS, 인프라 엔지니어의 든든한 동반자

    오늘은 Proxmox Backup Server (PBS)에 대해 설치부터 Proxmox VE 연동, 백업/복구 전략, 그리고 제가 겪었던 삽질 경험까지 자세히 이야기해 드렸습니다. 13년차 인프라 엔지니어로서 여러 백업 솔루션을 경험해 봤지만, Proxmox 환경에서는 PBS만큼 효율적이고 안정적인 솔루션은 찾기 힘들다고 생각합니다.

    특히 데이터 중복 제거와 증분 백업 기능은 저장 공간을 아끼는 데 큰 도움이 되었고, 직관적인 웹 인터페이스 덕분에 관리도 정말 편했습니다. 여러분도 Proxmox VE를 사용하고 계시다면, PBS 도입을 적극적으로 고려해 보시길 강력히 추천합니다. 처음엔 좀 낯설게 느껴질 수도 있지만, 한 번 세팅해두면 든든한 백업 시스템이 될 거예요. 든든한 백업 시스템 구축으로 여러분의 소중한 데이터를 지켜내시길 바랍니다!

    다음번에는 PBS의 원격 동기화(Remote Sync) 기능을 활용한 재해 복구(DR) 전략에 대해 더 깊이 다뤄볼까 합니다. 기대해 주세요! 😉

  • [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 백업 및 복원 전략: 안전한 가상 환경 운영 가이드

    [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 클러스터 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는 비계획 장애 대응에 쓰입니다.