ZFS는 1990년대 후반 Sun Microsystems가 만든 파일시스템·볼륨 매니저 통합 시스템입니다. 호스팅 서버에서는 ext4·xfs와 다른 차원의 가치를 제공합니다. 무료 스냅샷, 투명 압축, 검증 가능한 무결성, 통합 캐시 등. 이 글에서는 실전 운영 관점에서 ZFS를 정리합니다.

ZFS Pool 구조 — vdev · ARC · L2ARC · SLOG


ZFS의 핵심 특징

1) Pool 기반 구조

디스크를 “풀”로 묶고, 그 위에 데이터셋(=파일시스템) 또는 zvol(=블록 디바이스)을 자유롭게 생성. 파티션 개념이 사라짐.

2) Copy-on-Write

모든 쓰기가 새 위치에 기록 → 부분 쓰기 도중 정전이 발생해도 일관성 유지. 부팅 시 fsck 불필요.

3) 스냅샷 즉시 생성

copy-on-write 덕에 스냅샷이 즉시 생성, 추가 공간 0. 이후 변경분만 누적.

4) 체크섬으로 무결성 보장

모든 블록에 체크섬. 디스크 자체가 잘못된 데이터를 반환해도 ZFS가 감지·복구(미러·RAID-Z 환경).

5) 투명 압축

lz4/zstd 등으로 자동 압축. 읽기 시 투명하게 압축 해제.

6) 통합 캐시 (ARC·L2ARC)

자체 캐시 시스템으로 페이지 캐시보다 똑똑한 정책.


풀과 vdev 구조

ZFS는 디스크를 vdev(virtual device) 라는 단위로 묶고, 여러 vdev를 합쳐 풀을 만듭니다.

zpool tank
  ├── vdev1: mirror (sda + sdb)
  ├── vdev2: raidz2 (sdc + sdd + sde + sdf + sdg + sdh)
  ├── cache: L2ARC (nvme0)
  └── log: SLOG (nvme1)

vdev 종류:

  • stripe: 단일 디스크 (이중화 없음, 비권장)
  • mirror: 미러링 (RAID 1 유사)
  • raidz1: 패리티 1 (RAID 5 유사) — 1대 고장 허용
  • raidz2: 패리티 2 (RAID 6 유사) — 2대 고장 허용
  • raidz3: 패리티 3 — 3대 고장 허용

중요: 풀에 vdev를 추가하면 stripe됩니다. 다시 말해 vdev 단위로 이중화 — vdev 하나가 망가지면 풀 전체가 망가집니다. 호스팅 운영자에게 권장은 mirror 또는 raidz2.


호스팅 환경 권장 풀 구성

작은 VPS 호스트 (디스크 4~6개)

zpool create tank mirror sda sdb mirror sdc sdd
# 2개 mirror vdev → 4개 디스크, 절반 용량, 빠름

중대형 (디스크 8~12개)

zpool create tank raidz2 sda sdb sdc sdd sde sdf
# 8개 디스크, 2개 패리티, 6개 용량, 2대 동시 고장 허용

매우 큰 (디스크 24개)

zpool create tank \
  raidz2 sda sdb sdc sdd sde sdf \
  raidz2 sdg sdh sdi sdj sdk sdl \
  raidz2 sdm sdn sdo sdp sdq sdr \
  raidz2 sds sdt sdu sdv sdw sdx
# 4 vdev stripe, 각 raidz2 → 16TB 용량 + 8TB 패리티

데이터셋 — 파일시스템 같은 추상화

풀 안에 여러 데이터셋을 만들고, 각각 다른 속성을 설정합니다.

zfs create tank/www
zfs create tank/db
zfs create tank/backup

# 각 데이터셋 별 설정
zfs set compression=lz4 tank/www
zfs set compression=zstd tank/backup
zfs set recordsize=16K tank/db  # MySQL 페이지 크기에 맞춤
zfs set atime=off tank/www  # 액세스 시간 안 기록 → 쓰기 줄임

각 데이터셋은 마운트 포인트가 자동 생성되어 /tank/www 등에 보입니다.


스냅샷 — 호스팅의 핵심 기능

# 즉시 스냅샷 생성
zfs snapshot tank/db@2026-05-20-1200

# 목록
zfs list -t snapshot

# 스냅샷 시점으로 클론 (읽기·쓰기 가능 가상 데이터셋)
zfs clone tank/db@2026-05-20-1200 tank/db-test

# 원본 시점으로 롤백
zfs rollback tank/db@2026-05-20-1200

호스팅에서 활용:

  • 매 시간 자동 스냅샷: 사용자가 실수 삭제해도 즉시 복구
  • 배포 전 스냅샷: 문제 발생 시 1초 만에 롤백
  • 백업 송신: zfs send | zfs receive로 원격 복제

자동 스냅샷 도구

zfs-auto-snapshot 또는 sanoid로 정책 기반 자동 스냅샷:

# sanoid.conf
[tank/www]
  use_template = production
  recursive = yes

[template_production]
  frequently = 8
  hourly = 24
  daily = 30
  monthly = 6
  yearly = 0

압축 — 거의 무료의 디스크 절약

LZ4 압축은 거의 무료입니다 — CPU 부담은 미미한데 디스크 절약은 평균 1.5~3배.

zfs set compression=lz4 tank/www
zfs set compression=zstd-3 tank/backup

# 압축률 확인
zfs get compressratio tank/www
# tank/www  compressratio  2.13x

옵션:

  • lz4: 빠름, 일반 데이터에 권장 (기본 선택)
  • zstd-3 ~ zstd-19: 더 좋은 압축률, CPU 더 씀
  • gzip-1 ~ gzip-9: 옛 방식, zstd로 대체

이미지·동영상 같은 이미 압축된 콘텐츠는 효과 없지만, 텍스트·로그·DB는 큰 효과.


ARC와 L2ARC — 캐시 계층

ARC (Adaptive Replacement Cache)

RAM 기반 1차 캐시. ZFS가 메모리를 알아서 활용. 호스팅 서버라면 여유 RAM의 50~80%를 ARC가 사용해도 정상.

# 현재 ARC 사용량
arc_summary
# 또는
cat /proc/spl/kstat/zfs/arcstats | grep -E "size|hits|misses"

# ARC 최대 크기 제한 (메모리 다른 용도가 있을 때)
echo $((16 * 1024 * 1024 * 1024)) > /sys/module/zfs/parameters/zfs_arc_max

L2ARC

SSD 기반 2차 캐시. RAM에서 밀려난 데이터를 SSD에 보관.

zpool add tank cache /dev/nvme0n1

큰 데이터셋 + 부족한 RAM 환경에서 유용. 모든 환경에서 효과 있는 건 아닙니다.

SLOG (ZFS Intent Log)

동기 쓰기 가속용. DB·NFS처럼 동기 쓰기가 많은 워크로드에 필수. PLP(전력 손실 보호) NVMe 사용.

zpool add tank log mirror /dev/nvme1n1 /dev/nvme2n1

무결성 검사 (Scrub)

ZFS는 모든 블록 체크섬을 갖고 있어, 주기적으로 검사하면 silent corruption을 발견할 수 있습니다.

# 매주 일요일 새벽 자동 스크럽 (Ubuntu/Debian 기본)
systemctl status zfs-scrub-weekly@tank.timer

# 수동 실행
zpool scrub tank

# 진행 확인
zpool status tank

ECC RAM과 결합하면 데이터 무결성이 매우 강해집니다.


ZFS Send/Receive로 복제

다른 서버로 데이터셋 전체를 효율적으로 보냅니다.

# 첫 전체 전송
zfs snapshot tank/www@initial
zfs send tank/www@initial | ssh backup-host zfs recv backup/www

# 이후 증분
zfs snapshot tank/www@daily-1
zfs send -i tank/www@initial tank/www@daily-1 | \
  ssh backup-host zfs recv backup/www

스냅샷 간 변경분만 보내므로 매우 효율적. 3-2-1 백업의 오프사이트 부분에 활용.


운영 함정

1) Free Space 80% 이상 절대 금지

80% 이상이 되면 ZFS가 급격히 느려집니다. 항상 20% 이상 여유.

2) ECC RAM 강력 권장

체크섬이 강력하지만, RAM 자체가 손상되면 ZFS도 잘못된 데이터를 영구화. 호스팅 서버는 ECC RAM 필수.

3) 풀 확장의 제약

RAID-Z 풀에 디스크 1개를 추가하는 건 최근까지 불가능했습니다(OpenZFS 2.3에서 RAID-Z expansion 도입). 처음 설계 시 미래 확장 고려.

4) 중복 제거(dedup)는 신중히

dedup은 메모리 폭식. 1TB당 1~5GB RAM 필요. 일반 호스팅엔 부적합, VM 디스크 같은 특수 경우만.

5) 메모리 부족 환경에서는 ARC 제한

4GB RAM 미만에서는 ZFS가 비효율적. 8GB 이상 권장.


호스팅에서 ZFS를 선택해야 할 때

✅ 적합

  • VPS 호스트 (수십~수백 VM 디스크 관리)
  • DB 서버 (스냅샷·압축·무결성)
  • 백업 서버
  • 파일 호스팅 (대용량 + 압축)
  • 워크스테이션·개발 서버

❌ 비추

  • 메모리 매우 제한적 (1~2GB)
  • 단일 디스크 미러 없는 환경 (오히려 위험)
  • 매우 단순한 워크로드 (ext4로 충분)

ZFS on Linux 설치 (Ubuntu)

# Ubuntu 22.04
apt install -y zfsutils-linux

# 풀 생성 예시
zpool create -o ashift=12 tank mirror /dev/sda /dev/sdb

# 활성 모듈 확인
zpool version

ashift=12는 4KB 섹터 디스크 최적화. 거의 모든 최신 디스크에 권장.


마무리

ZFS는 학습 곡선이 있지만, 한 번 익히면 호스팅 운영의 디스크 관련 고민 절반이 사라집니다. 스냅샷·압축·무결성·통합 캐시가 한 시스템에 통합돼 있어 ext4 + LVM + RAID + 별도 백업 도구를 합친 것보다 훨씬 깔끔합니다.

TCP-80.NET의 전용서버 중·고급 플랜은 ECC RAM + 다중 디스크 + NVMe SLOG 구성에 적합해 ZFS 운영의 이상적인 환경을 제공합니다. 자세한 구성 가이드는 @tcp80net으로 문의해 주세요.