[가상화] Proxmox ZFS 스토리지, 흔한 문제와 해결책

홈랩이나 사내 가상화 환경을 운영하다 보면 Proxmox ZFS 문제는 생각보다 빨리 한 번쯤 만나게 됩니다. 처음엔 VM만 잘 뜨면 끝인 줄 알았는데, 실제로 써보니까 스토리지가 흔들리면 전체 운영이 같이 흔들리더라고요. 특히 ZFS(File System, 체크섬과 복구 기능이 강한 파일 시스템) 기반으로 Proxmox VE(가상화 플랫폼)를 굴릴 때는 디스크 상태, 메모리 여유, 풀(pool) 구성, 스냅샷 관리가 다 연결되어 있습니다. 저도 처음엔 이게 뭔가 싶었는데, 에러 메시지는 짧고 증상은 묘하게 길게 이어져서 삽질 좀 했습니다 ㅎㅎ

이번 글에서는 제가 홈랩과 테스트 서버에서 직접 부딪히며 정리한 Proxmox 스토리지 운영 팁을 기준으로, 자주 보이는 ZFS 에러, 성능 저하, 풀 손상 징후, 그리고 데이터 복구 접근 순서를 정리해보겠습니다. 단순히 명령어만 던지는 글이 아니라, 왜 이런 문제가 생기고 어떤 순서로 확인해야 덜 망가지는지까지 같이 보실 수 있게 구성했습니다.

Proxmox 호스트, ZFS 풀, VM 디스크, 백업 저장소의 관계를 한눈에 보여주는 개요 이미지입니다.

1. 왜 Proxmox ZFS 문제가 자주 체감될까요?

쉽게 말해 ZFS는 그냥 디스크 묶음이 아니라, 스토리지 관리자 + 파일 시스템 + 무결성 검사기 역할을 같이 합니다. 그래서 장점이 큽니다. 체크섬(checksum, 데이터 변조나 손상 여부를 확인하는 값) 기반으로 데이터 무결성을 챙기고, 스냅샷(snapshot, 특정 시점 상태 저장)도 편하고, 미러(mirror)나 RAIDZ 같은 구성도 안정적으로 가져갈 수 있거든요.

근데 여기서 중요한 포인트가 있습니다. ZFS는 문제를 숨기기보다 드러내는 편입니다. 디스크가 애매하게 고장 나기 시작하면 ext4 같은 단순 파일 시스템에서는 조용히 지나갈 수도 있는 이상 징후를 ZFS가 읽기/쓰기 오류로 먼저 드러내는 경우가 있었습니다. 운영자 입장에서는 무섭죠. 하지만 길게 보면 이게 오히려 안전합니다.

• 디스크 자체 불량: SATA 케이블, HBA(Host Bus Adapter, 스토리지 연결 카드), SSD 펌웨어 문제까지 포함됩니다.
• 메모리 부족: ARC(Adaptive Replacement Cache, ZFS 메모리 캐시)가 압박을 받으면 체감 성능이 떨어집니다.
• 풀 용량 과다 사용: 여유 공간이 적으면 쓰기 성능이 급격히 흔들릴 수 있습니다.
• 과도한 스냅샷: 삭제 정책 없이 쌓아두면 관리도 복잡해지고 공간 회수도 꼬입니다.
• 불균형한 풀 설계: VM 랜덤 I/O와 백업 대용량 쓰기를 같은 풀에 몰아넣으면 병목이 생깁니다.

저는 예전에 테스트한다고 VM 이미지, ISO, 백업, 템플릿을 한 풀에 다 넣었다가 야간 백업 시간만 되면 지연(latency, 응답 지연)이 튀는 걸 겪었습니다. 처음엔 네트워크 문제인 줄 알았는데, 결국 스토리지 쪽이더라고요.

2. ZFS 핵심 개념, 운영자가 꼭 알아야 하는 것만

2-1. pool, vdev, dataset 차이

처음 ZFS를 접하면 용어부터 헷갈립니다. 저도 그랬습니다. 쉽게 말해 아래처럼 이해하시면 됩니다.

2-2. scrub와 resilver는 다릅니다

scrub은 전체 데이터를 읽으면서 손상 여부를 검사하는 작업이고, resilver는 디스크 교체 후 필요한 데이터를 다시 맞춰 넣는 작업입니다. 이름이 비슷해서 초반엔 헷갈리는데, 역할이 다릅니다. 운영 중에는 scrub 결과를 주기적으로 확인하는 습관이 정말 중요합니다.

2-3. ZFS는 여유 공간이 성능입니다

이 부분은 경험상 진짜 중요합니다. 풀 사용률이 높아질수록 메타데이터 처리와 쓰기 패턴이 불리해져서, 같은 SSD라도 체감이 확 달라집니다. 그래서 저는 실서비스든 홈랩이든 풀 여유 공간을 충분히 남겨두는 것을 우선 원칙으로 둡니다.

3. 실전 점검: Proxmox 스토리지 기본 진단 순서

Proxmox ZFS 문제가 생겼을 때 제일 위험한 건, 원인도 모른 채 디스크를 막 빼거나 재부팅부터 하는 겁니다. 실제로 써보니까 순서가 중요하더라고요. 저는 보통 아래 순서로 갑니다.

1. 현재 풀 상태 확인
2. 읽기/쓰기/체크섬 오류 확인
3. 디스크 식별 정보와 SMART 상태 점검
4. 용량, 압축, 스냅샷 과다 여부 확인
5. Proxmox 작업 로그와 커널 메시지 확인
6. 필요하면 scrub 또는 교체 작업 진행

3-1. 가장 먼저 볼 명령어

zpool status -v
zpool list
zfs list
zfs get compressratio,used,available,mountpoint -r rpool

zpool status -v는 거의 출발점입니다. 여기에 읽기 오류(read errors), 쓰기 오류(write errors), 체크섬 오류(checksum errors), DEGRADED 상태, OFFLINE 디스크, 최근 scrub 결과가 다 모여 있거든요.

예를 들어 상태가 아래처럼 나오면 디스크 이상을 의심해볼 수 있습니다.

pool: tank
state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.
scan: scrub repaired 0B in 02:11:00 with 0 errors on Sun Aug 10 02:11:00 2026
config:

    NAME        STATE     READ WRITE CKSUM
    tank        DEGRADED     0     0     0
      mirror-0  DEGRADED     0     0     0
        sda     ONLINE       0     0     0
        sdb     UNAVAIL      0     0     0

이런 경우 저는 먼저 “진짜 디스크 고장인가, 연결 문제인가”를 분리해서 봅니다. SATA 환경에서는 케이블 불량이 생각보다 자주 있습니다.

3-2. 디스크 식별과 SMART 확인

ls -l /dev/disk/by-id/
smartctl -a /dev/sda
smartctl -a /dev/sdb

가능하면 /dev/sdX보다 /dev/disk/by-id/ 기준으로 실제 장치를 확인하는 게 좋습니다. 재부팅 후 장치명이 바뀌는 경우가 있거든요. 여기서 재할당 섹터, 미디어 오류, 인터페이스 오류, 온도 이상 같은 징후를 같이 봅니다.

ZFS 풀 상태 확인과 디스크 오류 진단 흐름을 보여주는 예시 이미지입니다.

3-3. Proxmox 쪽 로그도 같이 봐야 합니다

journalctl -b | grep -i zfs
journalctl -b | grep -Ei 'ata|scsi|nvme|i/o error'
dmesg | grep -Ei 'zfs|ata|nvme|reset|error'
pvesm status

여기서 ATA reset, I/O error, device timeout 같은 메시지가 보이면 ZFS 자체보다 하드웨어 경로 문제일 확률도 높습니다. 특히 HBA 패스스루(pass-through, 장치를 직접 넘기는 방식) 환경에서는 케이블, 백플레인(backplane), 전원 안정성까지 봐야 하더라고요.

4. 흔한 ZFS 에러와 해결책

4-1. 풀 상태가 DEGRADED로 바뀐 경우

이건 가장 많이 보는 유형 중 하나입니다. 미러 구성에서는 한 디스크가 빠져도 서비스는 계속 돌아가지만, 그 상태로 오래 두면 다음 장애 때 복구 여지가 줄어듭니다.

• 케이블 재장착 후 다시 인식되는지 확인
• SMART 상태가 나쁘면 디스크 교체
• 교체 후 zpool replace로 resilver 진행

zpool replace tank old-disk-id new-disk-id
zpool status -v

처음엔 단순히 새 디스크만 꽂으면 끝나는 줄 알았는데, 실제로는 기존 디스크 식별자를 정확히 잡는 게 중요했습니다. 잘못 잡으면 엉뚱한 장치 건드릴 수 있으니 꼭 by-id 기준으로 확인하세요.

4-2. checksum error가 누적되는 경우

ZFS 에러 중에서 운영자를 가장 찝찝하게 만드는 게 체크섬 오류입니다. 데이터가 읽히긴 읽히는데 무결성 문제가 감지되는 거라서, 디스크 자체뿐 아니라 케이블이나 컨트롤러도 의심해봐야 합니다.

• 특정 디스크에만 집중되는지 확인
• scrub 실행 후 오류 증가 여부 확인
• 다른 포트나 케이블로 바꿔서 재검증

zpool scrub tank
zpool status -v

제 경험상 checksum error가 꾸준히 늘어나는데 SMART는 멀쩡한 경우, 케이블이나 포트 문제였던 적이 꽤 있었습니다. 디스크만 의심하면 오히려 늦어집니다.

4-3. 성능 저하가 갑자기 심해진 경우

성능 저하는 원인이 하나가 아닙니다. ZFS는 캐시, 압축, 동기식 쓰기, 스냅샷, 풀 사용률이 서로 영향을 줍니다.

• 풀 사용률이 지나치게 높은지 확인
• 백업 작업이나 scrub가 겹치는 시간인지 확인
• 스냅샷이 과도하게 쌓였는지 확인
• 랜덤 I/O가 많은 VM과 대용량 백업이 같은 풀인지 확인

zfs list -t snapshot | wc -l
zpool iostat -v 2

zpool iostat -v 2는 체감이 안 좋을 때 꼭 한 번 보게 됩니다. 어느 vdev에서 병목이 걸리는지 흐름이 보이거든요. 드디어 원인 잡았을 때 그 시원함, 아시는 분은 아실 겁니다.

4-4. 스냅샷 때문에 공간이 안 돌아오는 것처럼 보일 때

삭제했는데도 공간이 안 늘어나는 경우가 있죠. 이건 대개 스냅샷이 이전 블록을 붙잡고 있어서 그렇습니다. VM 디스크를 자주 지우고 만들었다면 더 눈에 띕니다.

zfs list -t snapshot -o name,used,creation -s creation
zfs destroy tank/vmdata@old-snapshot

다만 스냅샷은 복구 안전망이기도 하니까 무작정 지우면 안 됩니다. 저는 운영 환경에서는 보존 주기를 먼저 정하고 자동화하는 쪽을 권합니다.

5. 데이터 복구 접근은 이렇게 하시는 게 안전합니다

데이터 복구는 속도보다 순서가 중요합니다. 이건 정말 강조하고 싶습니다. 풀 상태가 불안정한데 이것저것 쓰기 작업부터 해버리면 상황이 더 꼬일 수 있거든요.

1. 먼저 현재 상태를 기록합니다. zpool status -v, zpool history, SMART 출력 저장.
2. 자동 작업을 잠시 멈춥니다. 대량 백업, 복제(replication), 불필요한 VM 작업 중지.
3. 읽기 우선으로 접근합니다. 필요한 데이터부터 다른 저장소로 백업합니다.
4. 하드웨어 문제와 논리 문제를 구분합니다.
5. 교체 후 resilver, 또는 백업 복원 순서로 갑니다.

zpool history tank
zfs snapshot tank/vmdata@pre-recovery
zfs send tank/vmdata@pre-recovery | mbuffer | zfs receive backup-pool/vmdata

물론 위 전송 예시는 대상 풀과 네트워크 환경이 준비되어 있어야 합니다. 핵심은 “문제 풀이 아니라 데이터 보존이 먼저”라는 점입니다. 저도 예전에 에러 잡는다고 로그만 보다가, 정작 중요한 VM 백업을 늦게 떠서 식은땀 흘린 적이 있습니다.

장애 발생 후 점검, 백업, 교체, 복구 순서를 정리한 흐름도 이미지입니다.

6. 운영하면서 미리 해두면 좋은 Proxmox ZFS 안정화 팁

6-1. 역할이 다른 워크로드를 분리하세요

가능하면 VM 운영 풀과 백업 저장소 성격을 분리하는 게 좋습니다. 같은 SSD 풀에 모든 걸 몰면 평소엔 괜찮아 보여도, 백업 시간이나 대량 복제 시간에 병목이 확 옵니다.

6-2. scrub 주기와 결과 확인 습관

scrub를 주기적으로 돌리고 결과를 눈으로 확인하세요. 자동으로 돌았다고 끝이 아닙니다. “repaired 0B with 0 errors” 같은 결과가 쌓이는 게 안심 포인트거든요.

6-3. 스냅샷 정책은 짧고 명확하게

스냅샷은 많다고 무조건 좋은 게 아닙니다. 운영 편의성과 공간 회수 사이 균형이 필요합니다. 저는 보통 아래처럼 생각합니다.

6-4. 모니터링 포인트를 정해두세요

• 풀 상태 변화: ONLINE, DEGRADED, FAULTED
• 읽기/쓰기/체크섬 오류 카운트
• 사용률과 여유 공간
• 디스크 온도와 SMART 경고
• 백업 시간대 I/O 급증 여부

여기서 중요한 포인트! 문제가 터진 뒤 로그를 모으는 것보다, 평소 정상 상태를 알고 있는 게 훨씬 강합니다.

7. 검증: 문제 해결 후 무엇을 확인해야 할까요?

조치가 끝났다고 바로 안심하긴 이릅니다. 저도 처음엔 디스크 교체 후 ONLINE만 보고 끝냈었는데, 실제로 써보니까 이후 검증이 더 중요했습니다.

1. zpool status -v에서 모든 장치가 ONLINE인지 확인
2. 최근 scrub 결과에 추가 오류가 없는지 확인
3. VM 디스크 읽기/쓰기 테스트와 실제 부팅 확인
4. 백업 작업을 한 번 수동 실행해 병목이 줄었는지 확인
5. 이벤트 로그에 추가 I/O error가 없는지 재확인

zpool status -v
zpool iostat -v 2
qm list
pvesm status

체감상 가장 좋은 검증은 “평소 하던 작업을 다시 돌려보는 것”입니다. VM 마이그레이션, 백업, 스냅샷 생성, 복원 테스트까지 한 번 해보면 진짜 안정화됐는지 감이 옵니다.

복구 이후 ZFS 풀이 정상 ONLINE 상태로 돌아오고 성능 지표가 안정된 모습을 보여주는 이미지입니다.

8. 자주 묻는 질문 정리

Q1. scrub 중인데 서버가 느려졌습니다. 중단해야 할까요?

상황에 따라 다릅니다. 서비스 영향이 크면 시간대를 조정하는 게 낫습니다. 다만 손상 의심 상황이라면 너무 오래 미루는 것도 좋지 않습니다.

Q2. ZFS 에러가 0이어도 체감이 느릴 수 있나요?

그렇습니다. 에러 카운트가 없어도 풀 사용률, 스냅샷 누적, 백업 동시 수행, 느린 디스크 혼합 구성 때문에 성능 저하는 충분히 생깁니다.

Q3. 데이터 복구 전에 scrub부터 돌려도 되나요?

무조건 그렇진 않습니다. 불안정한 하드웨어 상태에서는 먼저 중요한 데이터를 다른 곳으로 옮기는 쪽이 더 안전할 수 있습니다.

Q4. Proxmox 스토리지는 ZFS 하나로 끝내도 될까요?

작은 환경에서는 충분히 좋습니다. 다만 백업 저장소 성격까지 한 풀에 몰아넣기보다는, 역할 분리를 고민해보시는 게 운영이 편합니다.

9. 마무리: 결국 안정성은 구조와 습관에서 나옵니다

Proxmox ZFS 문제는 단순히 명령어 몇 줄로 끝나는 경우도 있지만, 실제로는 구조와 습관의 문제인 경우가 많습니다. 케이블 하나, 스냅샷 정책 하나, 여유 공간 관리 하나가 나중에 큰 차이를 만들더라고요. 저도 처음엔 ZFS가 너무 예민한 거 아닌가 싶었는데, 오래 운영해보니 예민한 게 아니라 정확한 쪽에 가깝다는 생각이 들었습니다.

정리하면 이렇습니다. ZFS 에러는 메시지 자체보다 맥락을 봐야 하고, Proxmox 스토리지는 평소 설계가 반입니다. 그리고 데이터 복구는 원인 분석보다 보존이 먼저입니다. 이 세 가지만 잡아도 운영 안정성이 꽤 달라집니다.

다음 글에서는 Proxmox 백업 저장소 분리 전략과 스냅샷/복제 운영 패턴도 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 분리 구성과 함께 보시면 더 이해가 잘 되실 거예요.

운영 전 점검, 장애 대응, 복구 후 검증까지 한 장으로 정리한 요약 인포그래픽 이미지입니다.