13년차의 서버실

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

[카테고리:] proxmox

  • Proxmox를 CLI로 자동화하기 — qm·pct 실전 명령 정리

    Proxmox는 웹 UI가 훌륭하지만, 반복 작업이나 자동화는 결국 CLI가 답입니다. VM은 qm, 컨테이너는 pct — 이 두 명령만 익히면 클릭 수십 번을 한 줄로 끝낼 수 있습니다. 제가 홈랩을 운영·실습하며 실제로 가장 많이 쓰는 명령을 정리합니다.

    1. qm(VM) vs pct(LXC) — 쌍둥이 명령

    두 명령은 구조가 거의 같습니다. 대상만 VM이냐 컨테이너냐의 차이죠.

    작업 VM (qm) LXC (pct)
    목록 qm list pct list
    시작/정지 qm start/stop ID pct start/stop ID
    설정변경 qm set ID ... pct set ID ...
    설정보기 qm config ID pct config ID

    2. 설정 변경 — 클릭 대신 한 줄

    CPU·메모리·디스크를 명령으로 바꿉니다. 실제로 DevStack VM을 세팅할 때 이렇게 했습니다.

    # 메모리·코어 변경
qm set 200 --memory 12288 --cores 6

# CPU 타입을 host로 (가상화 기능 노출 — 중첩가상화/명령어셋)
qm set 200 --cpu host

# 디스크 확장(온라인, 무중단)
qm resize 200 scsi0 +37G

# LXC도 동일
pct set 113 --memory 2048 --cores 2

    3. 컨테이너 안에서 명령 실행 — pct exec

    pct exec는 LXC 내부에 SSH 없이 바로 명령을 넣습니다. 홈랩 자동화의 핵심입니다.

    # 컨테이너 113 안에서 명령 실행
pct exec 113 -- bash -lc "docker compose up -d"

# 호스트에서 여러 컨테이너 상태 한 번에
for id in 100 112 113; do echo -n "$id: "; pct status $id; done

    (참고: VM은 커널이 분리돼 qm exec 대신 QEMU Guest Agent나 SSH를 씁니다.)

    4. 스냅샷·복제 — 실험의 안전망

    # 위험 작업 전 스냅샷
qm snapshot 200 before_test
qm rollback 200 before_test     # 되돌리기

# 템플릿에서 새 VM 풀 클론 (cloud-init 템플릿 활용)
qm clone 9000 201 --full --name node1

    스냅샷 한 줄이면 몇 초 만에 되돌릴 수 있어, 실습·업그레이드 전에 습관처럼 찍습니다.

    5. 원격에서 한 번에 — SSH + pct 조합

    저는 작업 PC에서 Proxmox 호스트를 거쳐 컨테이너까지 한 줄로 조작합니다.

    # 작업PC → Proxmox 호스트 → LXC 113 내부 명령
ssh root@proxmox-host "pct exec 113 -- bash -lc 'uptime'"

    이 패턴으로 여러 호스트·컨테이너를 스크립트로 묶어 자동화할 수 있습니다.

    6. 자주 쓰는 조회 명령

    pvesm status           # 스토리지 용량/상태
qm config 200 | grep -E "cpu|memory|net"   # 특정 설정만
pct config 113 | grep features              # LXC 기능 플래그
pvesh get /nodes/$(hostname)/status         # 노드 상태(API)

    7. 정리

    qm(VM)·pct(LXC)는 구조가 같아 한 번 익히면 양쪽에 다 씁니다. set으로 설정, exec로 내부 실행, snapshot/clone으로 안전망 — 이 세 가지가 홈랩 자동화의 기본기입니다. 웹 UI로 배우되, 반복이 보이면 CLI로 넘기세요. 그게 홈랩을 “운영”하는 단계로 가는 길입니다.

  • [Proxmox] Proxmox ZFS 스냅샷·복제 전략 체크리스트

    [Proxmox] Proxmox ZFS 스냅샷·복제 전략 체크리스트

    목차

    Proxmox ZFS 스냅샷·복제 전략 체크리스트

    1. Proxmox ZFS 스냅샷은 백업이 아니라 운영 타임머신입니다

    Proxmox ZFS 스냅샷을 제대로 쓰면 패치 실패, 설정 실수, 배포 사고에서 돌아오는 시간이 확 줄어듭니다. 이거 진짜 편하더라고요. 다만 스냅샷을 백업처럼 믿는 순간 위험해집니다. 같은 ZFS 풀 안에 있는 스냅샷은 디스크 장애, 풀 손상, 관리자 계정 탈취, 랜섬웨어가 root 권한을 잡은 상황에서는 같이 위험해질 수 있습니다.

    운영 기준은 단순하게 잡는 편이 좋습니다. 스냅샷은 빠른 롤백용, 복제는 장애 대응 시간 단축용, 백업은 생존용입니다. 이 셋을 섞어서 생각하면 정책이 애매해지고, 장애가 났을 때 ‘이 데이터가 어디까지 살아 있지?’부터 다시 헤매게 됩니다.

    예를 들어 VM 100번에서 패키지 업데이트를 하기 전이라면 Proxmox VM 스냅샷이 가장 빠릅니다. 파일 서버 데이터셋이라면 ZFS 스냅샷과 원격 zfs send/zfs receive가 더 어울립니다. 장기 보관, 삭제 사고, 법적 보존, 랜섬웨어 대응까지 생각한다면 Proxmox Backup Server(PBS)나 별도 백업 저장소가 필요합니다.

    Proxmox 노드, ZFS 풀, 로컬 스냅샷, 원격 복제 서버가 어떻게 이어지는지 보여주는 전체 구조도입니다.

    2. 스냅샷, 복제, 백업의 책임 경계부터 정하세요

    도구부터 고르면 대개 과하게 복잡해집니다. 먼저 장애 유형을 놓고 어떤 보호 계층이 맡을지 정해야 합니다. 이 기준이 잡혀 있으면 나중에 복구 리허설을 할 때도 훨씬 덜 흔들립니다.

    상황 우선 선택 쓰면 좋은 이유 쓰지 말아야 할 때
    패키지 업데이트, 설정 변경, 방화벽 룰 수정 Proxmox VM 스냅샷 롤백이 빠르고 UI/CLI에서 상태 확인이 쉽습니다. 며칠 이상 오래 보관할 목적이면 부적합합니다.
    파일 서버에서 실수 삭제를 되돌리고 싶음 ZFS 데이터셋 스냅샷 파일 단위 복구 흐름을 만들기 좋습니다. 풀 자체 장애까지 커버한다고 보면 안 됩니다.
    다른 Proxmox 노드에서 빠르게 VM을 다시 띄우고 싶음 Proxmox 내장 Replication 클러스터 안에서 RTO를 줄이는 데 실용적입니다. 장기 백업, 오프사이트 보관, 랜섬웨어 대응의 대체재는 아닙니다.
    ZFS 데이터셋을 다른 서버에 보관하고 싶음 zfs send/zfs receive 스냅샷 단위로 증분 전송할 수 있습니다. 수신 대상 관리와 공통 스냅샷 보존 정책이 없으면 쉽게 꼬입니다.
    삭제, 암호화 사고, 장기 보관까지 대비 PBS 또는 별도 백업 저장소 보관 정책, 검증, 격리를 설계하기 좋습니다. 즉시 롤백만 필요한 작업 전 보호에는 과할 수 있습니다.

    현장에서 쓰기 좋은 결론은 이렇습니다. 작업 전에는 VM 스냅샷, 매일 데이터셋은 ZFS 스냅샷, 중요 데이터는 원격 복제, 최종 생존선은 별도 백업으로 나눕니다. 한 도구에 모든 책임을 몰아주지 않는 게 핵심입니다.

    3. 사전 점검: 풀 상태가 나쁘면 스냅샷도 좋은 답이 아닙니다

    스냅샷이나 복제 전에 풀 건강부터 봐야 합니다. 복제가 실패했는데 원인을 따라가 보면 네트워크나 SSH가 아니라 원본 풀의 checksum error인 경우도 있습니다. 복제는 원본 상태를 마법처럼 고쳐주지 않습니다. 나쁜 블록과 꼬인 상태도 운영 이슈로 그대로 따라옵니다.

    # 1) ZFS 풀 상태와 오류 카운터 확인
zpool status -v

# 2) 풀 용량과 조각화 경향 확인
zpool list -o name,size,alloc,free,cap,frag,health

# 3) 데이터셋, zvol, 마운트 지점 확인
zfs list -o name,type,used,avail,refer,usedbysnapshots,mountpoint

# 4) 스냅샷 목록을 생성일 기준으로 확인
zfs list -t snapshot -o name,creation,used,refer -s creation

# 5) Proxmox VM 디스크 매핑 확인
qm config 100
pvesm status

    zpool status에서 봐야 할 것은 state: ONLINE 하나가 아닙니다. READ, WRITE, CKSUM 카운터가 증가하는지, scan 결과에 unrepaired error가 있는지, 특정 디스크만 반복해서 오류를 내는지까지 봐야 합니다. 오류가 보이면 스냅샷 정책보다 디스크 교체, 케이블 확인, scrub 결과 분석이 먼저입니다.

    용량도 중요합니다. ZFS는 여유 공간이 너무 낮아지면 성능과 운영 안정성이 같이 나빠집니다. 여기서 임의의 만능 퍼센트를 외우기보다, cap이 계속 올라가고 오래된 스냅샷의 usedbysnapshots가 크게 잡힌다면 보관 정책을 바로 손봐야 합니다.

    4. Proxmox ZFS 스냅샷: 작업 전에는 빠르게 만들고 빠르게 지우기

    운영에서 가장 많이 쓰는 패턴은 ‘작업 직전 스냅샷’입니다. 스냅샷 이름에는 목적과 날짜를 넣는 편이 좋습니다. 장애 상황에서는 멋진 네이밍보다 pre-upgrade-2026-09-30처럼 바로 읽히는 이름이 이깁니다.

    4-1. VM 단위 스냅샷: Proxmox가 디스크와 메타데이터를 같이 관리하게 하기

    # VM 100번에 작업 전 스냅샷 생성: 메모리 상태는 저장하지 않음
qm snapshot 100 pre-upgrade-2026-09-30 --description 'before package upgrade' --vmstate 0

# 스냅샷 트리 확인
qm listsnapshot 100

# 문제가 있으면 해당 스냅샷으로 롤백
qm rollback 100 pre-upgrade-2026-09-30

# 검증이 끝난 뒤 불필요한 스냅샷 삭제
qm delsnapshot 100 pre-upgrade-2026-09-30

    --vmstate 0은 메모리 상태를 포함하지 않습니다. 대부분의 패키지 업데이트, 설정 파일 변경, 서비스 재시작 전에는 이 편이 부담이 적습니다. 반대로 실행 중인 애플리케이션 상태까지 그대로 붙잡아야 하는 테스트라면 --vmstate 1을 고려할 수 있지만, 스냅샷 생성 시간과 저장 공간 부담이 커질 수 있습니다.

    DB 서버라면 한 가지를 더 봐야 합니다. VM 스냅샷은 스토리지 관점의 시점 보존에 가깝습니다. 애플리케이션 일관성이 필요하면 게스트 안에서 DB flush, backup lock, 애플리케이션 자체 덤프, qemu-guest-agent 기반 freeze/thaw 같은 절차를 같이 설계해야 합니다. ‘스냅샷이 있으니 DB도 무조건 깨끗하다’는 가정은 위험합니다.

    4-2. ZFS 레벨 스냅샷: 데이터셋 정책을 직접 통제할 때

    # 단일 zvol 스냅샷
zfs snapshot rpool/data/vm-100-disk-0@pre-change-2026-09-30

# 하위 데이터셋까지 같은 이름으로 재귀 스냅샷 생성
zfs snapshot -r tank/projects@daily-2026-09-30

# 스냅샷별 공간 점유 확인
zfs list -t snapshot -o name,used,refer,creation -s creation

# 삭제 전 대상 목록만 먼저 확인
zfs list -t snapshot -r tank/projects

# 불필요한 스냅샷 삭제
zfs destroy tank/projects@daily-2026-09-30

    ZFS 레벨에서 직접 찍은 스냅샷은 Proxmox UI의 VM 스냅샷과 운영 경험이 다릅니다. 특히 VM 디스크가 zvol이면 파일처럼 열어서 복원하는 흐름이 아닙니다. VM 전체 롤백은 Proxmox 스냅샷이 낫고, 파일 서버나 애플리케이션 데이터셋처럼 ZFS 계층을 직접 다루는 대상은 ZFS 스냅샷이 낫습니다.

    Proxmox ZFS 스냅샷 기반 VM 작업 전 점검 흐름

    작업 전 스냅샷 생성, 변경 적용, 검증, 롤백 여부 판단 흐름을 보여주는 운영 절차 이미지입니다.

    5. 보관 정책: 많이 만드는 것보다 제때 지우는 게 어렵습니다

    스냅샷이 공간을 거의 안 쓴다는 말은 반만 맞습니다. 생성 직후에는 작아 보이지만, 원본 데이터가 바뀌면 오래된 스냅샷이 예전 블록을 계속 붙잡습니다. 파일을 지웠는데 용량이 안 돌아오는 대표 원인이 이겁니다.

    기본 보관 구조는 운영 성격별로 달라야 합니다. 자주 바뀌는 VM 디스크는 짧게, 파일 서버는 조금 길게, 장기 보관은 스냅샷이 아니라 백업 정책으로 넘깁니다. 그래야 ZFS 백업과 스냅샷이 서로 역할을 침범하지 않습니다.

    대상 스냅샷 주기 보관 감각 주의점
    패치 전 VM 작업 직전 수동 검증 후 즉시 삭제 남겨두면 VM 디스크 변경분이 계속 누적됩니다.
    파일 서버 데이터셋 일 단위 또는 업무 주기 기준 삭제 사고를 발견할 수 있는 기간만 사용자가 큰 파일을 자주 바꾸면 스냅샷 사용량이 빠르게 늘 수 있습니다.
    DB 데이터셋 애플리케이션 일관성 절차와 함께 복구 리허설로 검증한 기간만 스토리지 스냅샷만으로 논리적 복구를 대체하지 마세요.
    장기 보존 데이터 백업 정책에서 관리 PBS, 오프사이트, 불변 백업 등으로 분리 로컬 스냅샷을 장기 보관소로 쓰면 풀 용량 관리가 어려워집니다.

    간단한 환경에서는 아래처럼 이름 규칙을 고정해두는 것만으로도 사고가 줄어듭니다. 자동 삭제는 편하지만, 처음부터 과감하게 지우는 스크립트를 돌리지 말고 목록 출력부터 검증하세요. 작은 습관인데 나중에 정말 큰 차이를 만듭니다.

    # 예시: tank/projects에 날짜 기반 스냅샷 생성
SNAP_NAME='daily-'$(date +%F)
zfs snapshot -r tank/projects@${SNAP_NAME}

# 스냅샷 공간 점유 상위 항목 확인
zfs list -t snapshot -o name,used,creation -s used | tail -n 20

# 특정 접두어의 스냅샷만 확인
zfs list -H -t snapshot -o name -r tank/projects | grep '@daily-'

    6. 원격 ZFS 복제: send/receive는 공통 스냅샷이 생명입니다

    ZFS 백업을 ZFS답게 만들고 싶다면 zfs send/zfs receive를 이해해야 합니다. 최초에는 전체 스트림을 보내고, 이후에는 양쪽에 공통으로 남아 있는 스냅샷을 기준으로 증분을 보냅니다. 실패의 절반은 이 공통 기준 스냅샷을 지워서 생깁니다.

    # 원본 서버: 최초 기준 스냅샷 생성
zfs snapshot -r tank/projects@base-2026-09-30

# 백업 서버: 수신 부모 데이터셋 준비
ssh backup-server 'zfs create -p backup/replica'

# 최초 전체 전송: -R은 하위 데이터셋과 스냅샷 관계를 함께 보냄
zfs send -R tank/projects@base-2026-09-30 | ssh backup-server 'zfs receive -u backup/replica/projects'

# 다음 스냅샷 생성
zfs snapshot -r tank/projects@inc-2026-09-30

# 증분 전송: 양쪽에 base 스냅샷이 있어야 함
zfs send -R -i tank/projects@base-2026-09-30 tank/projects@inc-2026-09-30 | ssh backup-server 'zfs receive -u backup/replica/projects'

# 원본/대상 스냅샷 비교
zfs list -H -t snapshot -o name -r tank/projects
ssh backup-server 'zfs list -H -t snapshot -o name -r backup/replica/projects'

    -R은 복제 스트림을 만들 때 유용합니다. 하위 데이터셋, 스냅샷 관계, 일부 속성을 함께 다루기 때문입니다. -i는 지정한 이전 스냅샷 이후 변경분만 보냅니다. 중간 스냅샷까지 포함한 증분 체인을 보내야 하는 상황에서는 -I가 더 적합할 수 있습니다. 수신 쪽의 -u는 receive 후 자동 마운트를 막아 백업 서버의 경로가 의도치 않게 올라오는 사고를 줄입니다.

    복제본에는 가능하면 사람이 쓰지 못하게 하세요. 수신 대상 데이터셋이 수정되면 다음 증분 receive가 실패할 수 있습니다. 백업 서버에서 복제 루트를 읽기 전용으로 두고, 복구 테스트가 필요할 때는 clone이나 별도 restore 위치를 쓰는 흐름이 안전합니다.

    # 백업 서버: 복제본을 읽기 전용으로 설정
ssh backup-server 'zfs set readonly=on backup/replica/projects'

# 읽기 전용 속성 확인
ssh backup-server 'zfs get readonly backup/replica/projects'

# 복구 테스트용 클론 생성 예시
ssh backup-server 'zfs clone backup/replica/projects@inc-2026-09-30 backup/restore-test/projects-2026-09-30'

# 테스트 후 클론 제거
ssh backup-server 'zfs destroy backup/restore-test/projects-2026-09-30'

    7. Proxmox 내장 Replication: 빠른 재가동용이지 장기 백업은 아닙니다

    Proxmox의 ZFS 기반 Replication은 클러스터 노드 간 VM 디스크를 주기적으로 복제하는 기능입니다. 장점은 Proxmox가 VM 단위로 작업을 관리해준다는 점입니다. 한계도 분명합니다. 일반적으로 같은 클러스터 안의 다른 노드가 대상이고, 스토리지 구성과 VM 배치 정책의 영향을 많이 받습니다.

    # VM 100의 복제 작업을 pve2 노드 대상으로 생성
# 작업 ID 100-0은 예시이며, 실제 환경에서는 기존 작업 ID와 충돌하지 않게 확인합니다.
pvesr create-local-job 100-0 pve2 --schedule '*/15' --rate 50

# 복제 작업 목록과 상태 확인
pvesr list
pvesr status

# 작업 중지/재개
pvesr disable 100-0
pvesr enable 100-0

# 스케줄 변경 예시
pvesr update 100-0 --schedule '*/30'

    --schedule은 반복 주기를 정합니다. */15는 15분 간격 예시입니다. --rate는 복제 대역폭을 제한할 때 씁니다. 운영 시간대에 복제가 스토리지와 네트워크를 압박한다면 제한을 거는 편이 낫습니다. 다만 제한을 너무 낮게 잡으면 변경량을 따라가지 못해 다음 주기까지 밀릴 수 있습니다.

    Proxmox Replication에서 자주 보는 실패 원인은 세 가지입니다. 첫째, 대상 노드에 같은 스토리지 ID의 ZFS 스토리지가 없거나 VM 디스크가 복제 가능한 ZFS 스토리지에 있지 않은 경우입니다. 둘째, 이전 스냅샷이나 작업 상태가 꼬여 공통 기준을 못 찾는 경우입니다. 셋째, 네트워크, SSH, 노드 상태 문제로 작업이 중간에 끊기는 경우입니다. 이때는 pvesr status만 보지 말고 Proxmox task log와 양쪽 노드의 zfs list -t snapshot을 같이 봐야 합니다.

    8. 흔한 실패 모드와 근본 원인

    장애 대응 문서는 ‘명령어 모음’보다 ‘왜 실패했는지’를 빠르게 좁혀주는 쪽이 더 쓸모 있습니다. 아래 표는 실제 점검 때 우선순위로 보기 좋은 항목입니다.

    증상 가능한 근본 원인 확인 명령 권장 대응
    파일을 지웠는데 풀 용량이 안 줄어듦 오래된 스냅샷이 삭제 전 블록을 계속 참조 zfs list -o name,usedbysnapshots 보관 정책을 확인하고 불필요한 스냅샷부터 정리합니다.
    증분 send가 실패함 원본 또는 대상에서 기준 스냅샷 삭제 zfs list -t snapshot 남아 있는 공통 스냅샷부터 다시 증분하거나 새 기준으로 전체 전송합니다.
    receive 대상이 수정되었다는 오류 백업 서버 복제본에 직접 쓰기 발생 zfs get readonly 복제본은 readonly로 두고 테스트는 clone에서 합니다.
    VM 스냅샷 후 앱 데이터가 이상함 게스트 내부 애플리케이션 일관성 절차 부재 DB 로그, qemu-guest-agent 상태 DB dump, freeze/thaw, 앱별 백업 절차를 병행합니다.
    Proxmox Replication이 반복 실패 스토리지 ID 불일치, 대상 노드 ZFS 미구성, 이전 작업 상태 꼬임 pvesm status, pvesr status 스토리지 구성을 맞추고 task log에서 정확한 실패 지점을 확인합니다.

    재현 가능한 시나리오: 기준 스냅샷을 지운 뒤 증분 복제가 깨지는 경우

    # 원본에서 기준 스냅샷을 실수로 삭제한 상황
zfs destroy tank/projects@base-2026-09-30

# 이후 이 명령은 기준 스냅샷을 찾지 못해 실패합니다.
zfs send -R -i tank/projects@base-2026-09-30 tank/projects@inc-2026-09-30 | ssh backup-server 'zfs receive -u backup/replica/projects'

# 양쪽에 남아 있는 공통 스냅샷 확인
zfs list -H -t snapshot -o name -r tank/projects
ssh backup-server 'zfs list -H -t snapshot -o name -r backup/replica/projects'

    이 상황에서 zfs receive -F를 습관처럼 붙이는 건 조심해야 합니다. -F는 대상 쪽 상태를 송신 스트림에 맞추기 위해 롤백 성격의 동작을 할 수 있습니다. 대상에만 있던 스냅샷이나 변경을 잃을 수 있으니, 적용 전에는 대상 서버의 스냅샷 목록과 필요한 복구 지점을 반드시 확인해야 합니다.

    9. 검증 체크리스트: 성공 메시지보다 복구 가능성이 중요합니다

    Proxmox ZFS 스냅샷과 복제는 생성보다 검증이 더 중요합니다. ‘명령어가 0으로 끝났다’와 ‘장애 때 복구할 수 있다’는 다른 이야기입니다. 복구 리허설을 한 번 해보면 빈틈이 생각보다 빨리 드러납니다.

    1. zpool status -v에서 풀 상태와 오류 카운터를 확인합니다.
    2. zfs list -t snapshot으로 원본과 대상의 스냅샷 이름이 맞는지 비교합니다.
    3. zfs list -o usedbysnapshots로 오래된 스냅샷이 공간을 붙잡고 있는지 봅니다.
    4. zfs get readonly로 백업 복제본이 쓰기 방지되어 있는지 확인합니다.
    5. 테스트 데이터셋을 clone하거나 별도 위치에 receive해서 실제 파일을 열어봅니다.
    6. VM이라면 qm config로 디스크 매핑을 확인하고 테스트 부팅 절차를 문서화합니다.
    7. Proxmox Replication은 pvesr status와 task log를 함께 봅니다.
    # 원본 상태 점검
zpool status -v
zfs list -o name,used,avail,refer,usedbysnapshots -r tank/projects

# 원본 스냅샷 확인
zfs list -t snapshot -o name,creation,used,refer -r tank/projects

# 백업 서버 스냅샷 확인
ssh backup-server 'zfs list -t snapshot -o name,creation,used,refer -r backup/replica/projects'

# 복제본 읽기 전용 여부 확인
ssh backup-server 'zfs get readonly backup/replica/projects'

# Proxmox 복제 상태 확인
pvesr status
    ZFS 백업 복제 상태와 Proxmox 재해 복구 검증 화면

    원본과 백업 서버의 스냅샷 목록, 풀 상태, 복제 상태를 한눈에 점검하는 대시보드 느낌의 이미지입니다.

    10. ZFS 베스트 프랙티스: 성능과 안정성을 가르는 결정 포인트

    ZFS 스냅샷 자체는 보통 빠르게 만들어지지만, 운영 비용은 뒤에서 발생합니다. 변경이 많은 VM 디스크에 스냅샷을 오래 붙잡아두면 쓰기 패턴, 공간 회수, 복제량에 영향을 줍니다. 그래서 성능 튜닝보다 먼저 ‘무엇을 얼마나 오래 잡아둘지’를 정하는 게 우선입니다.

    결정 포인트 선택 기준 운영 영향
    VM 스냅샷에 메모리 포함 여부 실행 상태까지 되돌려야 하면 포함, 일반 패치 전이면 제외 포함 시 생성 시간과 저장 공간 부담이 커질 수 있습니다.
    스냅샷 보관 기간 삭제 사고를 발견하는 데 걸리는 시간 기준 길수록 복구 지점은 늘지만 풀 공간 회수가 늦어집니다.
    zfs send -i와 -I 두 지점 사이 변경만 필요하면 -i, 중간 스냅샷 체인까지 보내려면 -I 수신 측 스냅샷 구조와 보관 정책이 달라질 수 있습니다.
    zfs receive -u 백업 서버에서 자동 마운트를 피하고 싶을 때 사용 복제본이 운영 경로에 갑자기 나타나는 사고를 줄입니다.
    복제 대역폭 제한 업무 시간대 I/O 영향이 있으면 제한 너무 낮으면 변경량을 따라가지 못해 지연이 누적됩니다.
    백업 복제본 readonly 복제 대상에 사람이 직접 접근할 가능성이 있으면 활성화 다음 증분 receive 실패 가능성을 줄입니다.

    또 하나, VM 디스크의 volblocksize나 데이터셋의 recordsize 같은 값은 생성 후 쉽게 바꾸는 튜닝 항목이 아닙니다. 이미 운영 중인 VM에 숫자만 보고 적용하면 기대와 다른 결과가 나올 수 있습니다. 새 스토리지를 설계할 때 워크로드 단위로 검토하고, 기존 환경에서는 스냅샷·복제 정책을 먼저 안정화하는 편이 더 현실적입니다.

    11. Proxmox 재해 복구를 위한 최종 운영 체크리스트

    Proxmox ZFS 환경을 인수하거나 새로 설계할 때 마지막으로 남기기 좋은 체크리스트입니다. 이 정도만 지켜도 ‘스냅샷은 있는데 복구는 못 하는’ 상황을 꽤 줄일 수 있습니다. 관련 글로는 Proxmox Backup Server 구성법, ZFS scrub 운영 주기, Proxmox HA 설계 가이드를 함께 연결해두면 내부 링크 흐름도 자연스럽습니다.

    • 작업 전 VM 스냅샷은 짧게 가져갑니다. 검증이 끝나면 삭제합니다.
    • 중요 데이터셋은 ZFS 스냅샷 이름 규칙을 고정합니다. 예: daily-YYYY-MM-DD, pre-migration-YYYY-MM-DD.
    • 원격 복제는 공통 기준 스냅샷을 절대 함부로 지우지 않습니다. 보관 정책에 ‘복제 기준 스냅샷 보호’를 포함합니다.
    • 백업 서버의 복제본은 readonly로 둡니다. 복구 테스트는 clone 또는 별도 restore 데이터셋에서 합니다.
    • Proxmox Replication은 빠른 재가동용으로 씁니다. 장기 보관과 랜섬웨어 대응은 별도 백업으로 분리합니다.
    • 월 1회 이상 복구 리허설을 합니다. 파일 열기, VM 설정 확인, 테스트 부팅까지 해봐야 진짜 체크입니다.

    12. FAQ: 운영자가 자주 헷갈리는 질문

    Q1. Proxmox ZFS 스냅샷만 있으면 백업은 없어도 되나요?

    아니요. 스냅샷은 같은 풀 안의 시점 보존입니다. 풀 장애, 노드 분실, 관리자 실수, 악성 코드가 root 권한을 잡은 상황까지 대비하려면 별도 위치의 백업이 필요합니다.

    Q2. VM 스냅샷과 ZFS 스냅샷 중 무엇을 써야 하나요?

    VM 전체를 롤백할 목적이면 Proxmox VM 스냅샷을 우선합니다. 특정 파일 서버 데이터셋, 프로젝트 데이터셋처럼 ZFS 계층에서 복구 단위를 관리하고 싶다면 ZFS 스냅샷이 낫습니다.

    Q3. Proxmox Replication과 zfs send/receive 중 무엇이 더 좋나요?

    목적이 다릅니다. 클러스터 안에서 VM을 빨리 다시 띄우는 게 목표라면 Proxmox Replication이 편합니다. 독립 백업 서버에 데이터셋을 보관하고 복구 경로를 직접 통제하려면 zfs send/receive가 좋습니다. 중요한 운영 환경에서는 둘 중 하나만 고르기보다 역할을 나눠 같이 씁니다.

    Q4. 스냅샷을 오래 보관하면 왜 문제가 되나요?

    오래된 스냅샷은 과거 블록을 계속 참조합니다. 원본에서 파일을 삭제하거나 덮어써도 스냅샷이 잡고 있으면 공간이 즉시 반환되지 않습니다. 그래서 스냅샷 정책에는 생성 주기뿐 아니라 삭제 기준이 반드시 있어야 합니다.

    Q5. 추천 조합은 무엇인가요?

    홈랩이나 소규모 사무실이라면 작업 전 VM 스냅샷 + 중요 데이터셋 일일 ZFS 스냅샷 + 주기적 원격 복제 + 별도 백업을 권합니다. Proxmox 클러스터라면 여기에 내장 Replication을 더해 장애 시 재가동 시간을 줄이세요. 대신 Replication을 백업으로 착각하지 않는 선을 분명히 그어야 합니다.

    이 체크리스트의 핵심은 도구를 많이 쓰는 게 아닙니다. 되돌릴 지점, 복제할 위치, 검증할 절차를 운영자가 실제로 반복할 수 있게 만드는 것입니다. 스냅샷은 빠르게 만들고, 복제는 기준을 지키고, 백업은 원본과 분리하세요. 그 세 줄이 Proxmox ZFS 데이터 보호 전략의 뼈대입니다.

    Proxmox ZFS 베스트 프랙티스 체크리스트 요약

    스냅샷, 복제, 백업, 검증 리허설을 한 장으로 요약한 체크리스트형 인포그래픽입니다.

  • Proxmox 네트워크 기초 — Linux Bridge와 VLAN 이해하기

    Proxmox를 설치하면 vmbr0라는 게 자동으로 생깁니다. VM·컨테이너가 다 여기에 붙는데, 정작 이게 뭔지 모르고 쓰는 분이 많습니다. Linux Bridge와 VLAN — Proxmox 네트워크의 두 핵심을 실제 제 구성과 함께 정리합니다.

    1. Linux Bridge — 가상 스위치

    vmbr0는 소프트웨어로 만든 네트워크 스위치입니다. 물리 랜포트(NIC)와 VM/컨테이너들을 이 가상 스위치에 꽂아 서로·외부와 통신하게 합니다.

    실제 제 홈랩의 설정은 이렇게 단순합니다.

    # /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 192.168.20.100/24
    bridge-ports enp1s0     # 물리 NIC를 브리지에 연결
    bridge-stp off
    bridge-fd 0

    즉 물리 NIC enp1s0가 vmbr0에 물려 있고, 모든 게스트가 이 브리지를 통해 192.168.20.x 실제 네트워크에 직접 참여합니다. 그래서 VM에 공유기가 주는 IP가 그대로 붙는 겁니다.

    2. 게스트를 브리지에 연결

    # VM/LXC 네트워크를 vmbr0에 virtio로 연결
qm set 100 --net0 virtio,bridge=vmbr0
pct set 113 --net0 name=eth0,bridge=vmbr0,ip=dhcp

    이게 전부입니다. 게스트는 마치 물리 스위치에 랜선을 꽂은 것처럼 동작합니다.

    3. VLAN — 하나의 랜을 여러 개로 나누기

    네트워크를 용도별로 분리하고 싶을 때(예: 서버망 / IoT망 / 게스트망) VLAN을 씁니다. 물리 케이블은 하나인데 논리적으로 여러 망으로 쪼개는 기술입니다.

    Proxmox에서는 브리지를 VLAN-aware로 만들고, 게스트마다 VLAN 태그를 지정합니다.

    # VLAN 인식 브리지
auto vmbr0
iface vmbr0 inet static
    address 192.168.20.100/24
    bridge-ports enp1s0
    bridge-vlan-aware yes
    bridge-vids 2-4094
    # 게스트를 특정 VLAN(예: 30)에 배치
qm set 100 --net0 virtio,bridge=vmbr0,tag=30

    이러면 tag=30인 게스트들끼리만 같은 망에 묶이고, 다른 VLAN과는 L3 라우팅(방화벽)을 거쳐야만 통신합니다. 보안 분리에 효과적이죠.

    4. 솔직한 현실 — 내 홈랩은 아직 플랫

    고백하자면 제 홈랩은 아직 VLAN 없이 단일 플랫 네트워크(192.168.20.x)입니다. 서비스가 늘면서 “IoT·실험 VM은 분리하는 게 맞는데” 싶은 순간이 오는데, 저도 그 숙제를 남겨둔 상태입니다. 홈랩이 커지면 VLAN 분리는 결국 마주치는 과제입니다.

    5. 실전 팁

    • bridge-stp off: 단일 스위치 환경에선 STP 꺼도 됩니다(루프 위험 없을 때).
    • 본딩(bond): NIC가 여러 개면 본딩으로 이중화·대역폭 확장 가능.
    • 관리망 분리: 규모가 커지면 Proxmox 관리 접속용 망을 따로 두는 걸 권장.

    6. 정리

    Proxmox 네트워크의 기본은 Linux Bridge(가상 스위치)이고, 분리가 필요하면 VLAN(논리 분할)을 얹습니다. 대부분은 vmbr0 하나로 시작해 충분하고, 서비스가 많아지면 VLAN으로 넘어가면 됩니다. 브리지가 어떻게 물리 NIC와 게스트를 잇는지만 이해하면, Proxmox 네트워크는 더 이상 미스터리가 아닙니다.

  • Proxmox 백업 vzdump 완전 정리 — 스냅샷 말고 진짜 백업 걸기

    지난 ZFS 글에서 “스냅샷은 백업이 아니다”라고 했습니다. 그럼 Proxmox에서 진짜 백업은 어떻게 할까요? 답은 vzdump입니다. VM·컨테이너를 통째로 백업하는 Proxmox 내장 도구인데, 솔직히 저도 아직 예약 백업을 안 걸어둔 상태라 이번 기회에 제대로 정리합니다.

    1. vzdump이 하는 일

    vzdump은 VM/LXC 전체를 하나의 아카이브로 백업합니다. 스냅샷(같은 디스크 안의 되돌리기)과 달리, 별도 스토리지(NAS 등)에 복제본을 만드는 진짜 백업입니다.

    • 디스크가 통째로 죽어도 복구 가능
    • 다른 노드·다른 서버로 이전 가능
    • 보관 개수를 정해 자동 로테이션

    2. 백업 모드 3가지

    모드 다운타임 특징
    snapshot 거의 없음 실행 중 백업(권장)
    suspend 잠깐 정지 중간 안전성
    stop 완전 정지 가장 일관적

    대부분 snapshot 모드면 충분합니다. 실행 중인 서비스를 멈추지 않고 백업하니까요(단, DB처럼 일관성이 중요하면 stop 고려).

    3. 수동 백업 — 한 줄

    # LXC 113을 NAS 스토리지에 snapshot 모드로 백업
vzdump 113 --mode snapshot --storage nas-backup --compress zstd

# 여러 개 한 번에
vzdump 112 113 124 --mode snapshot --storage nas-backup --compress zstd

    --compress zstd는 빠르고 압축률도 좋아 요즘 표준입니다. 백업 파일은 지정한 스토리지(예: NAS)에 .vma.zst(VM) / .tar.zst(LXC)로 쌓입니다.

    4. 예약 백업 (여기가 진짜 핵심)

    수동은 잊어버립니다. Proxmox 웹UI Datacenter → Backup → Add에서 예약을 겁니다. 핵심 설정은 —

    • 대상: 백업할 VM/LXC 선택(또는 전체)
    • 스토리지: 반드시 다른 디스크/NAS(같은 풀에 백업하면 의미 없음)
    • 스케줄: 예) 매일 새벽 3시
    • 보관(Retention): 일 7 / 주 4 / 월 3 등
    # /etc/pve/jobs.cfg 에 생성되는 예약 백업(예시)
vzdump: backup-daily
	schedule 03:00
	storage nas-backup
	mode snapshot
	compress zstd
	prune-backups keep-daily=7,keep-weekly=4

    5. 복구

    백업이 있으면 복구는 간단합니다. 웹UI에서 백업 파일 선택 → Restore, 또는 CLI로:

    # LXC 복구 (새 ID 113으로)
pct restore 113 /mnt/nas-backup/dump/vzdump-lxc-113-....tar.zst --storage local-zfs

    중요: 백업은 복구 테스트까지 해봐야 진짜 백업입니다. 한 번쯤 테스트 ID로 복구해 정상 부팅을 확인해 두세요.

    6. 정리 — 스냅샷 + vzdump = 완성

    스냅샷은 위험한 작업 직전의 빠른 되돌리기, vzdump은 다른 스토리지에 두는 진짜 백업입니다. 둘은 역할이 다르니 둘 다 써야 합니다. 저처럼 “스냅샷은 하는데 예약 백업은 아직”인 분이라면, 오늘 Datacenter → Backup에서 매일 백업 하나만 걸어두세요. 미래의 내가 고마워할 겁니다.

  • Proxmox cloud-init 템플릿으로 VM 즉시 찍어내기 — 설치 0분 배포

    학습용 VM을 매번 ISO로 OS 설치하고, 계정 만들고, SSH 키 넣고, IP 잡고… 이걸 반복하다 지치신 적 있나요? 저는 Proxmox cloud-init 템플릿으로 이 과정을 없앴습니다. 클론 한 번이면 부팅과 동시에 설정까지 끝난 VM이 나옵니다. 실제로 제 홈랩 학습 VM들이 이 방식으로 찍혀 나옵니다.

    1. cloud-init이 뭔가

    cloud-init은 클라우드 이미지가 첫 부팅 때 자기 자신을 설정하게 해주는 표준 도구입니다. 호스트명·사용자·비밀번호·SSH 키·네트워크(IP)를 부팅 시 주입받아 자동 구성합니다. AWS·OpenStack이 인스턴스를 찍어내는 원리와 같은 것을, Proxmox에서도 그대로 씁니다.

    2. 왜 템플릿 + cloud-init인가

    • 속도: OS 설치 0분. 클론 → 부팅이면 끝.
    • 일관성: 항상 같은 베이스에서 시작(학습·실습에 최적).
    • 자동 설정: SSH 키·IP까지 부팅과 동시에.

    실제로 제 홈랩엔 Ubuntu, Rocky 등 cloud-init 템플릿이 준비돼 있어서, 실습이 필요하면 몇 초 만에 새 VM을 뽑습니다.

    3. 템플릿 만들기 (한 번만)

    배포판이 제공하는 cloud 이미지(.img/.qcow2)를 받아서 VM에 붙이고 템플릿으로 변환합니다.

    # 1) cloud 이미지 다운로드 (예: Ubuntu)
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

# 2) 빈 VM 생성
qm create 9000 --name ubuntu-2404-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0

# 3) 이미지를 디스크로 임포트
qm importdisk 9000 noble-server-cloudimg-amd64.img local-zfs
qm set 9000 --scsihw virtio-scsi-single --scsi0 local-zfs:vm-9000-disk-0

# 4) cloud-init 드라이브 + 부팅 설정
qm set 9000 --ide2 local-zfs:cloudinit
qm set 9000 --boot c --bootdisk scsi0 --serial0 socket --vga serial0

# 5) 템플릿으로 변환
qm template 9000

    4. 템플릿에서 VM 즉시 찍어내기

    이제 실습 VM이 필요할 때마다 클론 + cloud-init 값만 지정하면 됩니다.

    # 템플릿(9000)에서 새 VM(201) 풀 클론
qm clone 9000 201 --name study-node1 --full

# cloud-init: 사용자·SSH키·고정 IP 주입
qm set 201 --ciuser myuser --sshkeys ~/.ssh/id_rsa.pub
qm set 201 --ipconfig0 ip=192.168.x.201/24,gw=192.168.x.1

qm start 201

    부팅되면 지정한 사용자·SSH 키·IP가 이미 적용돼 있어 바로 SSH 접속됩니다. OS 설치도, 초기 설정도 없습니다.

    5. 실전 팁

    • DHCP도 가능: 고정 IP 대신 --ipconfig0 ip=dhcp로 간단히.
    • 디스크 리사이즈: cloud 이미지는 작으니 qm resize 201 scsi0 +20G로 늘리면 cloud-init이 파일시스템까지 확장.
    • OpenStack 학습과 연결: 이 “이미지→인스턴스” 흐름이 바로 OpenStack의 Glance·Nova가 하는 일입니다. 원리가 같아요.
    • 골든 이미지: 자주 쓰는 패키지를 미리 넣어 템플릿을 만들면 클론 즉시 실전 투입 가능.

    6. 정리

    cloud-init 템플릿은 홈랩 생산성을 통째로 바꿉니다. 한 번 템플릿을 만들어 두면, 이후엔 클론 한 줄로 설정 완료된 VM이 나옵니다. 학습·실습으로 VM을 자주 만드는 분이라면 무조건 세팅해 두세요. 그리고 이 원리는 그대로 프라이빗 클라우드(OpenStack)의 인스턴스 배포로 이어집니다.

  • Proxmox 부팅 순서, onboot만으론 부족하다 — startup order 실전

    Proxmox 호스트를 재부팅했는데, 앱은 떴지만 그 앱이 붙어야 할 데이터베이스는 아직 안 떠서 서비스가 깨진 경험, 있으신가요? onboot=1만 켜두면 이런 일이 생깁니다. 이번 글은 부팅 자동 시작과 시작 순서(startup order) 이야기입니다 — 제 홈랩의 (아직 안 잡은) 현실과 함께요.

    1. onboot — 자동 시작의 기본

    Proxmox에서 onboot=1은 “호스트가 켜지면 이 게스트도 자동으로 시작”입니다. 제 홈랩의 주요 서비스는 전부 켜져 있습니다.

    # 컨테이너/VM 자동 시작 켜기
pct set 113 --onboot 1     # LXC
qm set 106 --onboot 1      # VM

# 현재 설정 확인
pct config 113 | grep onboot

    여기까지는 대부분 합니다. 문제는 “언제, 어떤 순서로”가 빠져 있다는 겁니다.

    2. 솔직한 고백 — 내 홈랩엔 순서가 없다

    제 홈랩을 점검해 보니 주요 서비스가 모두 onboot=1이지만 startup 순서·지연은 하나도 설정돼 있지 않았습니다. 즉 호스트가 부팅되면 다 같이 우르르 시작합니다.

    이게 왜 위험하냐면 — 예를 들어 앱 컨테이너가 DB 컨테이너보다 먼저 떠버리면, 앱이 DB에 붙지 못하고 에러를 뱉거나 죽습니다. 스토리지(NAS)에 의존하는 서비스가 NAS보다 먼저 뜨는 것도 마찬가지고요. 지금은 운 좋게 문제가 안 났지만, 의존성이 있는 서비스라면 시간문제입니다.

    3. 해결 — startup order와 지연

    Proxmox는 게스트별로 시작 순서(order)·시작 후 지연(up)·종료 대기(down)를 지정할 수 있습니다.

    # DB 먼저(order 낮을수록 먼저), 30초 뒤 다음
pct set 124 --startup order=1,up=30      # meal-db (먼저)
pct set 125 --startup order=2            # meal-app (DB 다음)

# 스토리지/NAS는 가장 먼저
pct set 100 --startup order=0,up=20      # nas-fileserver
    파라미터 의미
    order 시작 순서(작을수록 먼저, 종료는 역순)
    up 이 게스트 시작 후 다음까지 대기(초)
    down 종료 시 강제 종료 전 대기(초)

    핵심 원칙은 “의존 대상을 먼저”입니다. 스토리지 → DB → 애플리케이션 순으로 order를 매기고, 뒤 서비스가 준비될 시간을 up으로 벌어 주면 됩니다.

    4. 실전 팁

    • up 지연을 아끼지 말 것: DB가 완전히 준비되는 데 시간이 걸립니다. 10~30초 여유를 두면 경합이 사라집니다.
    • 종료는 역순: Proxmox가 order 역순으로 종료하므로, 앱이 먼저 내려가고 DB가 나중에 내려갑니다(정상).
    • order 없는 게스트는 맨 마지막: 순서를 지정하지 않으면 지정된 것들 뒤에 시작됩니다. 그래서 중요 의존성엔 반드시 order를 명시하세요.

    5. 정리

    onboot=1은 “자동 시작”일 뿐, “올바른 순서”까지 보장하지 않습니다. DB·스토리지에 의존하는 서비스가 있다면 --startup order,up으로 순서와 지연을 잡아 주세요. 저처럼 “지금까지 운 좋게 안 터진” 상태라면, 다음 재부팅에서 당하기 전에 미리 잡아두시길 권합니다. 저도 이 글을 쓰며 정리해야 할 숙제로 남겨둡니다.

  • Proxmox LXC 안에서 Docker 돌리기 — nesting·keyctl과 함정들

    Proxmox에서 어떤 서비스를 올릴 때, 무거운 VM을 통째로 띄우는 대신 가벼운 LXC 컨테이너 안에서 Docker를 돌리는 방법이 있습니다. 저는 사진 서버(Immich)도, 이 블로그 자동화 봇도 이 방식으로 운영합니다. 실제 설정과 반드시 알아야 할 함정을 정리합니다.

    1. 왜 VM이 아니라 LXC + Docker인가

    • 가볍다: LXC는 호스트 커널을 공유해서 VM보다 메모리·오버헤드가 훨씬 적습니다.
    • 빠르다: 부팅이 거의 즉시고, 자원 낭비가 적습니다.
    • Docker 생태계 그대로: compose 파일과 이미지를 그대로 씁니다.

    단, “다른 커널이 필요하다”거나 “강한 격리가 필수”라면 그땐 VM이 맞습니다. 일반적인 웹서비스·봇·셀프호스팅 앱이라면 LXC + Docker가 가성비 최고입니다.

    2. 핵심 — 두 개의 기능 플래그

    기본 LXC에 Docker를 깔면 안 돌아갑니다. 두 가지 features를 켜야 합니다.

    # 컨테이너(예: 113)에 nesting + keyctl 활성화
pct set 113 --features nesting=1,keyctl=1
    플래그 역할
    nesting=1 컨테이너 안에서 또 컨테이너(Docker) 실행 허용
    keyctl=1 Docker가 쓰는 커널 키링 접근 허용

    실제로 제 컨테이너들은 이렇게 잡혀 있습니다 — 봇 컨테이너는 nesting=1,keyctl=1, Immich 컨테이너는 nesting=1. 그리고 둘 다 unprivileged(비특권) 컨테이너입니다. 보안상 가능하면 unprivileged로 두는 걸 권합니다.

    3. Docker 설치

    플래그를 켜고 컨테이너를 재시작한 뒤, 안에서 평범하게 Docker를 설치하면 됩니다.

    # LXC 내부에서 (공식 스크립트)
curl -fsSL https://get.docker.com | sh
docker --version   # 예: Docker version 29.4.0
docker compose version

    4. 반드시 밟는 함정 — 좀비 프로세스

    여기서 많은 분이 당합니다. 컨테이너 안에서 자식 프로세스를 반복 생성하는 앱(브라우저 자동화, 이미지 변환 등)을 Docker로 돌리면, 죽은 자식이 좀비로 쌓입니다. 컨테이너의 PID 1이 이를 거두지 않기 때문입니다(저는 이걸로 좀비 307개를 만든 적이 있습니다 — 관련 글).

    # docker-compose.yml — tini를 PID 1로 넣어 좀비 자동 수거
services:
  app:
    image: my-app:latest
    init: true

    5. 그 외 실전 주의점

    • rootfs 용량: Docker 이미지·빌드 캐시가 금방 쌓입니다. LXC rootfs를 넉넉히(무거운 이미지는 16GB+) 잡고, docker builder prune을 주기적으로.
    • 데이터는 볼륨으로: 컨테이너를 갈아엎어도 데이터가 남게, 영구 데이터는 호스트 경로/NAS 볼륨에 마운트.
    • 백업: LXC 자체를 Proxmox 스냅샷/백업하면 Docker 스택까지 통째로 보존됩니다.

    6. 정리

    LXC + Docker는 홈랩에서 VM의 무게 없이 Docker 생태계를 쓰는 최적의 절충안입니다. 핵심은 딱 두 가지 — nesting=1과 keyctl=1을 켜는 것, 그리고 서브프로세스 앱엔 init: true를 잊지 않는 것. 이 두 개만 챙기면 미니 PC 한 대에 서비스를 훨씬 많이 얹을 수 있습니다.

  • 홈랩 트러블슈팅 회고 — 디스크 풀과 좀비 프로세스 307개를 잡은 실화

    홈랩은 잘 돌아갈 땐 조용하지만, 한 번 터지면 새벽까지 붙잡게 됩니다. 이번 글은 제가 실제로 겪고 해결한 두 가지 사건 — “빌드하다 디스크가 꽉 참”과 “좀비 프로세스 307개” — 을 그대로 복기합니다. 둘 다 홈랩에서 흔히 만나는 함정이라, 같은 벽에 부딪힌 분께 도움이 될 겁니다.

    사건 1. 컨테이너 빌드 중 “disk quota exceeded”

    Docker 이미지를 새로 빌드하는데 갑자기 실패했습니다.

    failed to solve: ... write ...: disk quota exceeded

    원인을 찾아보니 해당 LXC의 rootfs가 8GB였는데, 그 안에서 Playwright(헤드리스 크롬) 이미지를 재빌드하려니 공간이 부족했습니다. 크로미움을 포함한 이미지는 통째로 1GB를 훌쩍 넘고, 여기에 빌드 캐시가 눈덩이처럼 쌓여 순식간에 rootfs를 채운 겁니다.

    해결은 두 단계였습니다. 먼저 쌓인 빌드 캐시를 비우고,

    # 안 쓰는 빌드 캐시 전량 정리 (공간 즉시 회수)
docker builder prune -af

    그래도 빠듯해서 Proxmox 호스트에서 LXC rootfs를 온라인으로 확장했습니다(무중단).

    # LXC 113의 rootfs를 8G → 16G 로 확장
pct resize 113 rootfs +8G

    배운 것: 크로미움·플레이라이트처럼 무거운 이미지를 빌드하는 컨테이너는 rootfs를 처음부터 넉넉히(최소 16GB) 잡아야 합니다. 그리고 docker builder prune을 주기적으로 돌리지 않으면 빌드 캐시가 조용히 디스크를 잠식합니다. 빌드 전 df -h / 확인은 습관으로.

    사건 2. 좀비 프로세스가 307개까지 쌓였다

    어느 날 컨테이너 상태를 보니 좀비(zombie) 프로세스가 307개나 쌓여 있었습니다.

    # 좀비 프로세스 개수 확인
ps aux | awk '$8 ~ /Z/ {c++} END {print c}'

    범인은 헤드리스 크롬이었습니다. Playwright가 크로미움을 반복 실행/종료하는데, 자식 프로세스가 끝나면 부모가 그 종료 상태를 거둬(reap)줘야 합니다. 그런데 컨테이너의 PID 1(내 파이썬 앱)은 그 일을 하지 않습니다. 일반 리눅스라면 init이 고아 프로세스를 거두지만, 컨테이너 안엔 그 init이 없어서 죽은 크롬 프로세스가 계속 좀비로 남은 겁니다.

    해결은 가벼운 init(tini)을 PID 1로 넣는 것이었습니다. Docker Compose라면 한 줄이면 됩니다.

    services:
  app:
    image: my-bot:latest
    init: true   # tini가 PID 1이 되어 좀비를 자동 수거

    init: true를 켜자 좀비가 더 이상 쌓이지 않았습니다. tini가 PID 1로 앉아 자식들의 종료를 대신 거둬 주기 때문입니다.

    배운 것: 컨테이너 안에서 자식 프로세스를 반복 생성하는 앱(브라우저 자동화, 이미지 변환, 서브프로세스 호출 등)을 돌린다면 init: true는 선택이 아니라 필수입니다. 컨테이너의 PID 1은 “프로세스 청소부” 역할을 하지 않는다는 걸 꼭 기억하세요.

    정리 — 홈랩 삽질에서 얻은 두 습관

    사건 근본 원인 예방 습관
    디스크 풀 빌드 캐시 누적 + 작은 rootfs rootfs 넉넉히, builder prune 주기화, 빌드 전 df -h
    좀비 307개 컨테이너 PID 1이 자식 미수거 서브프로세스 앱엔 init: true

    둘 다 “알고 나면 별것 아니지만, 모르면 새벽을 태우는” 문제였습니다. 홈랩의 실력은 이런 삽질을 하나씩 기록하며 쌓이는 것 같습니다.

  • [Proxmox] Proxmox ZFS 메모리 사용량 최적화: ARC 캐시 튜닝 전략

    [Proxmox] Proxmox ZFS 메모리 사용량 최적화: ARC 캐시 튜닝 전략

    목차

    Proxmox ZFS 메모리 사용량 최적화: ARC 캐시 튜닝 전략

    안녕하세요, 13년차의 서버실입니다. 오늘은 홈랩이나 작은 서버 환경에서 Proxmox VE와 ZFS를 함께 사용하시는 분들이라면 한 번쯤 겪어보셨을 법한, 바로 메모리 사용량 최적화에 대한 이야기를 해볼까 합니다. 특히 ZFS의 ARC 캐시(Adaptive Replacement Cache) 때문에 램이 부족하다고 느끼는 경우가 많으실 텐데요. 제가 직접 여러 번의 삽질 끝에 찾아낸 ZFS 성능 튜닝 전략을 솔직하게 공유해드리겠습니다. 혹시 Proxmox 서버의 램이 항상 꽉 차 있는 것 같아 답답하셨다면, 이 글이 좋은 해결책이 될 거예요!

    Proxmox VE와 ZFS가 메모리를 사용하는 일반적인 아키텍처 다이어그램

    Proxmox VE와 ZFS가 메모리를 사용하는 일반적인 아키텍처 다이어그램입니다. ARC 캐시가 시스템 메모리에 어떻게 자리 잡는지 보여줍니다.

    ZFS ARC 캐시, 너는 누구니?

    ZFS를 사용하면 스토리지 성능을 극대화하기 위해 ARC 캐시(Adaptive Replacement Cache)라는 똑똑한 녀석이 작동합니다. 쉽게 말해, 자주 접근하는 데이터를 메모리에 미리 올려두어 디스크 I/O를 줄이고 속도를 높여주는 역할을 하죠. 웹 서버의 프록시 캐시나 데이터베이스의 버퍼 캐시와 비슷하다고 생각하시면 됩니다.

    근데 여기서 문제가 발생해요. ZFS는 기본적으로 시스템 메모리의 절반까지 ARC 캐시로 사용하도록 설계되어 있거든요. 예를 들어, 32GB 램을 가진 서버라면 ZFS는 최대 16GB를 ARC 캐시로 끌어다 쓸 수 있다는 거죠. 문제는 Proxmox VE 위에 가상머신(VM)이나 컨테이너(LXC)를 여러 개 돌리다 보면, 이 녀석들도 각자 램을 필요로 한다는 겁니다. 결국 ZFS ARC가 너무 많은 램을 차지해서 VM들이 램 부족에 시달리거나, 스왑(Swap)이 발생해서 전체적인 성능 저하로 이어지는 경우가 허다하더라고요. 저도 처음엔 이게 뭔가 싶었는데, 알고 보니 ARC 캐시가 범인이었죠.

    ARC 캐시, 이제 너를 길들이자!

    그럼 이 똑똑하지만 탐욕스러운 ARC 캐시를 어떻게 길들일 수 있을까요? 핵심은 zfs_arc_max라는 커널 파라미터를 조절하는 거예요. 이 값을 통해 ARC 캐시가 사용할 수 있는 최대 메모리 양을 제한할 수 있습니다. 저도 이 값을 찾기 위해 꽤나 삽질을 했었는데, 몇 번의 시행착오 끝에 안정적인 방법을 찾았으니 너무 걱정 마세요!

    단계별로 차근차근 따라 해보시면 돼요. 중요한 건, 자신의 서버 환경과 워크로드를 고려해서 적절한 값을 찾아야 한다는 점이에요. 무작정 너무 낮게 설정하면 오히려 ZFS 성능이 떨어질 수 있으니 주의해야 합니다.

    1. ZFS 모듈 설정 파일 생성 및 수정:
      /etc/modprobe.d/zfs.conf 파일을 만들거나 수정해서 ARC 캐시의 최대 크기를 설정합니다. 저는 보통 최소 1GB, 최대 4GB 정도로 설정해서 사용하고 있어요. 램이 넉넉하다면 더 여유 있게 잡아도 좋고요. 값은 바이트 단위로 입력해야 합니다. 예를 들어 4GB는 4294967296입니다.

      # /etc/modprobe.d/zfs.conf 파일 생성 또는 편집
sudo nano /etc/modprobe.d/zfs.conf

      options zfs zfs_arc_min=1073741824  # 1GB
options zfs zfs_arc_max=4294967296  # 4GB

      위 예시는 ARC 캐시의 최소 크기를 1GB, 최대 크기를 4GB로 제한하는 설정입니다. zfs_arc_min은 ARC 캐시가 최소한으로 유지할 메모리 양을 지정하며, zfs_arc_max는 ARC 캐시가 최대로 사용할 수 있는 메모리 양을 지정해요.

    2. initramfs 업데이트:
      커널 모듈 설정을 시스템에 적용하려면 initramfs를 업데이트해야 합니다. 이 작업은 재부팅 시 ZFS 드라이버가 새로운 설정값을 가지고 로드되도록 해줍니다.

      sudo update-initramfs -u -k all

    3. 시스템 재부팅:
      모든 변경 사항을 적용하려면 시스템을 재부팅해야 합니다. 재부팅 후에 새로운 ARC 캐시 설정이 적용돼요.

      sudo reboot
    ZFS ARC 캐시 설정을 위해 zfs.conf 파일을 편집하는 터미널 화면

    터미널에서 zfs.conf 파일을 편집하는 모습입니다. 정확한 파라미터 설정을 확인하세요.

    ⚠️ 주의사항 및 트러블슈팅: 제가 겪었던 삽질

    제가 처음 이 설정을 만지면서 겪었던 가장 큰 삽질은 zfs_arc_max 값을 너무 낮게 설정한 거였어요. 제 홈랩 서버는 16GB 램을 사용하고 있었고, Proxmox 위에 VM 몇 개랑 Plex 서버까지 돌리느라 램이 항상 부족했거든요. 그래서 욕심이 과해서 ARC 캐시를 512MB(536870912 바이트)로 확 줄여버렸죠. 결과는요? VM들의 디스크 I/O 성능이 눈에 띄게 저하되고, 특히 ZFS 스토리지에 있는 파일들을 읽어올 때 버벅거림이 심해지더라고요. Plex 서버에서 영화를 재생하는데 계속 끊기는 현상까지 발생해서 멘붕이 왔었습니다. 😭

    이 경험을 통해 깨달은 것은 워크로드에 맞는 적절한 값을 찾는 것이 정말 중요하다는 거예요. 아무리 램이 부족해도, ZFS가 캐시로 쓸 최소한의 공간은 보장해줘야 해요. 저는 결국 1GB ~ 2GB 정도로 다시 설정하고 나서야 안정적인 성능을 되찾을 수 있었습니다.

    만약 설정 후 문제가 발생했다면, /etc/modprobe.d/zfs.conf 파일을 다시 편집해서 options zfs zfs_arc_min=... zfs_arc_max=... 줄을 주석 처리(#)하거나 삭제한 후, 다시 sudo update-initramfs -u -k all 명령을 실행하고 재부팅하면 기본값으로 되돌릴 수 있어요.

    검증 및 결과 확인: 드디어 됐다! 🎉

    설정을 변경하고 재부팅했다면, 이제 제대로 적용되었는지 확인해야겠죠? 다음 명령어를 통해 현재 시스템에 적용된 ARC 캐시의 최대 크기를 확인할 수 있습니다.

    cat /sys/module/zfs/parameters/zfs_arc_max
cat /sys/module/zfs/parameters/zfs_arc_min

    이 명령어로 출력되는 값이 여러분이 zfs.conf 파일에 설정한 바이트 단위의 값과 일치한다면 성공적으로 적용된 거예요! 그리고 실제 ARC 캐시의 동작을 더 자세히 보고 싶다면 arc_summary 도구를 사용해보세요. 이 도구는 ZFS ARC 캐시의 상세 통계를 보여줍니다. arc_summary는 zfsutils-linux 또는 zfs-initramfs 패키지에 포함되어 있는데, 설치되어 있지 않다면 다음 명령으로 설치할 수 있습니다.

    sudo apt install zfsutils-linux

    arc_summary

    arc_summary 출력에서 ARC Size와 Min Size, Max Size 항목을 보면 현재 ARC 캐시가 얼마나 사용되고 있고, 설정된 제한 범위는 얼마인지 한눈에 파악할 수 있어요. 💡 팁: arc_summary를 정기적으로 모니터링하면서, 실제 워크로드에 따라 Max Size에 가까워지는지, 아니면 여유가 있는지 확인해보세요. 만약 Max Size에 항상 도달해있는데도 시스템 성능이 만족스럽지 않다면, 조금 더 여유를 주는 방향으로 zfs_arc_max 값을 늘려볼 수도 있습니다.

    arc_summary 명령어를 통해 ZFS ARC 캐시 사용량과 설정된 최대값을 확인하는 화면

    arc_summary 명령어 실행 결과 화면입니다. ARC 캐시의 현재 사용량과 설정된 최대/최소값을 확인할 수 있습니다.

    ARC 캐시 튜닝 가이드라인

    어떤 값을 설정해야 할지 고민이신 분들을 위해, 제가 경험했던 상황별 가이드라인을 표로 정리해봤습니다. 물론 절대적인 기준은 아니지만, 시작점으로 삼기에는 충분할 거예요.

    서버 환경/용도 전체 시스템 RAM 권장 zfs_arc_max (예시) 추가 고려사항
    홈랩/NAS (가벼운 VM, 파일 공유) 8GB ~ 16GB 2GB ~ 4GB VM에 할당할 램을 우선 고려하고, 파일 I/O가 아주 빈번하지 않다면 낮게 설정.
    미디어 서버 (Plex, Jellyfin) 16GB ~ 32GB 4GB ~ 8GB 대용량 미디어 파일 스트리밍이 많으므로, 캐시를 충분히 확보하여 I/O 부하 감소.
    경량 개발/테스트 서버 (VM 다수) 32GB 이상 8GB ~ 16GB VM 개수와 각 VM의 램 할당량을 기준으로, 남는 램을 ARC에 배분.
    고성능 스토리지 서버 (DB, IOPS 중요) 64GB 이상 전체 램의 1/4 ~ 1/2 ZFS 본연의 성능을 최대로 활용하기 위해 충분한 ARC 할당. VM 램과 균형 중요.
    Proxmox ZFS ARC 캐시 튜닝의 이점과 모범 사례를 요약한 인포그래픽

    ZFS ARC 캐시 튜닝의 주요 이점과 모범 사례를 요약한 인포그래픽입니다.

    마무리하며: 나에게 맞는 최적의 값을 찾아서!

    Proxmox ZFS 환경에서 메모리 사용량 최적화는 단순히 램을 아끼는 것을 넘어, 전체 시스템의 안정성과 성능에 직접적인 영향을 미치는 중요한 작업입니다. zfs_arc_max 값을 튜닝함으로써 ZFS ARC 캐시가 과도하게 메모리를 점유하는 것을 막고, 가상머신이나 다른 서비스들이 충분한 리소스를 확보할 수 있도록 도울 수 있어요.

    제가 겪었던 삽질처럼 너무 극단적인 값으로 설정하기보다는, 위에서 제시된 가이드라인을 참고하여 자신의 워크로드와 서버 사양에 맞는 최적의 값을 찾아가는 과정이 필요합니다. 처음에는 조금 어렵게 느껴질 수 있지만, 몇 번의 시도와 모니터링을 통해 분명 만족스러운 결과를 얻으실 수 있을 거예요. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 다음에는 ZFS 성능 모니터링 도구들에 대해 좀 더 자세히 다뤄볼까 합니다. 다음에 또 만나요! 👋

  • [Proxmox] Proxmox 백업 전략 비교: PBS, NAS, 클라우드 중 무엇을 선택할까?

    [Proxmox] Proxmox 백업 전략 비교: PBS, NAS, 클라우드 중 무엇을 선택할까?

    목차

    Proxmox 백업 전략 비교: PBS, NAS, 클라우드 중 무엇을 선택할까?

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩에서 Proxmox VE(Virtual Environment)를 운영하시는 분들이라면 한 번쯤은 ‘내 소중한 가상 머신(VM)이랑 컨테이너(LXC) 데이터, 어떻게 안전하게 백업해야 할까?’ 하는 고민을 해보셨을 거예요. 저도 처음엔 대수롭지 않게 생각했다가, 디스크 장애로 모든 데이터를 날릴 뻔한 아찔한 경험을 하고 나서 백업의 중요성을 뼈저리게 느꼈거든요. 그때부터 백업 전략에 진심이 됐죠. 오늘은 Proxmox 환경에서 가장 많이 고려하는 세 가지 백업 전략, 바로 Proxmox Backup Server (PBS), NAS (Network Attached Storage), 그리고 클라우드 백업을 제 경험을 바탕으로 비교 분석해 드릴게요. 어떤 선택이 여러분의 홈랩에 딱 맞을지 함께 고민해 봅시다!

    Proxmox 환경에서 백업 데이터가 여러 저장소로 이동하는 전체적인 아키텍처 다이어그램입니다.

    1. Proxmox 백업, 왜 중요할까요?

    솔직히 백업은 평소엔 귀찮고 비용만 드는 일처럼 느껴질 때가 많잖아요? 저도 그랬습니다. 하지만 데이터 손실은 언제든 일어날 수 있는 현실이에요. 하드웨어 고장, 소프트웨어 오류, 심지어는 실수로 인한 삭제까지요. 특히 Proxmox는 여러 VM과 LXC를 한데 모아 운영하는 만큼, 하나의 장애가 전체 서비스 중단으로 이어질 수 있습니다. 그래서 정기적인 백업과 복구 계획은 선택이 아니라 필수거든요. 백업은 단순히 데이터를 저장하는 것을 넘어, 비상 상황 시 서비스를 빠르게 복구하고 비즈니스 연속성(Business Continuity)을 확보하는 핵심 과정이에요.

    2. Proxmox 백업 전략, 세 가지 주요 선택지

    Proxmox 백업을 위한 다양한 방법 중, 가장 대표적인 세 가지를 설명해 드릴게요.

    2.1. Proxmox Backup Server (PBS) – Proxmox에 최적화된 백업 솔루션

    PBS는 Proxmox VE 개발팀이 직접 만든 백업 솔루션이에요. 쉽게 말해, Proxmox VE 백업을 위해 태어난 전용 서버라고 보시면 됩니다. 얘의 가장 큰 장점은 바로 블록 레벨 중복 제거(Block-level Deduplication)와 증분 백업(Incremental Backup)이에요. 처음 백업할 때는 모든 데이터를 다 저장하지만, 다음 백업부터는 변경된 블록만 저장해서 백업 공간을 엄청나게 절약해 줍니다. 게다가 데이터 무결성 검사(Data Integrity Checks) 기능도 있어서 백업된 데이터가 손상되지 않았는지 주기적으로 확인해 주니 얼마나 든든한지 몰라요. 제가 직접 써보니, 여러 Proxmox VE 호스트를 운영하는 경우 중앙에서 효율적으로 백업을 관리할 수 있어서 정말 편하더라고요.

    2.2. NAS (Network Attached Storage) – 쉽고 친숙한 로컬 백업

    NAS는 이름 그대로 네트워크에 연결된 저장 장치를 의미합니다. 시놀로지(Synology)나 큐냅(QNAP) 같은 제품들이 대표적이죠. Proxmox VE에서 NFS(Network File System)나 SMB/CIFS(Server Message Block/Common Internet File System) 프로토콜을 이용해 NAS를 백업 저장소로 연결하는 방식이에요. 특별한 소프트웨어 설치 없이 Proxmox VE 자체 백업 기능을 활용할 수 있다는 게 장점입니다. 접근성이 좋고 사용법이 직관적이라 홈랩에서 많이들 사용하시죠. 저도 처음엔 NAS에 백업을 많이 했었는데, 설정만 잘하면 가장 빠르게 백업을 시작할 수 있는 방법이거든요.

    2.3. 클라우드 백업 – 안전한 오프사이트(Offsite) 저장소

    클라우드 백업은 아마존 S3(Amazon S3), 구글 클라우드 스토리지(Google Cloud Storage), 백블레이즈 B2(Backblaze B2), 혹은 마이크로소프트 애저 블롭 스토리지(Microsoft Azure Blob Storage) 같은 원격 클라우드 저장소에 백업 데이터를 올리는 방식입니다. 가장 큰 장점은 지리적 분산(Geographical Distribution)이에요. 만약 홈랩에 화재나 도난 같은 큰 재해가 발생해도 클라우드에 저장된 데이터는 안전하죠. 주로 rclone 같은 도구를 사용해서 Proxmox VE에서 생성된 백업 파일을 클라우드로 동기화하는 방식으로 많이 사용합니다. 백업 속도는 인터넷 회선에 따라 달라지지만, 재해 복구(Disaster Recovery) 관점에서 보면 최고의 선택지 중 하나거든요.

    3. 실전 구현: Proxmox 백업 저장소 구성 및 백업 명령어

    각 전략별로 Proxmox VE에서 어떻게 백업 저장소를 구성하고 백업을 실행하는지 간단한 예시를 보여드릴게요.

    3.1. Proxmox Backup Server (PBS) 연결 및 백업

    PBS를 별도의 서버에 설치하고 나면, Proxmox VE 웹 GUI에서 Datacenter > Storage > Add > Proxmox Backup Server를 선택해서 연결할 수 있습니다. 필요한 정보는 PBS 서버의 IP 주소, 포트(기본 8007), 사용자 이름, 비밀번호, 그리고 인증서 지문(Fingerprint)이에요. 연결 후에는 일반 스토리지처럼 백업 작업을 스케줄링할 수 있습니다.

    CLI에서 특정 VM을 PBS로 백업하려면 다음과 같이 명령을 사용해요:

    # Proxmox VE 호스트에서 실행
qm backup <VMID> --storage <PBS_Storage_ID> --mode snapshot --compress zstd
# 예시: VM 101을 'pbs-backup'이라는 스토리지 ID로 스냅샷 모드, zstd 압축을 사용하여 백업
qm backup 101 --storage pbs-backup --mode snapshot --compress zstd

    <VMID>는 백업할 가상 머신의 ID이고, <PBS_Storage_ID>는 Proxmox VE에 등록한 PBS 저장소의 ID입니다. --mode snapshot은 VM이 실행 중인 상태에서 백업하는 방식이고, --compress zstd는 Zstandard 압축을 사용하겠다는 의미예요. PBS는 이 압축률이 상당히 좋더라고요.

    3.2. NAS (NFS) 연결 및 백업

    NAS를 NFS로 연결하는 방법은 Proxmox VE 호스트에 직접 마운트하는 방식이 일반적입니다. 먼저 SSH로 Proxmox VE에 접속해서 마운트 포인트를 만들고, NAS의 NFS 공유를 마운트합니다.

    # Proxmox VE 호스트에서 실행
mkdir -p /mnt/pve/nasbackup
mount -t nfs 192.168.1.100:/volume1/proxmox_backup /mnt/pve/nasbackup
# 부팅 시 자동 마운트를 위해 /etc/fstab에 추가 (주의: 반드시 테스트 후 적용!)
# 192.168.1.100:/volume1/proxmox_backup /mnt/pve/nasbackup nfs defaults 0 0

    마운트가 성공하면, Proxmox VE 웹 GUI에서 Datacenter > Storage > Add > Directory를 선택하고, Directory 경로에 /mnt/pve/nasbackup을 입력하여 저장소로 추가합니다. Content에는 백업(VZDump backup file)을 꼭 선택해 주세요.

    3.3. 클라우드 백업 (rclone 사용)

    클라우드 백업은 Proxmox VE에서 직접 클라우드 저장소를 연결하기보다는, NAS로 백업된 파일이나 로컬 저장소에 백업된 파일을 rclone 같은 도구를 이용해 클라우드로 동기화하는 방식을 추천해요. 저는 보통 NAS로 1차 백업을 하고, 그 NAS의 백업 폴더를 rclone으로 클라우드에 2차 백업하는 방식을 선호합니다.

    # rclone 설치 및 설정 (설정은 `rclone config` 명령어로 대화형으로 진행)
# rclone config 설정 시, 원격 저장소 이름 (예: 'b2_proxmox')과 자격 증명을 입력합니다.

# Proxmox VE 백업 디렉토리에 있는 파일을 Backblaze B2 (b2_proxmox)로 동기화
rclone sync /var/lib/vz/dump/ b2_proxmox:proxmox-backups/ --fast-list --progress --log-file /var/log/rclone_sync.log

    rclone sync 명령어는 소스 디렉토리와 대상 클라우드 저장소를 동기화합니다. --fast-list는 큰 디렉토리에서 빠르게 목록을 가져오고, --progress는 진행 상황을 보여주며, --log-file은 로그를 파일로 기록합니다. 이 명령어를 cron에 등록해서 주기적으로 실행하면 클라우드 백업이 자동화돼요.

    Proxmox VE 웹 인터페이스에서 성공적으로 완료된 백업 작업 로그 스크린샷

    Proxmox VE 웹 GUI에서 성공적으로 완료된 백업 작업의 로그 화면입니다.

    4. 주의사항 및 삽질 경험 공유: NAS NFS 권한 문제

    제가 NAS를 백업 저장소로 사용하면서 가장 많이 삽질했던 부분이 바로 NFS 권한 문제였어요. 분명히 마운트는 됐는데, Proxmox VE에서 백업을 시작하면 ‘permission denied’ 오류가 뜨는 겁니다. 처음엔 Proxmox VE 호스트의 사용자 권한 문제인 줄 알고 여러 설정을 바꿔봤는데, 알고 보니 NAS 쪽 NFS 공유 설정 문제였더라고요. Proxmox VE는 백업 파일을 생성할 때 root 권한으로 접근하려고 하는데, NAS의 NFS 공유 설정에서 root squash가 활성화되어 있으면 root 권한이 일반 사용자 권한으로 매핑되어 버립니다. 그래서 쓰기 권한이 없어져 버리는 거죠.

    해결 방법: NAS의 NFS 공유 설정에서 해당 공유 폴더에 대해 ‘root squash’를 ‘no_root_squash’로 변경해야 합니다. 시놀로지 NAS의 경우 제어판 > 파일 서비스 > NFS > NFS 고급 설정 > 루트와 동일한 권한으로 모든 클라이언트에게 액세스 허용 (또는 유사한 옵션)을 체크하거나, 특정 IP에 대해 ‘root squash’ 설정을 변경하는 옵션을 찾아보세요. 이 설정을 변경하고 나니 백업이 드디어 성공하더라고요! 🥳

    5. Proxmox 백업 전략 비교: 무엇을 선택할까?

    세 가지 전략의 장단점을 정리한 비교표를 보면서 어떤 선택이 여러분의 상황에 가장 적합할지 함께 고민해 봅시다.

    구분 Proxmox Backup Server (PBS) NAS (NFS/SMB) 클라우드 백업 (rclone)
    장점
    • Proxmox VE에 최적화된 성능
    • 블록 레벨 중복 제거로 공간 효율 극대화
    • 증분 백업 지원
    • 데이터 무결성 검사
    • Proxmox VE GUI 통합 및 쉬운 관리
    • 빠른 복구 속도 (로컬 네트워크)
    • 설정 간편 (친숙한 NAS 인터페이스)
    • 비교적 저렴한 초기 비용
    • 로컬 네트워크 내 빠른 백업/복구
    • 다목적 사용 가능 (파일 서버 등)
    • 최고의 재해 복구 능력 (오프사이트)
    • 무제한에 가까운 확장성
    • 물리적 재해로부터 안전
    • 관리 부담 적음 (인프라)
    단점
    • 별도 서버 또는 VM 필요 (하드웨어 자원 소모)
    • 초기 설정 학습 필요
    • 로컬 저장소에 의존 (오프사이트 백업 필요)
    • 중복 제거 기능 미약 (Proxmox 자체 기능 사용 시)
    • 데이터 무결성 검사 부족
    • 오프사이트 백업 미지원
    • 성능이 NAS 자체에 따라 제한적
    • 인터넷 대역폭에 따른 백업/복구 속도 제한
    • 지속적인 운영 비용 발생
    • 복잡한 rclone 설정 (초심자에게)
    • 데이터 유출 위험 (보안 고려 필요)
    적합한 경우
    • 다수의 Proxmox VE 호스트 운영
    • 백업 공간 효율이 중요한 경우
    • 빠른 복구와 데이터 무결성 중시
    • 전용 백업 솔루션 도입 의지
    • 단일 Proxmox VE 호스트 운영
    • 간단하고 빠른 백업 구성 선호
    • 초기 비용 절감 중요
    • 다른 용도로 NAS를 이미 사용 중
    • 강력한 재해 복구 계획 필요
    • 오프사이트 백업이 필수인 경우
    • 물리적 저장 공간 제약
    • 백업 데이터 보안에 대한 이해
    Proxmox 백업 전략 (PBS, NAS, 클라우드) 핵심 특징 및 장단점 비교 인포그래픽

    Proxmox 백업 전략별 주요 특징과 고려사항을 요약한 인포그래픽입니다.

    6. 결론: 당신의 홈랩에 맞는 백업 전략은?

    각 백업 전략은 고유한 장단점이 있기 때문에, 어떤 것이 ‘최고’라고 단정하기는 어렵습니다. 중요한 것은 여러분의 홈랩 규모, 예산, 그리고 가장 중요하게 생각하는 가치(속도, 공간 효율, 재해 복구 등)에 따라 최적의 조합을 찾는 것이에요.

    제 경험을 바탕으로 몇 가지 시나리오를 제안해 드릴게요.

    • 작은 홈랩 (Proxmox VE 1대, 예산 제한적): NAS 백업만으로도 충분히 시작할 수 있습니다. 이미 가지고 있는 NAS가 있다면 가장 저렴하고 빠르게 백업 환경을 구축할 수 있죠. 다만, 오프사이트 백업은 꼭 고려해 주세요.
    • 성장하는 홈랩 (Proxmox VE 2대 이상, 백업 데이터 많음): PBS를 적극 추천합니다. 중복 제거와 증분 백업 기능으로 백업 공간을 효율적으로 사용하고, 중앙에서 백업 관리가 정말 편리하거든요. 별도의 서버가 부담된다면, Proxmox VE 호스트 중 하나에 VM으로 PBS를 설치하는 방법도 고려해 볼 수 있어요 (물론, 백업 서버와 원본 서버가 동일 호스트에 있으면 재해 발생 시 위험이 커지니 추천하지는 않습니다. 가능하면 별도 물리 서버에 구축하는 것이 좋아요).
    • 최고의 안정성 (재해 복구 필수): PBS + 클라우드 백업 조합이 가장 이상적입니다. PBS로 빠르고 효율적인 로컬 백업을 하고, 이 백업 데이터를 rclone 등을 통해 클라우드에 2차로 동기화하는 거죠. 이중 백업 전략(3-2-1 Rule: 3개의 복사본, 2가지 미디어, 1개 오프사이트)을 충족시켜 최고의 안정성을 확보할 수 있습니다. 초기 설정은 복잡하지만, 한번 구축해두면 마음이 정말 편안하더라고요.

    결론적으로, 저는 홈랩 규모가 커질수록 Proxmox Backup Server(PBS)의 도입을 강력히 권장합니다. 그리고 어떤 전략을 선택하시든, 오프사이트 백업은 반드시 병행하시라고 말씀드리고 싶어요. 백업은 단순히 데이터를 저장하는 것을 넘어, 언젠가 찾아올지 모르는 재앙에 대비하는 보험과도 같으니까요.

    다음 글에서는 PBS를 직접 설치하고 설정하는 방법에 대해 더 자세히 다뤄볼 예정이니 기대해주세요! 백업은 꾸준함이 생명입니다. 여러분의 소중한 데이터를 안전하게 지키세요! 💪