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. 스냅샷, 복제, 백업의 책임 경계부터 정하세요

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

현장에서 쓰기 좋은 결론은 이렇습니다. 작업 전에는 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 스냅샷이 낫습니다.

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

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

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

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

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

# 예시: 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 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

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

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

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

또 하나, 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 데이터 보호 전략의 뼈대입니다.

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