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

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

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

▲ 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로 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에서 자동 백업 스케줄을 설정하는 화면 — 스토리지, 시간, 압축 방식을 직관적으로 설정할 수 있습니다.

복원(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

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

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

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

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

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

클라우드 동기화는 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에서 스토리지 재구성 후 복원 진행

▲ 재해 복구 전략 요약 인포그래픽 — 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년 동안 서버 운영하면서 배운 가장 중요한 교훈 하나를 드리고 마칠게요. “백업은 있는데 복원은 안 된다”는 건 백업이 없는 것과 같습니다. 오늘 바로 복원 테스트 한 번 해보시는 거 어떨까요? 🎉