13년차의 서버실

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

[태그:] 파일 시스템

  • [NAS 파일 시스템] Btrfs, 데이터 무결성을 위한 현명한 선택일까?

    [NAS 파일 시스템] Btrfs, 데이터 무결성을 위한 현명한 선택일까?

    [NAS 파일 시스템] Btrfs, 데이터 무결성을 위한 현명한 선택일까?

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 NAS를 운영하시는 분들이라면 한 번쯤 고민해봐야 할 주제, 바로 Btrfs 파일 시스템에 대해 얘기해보려고 합니다. 저도 처음엔 ZFS(Zettabyte File System)만 최고인 줄 알았거든요. 근데 홈랩에서 다양한 파일 시스템을 직접 써보고 삽질도 좀 해보면서, Btrfs가 NAS 환경에서 얼마나 매력적인 선택지가 될 수 있는지 깨달았습니다. 특히 데이터 무결성(Data Integrity)을 중요하게 생각하신다면, 오늘 제 경험담이 도움이 될 거예요.

    소중한 데이터, 한순간의 실수나 하드웨어 오류로 날아가면 정말 끔찍하잖아요? 저도 예전에 백업 없이 중요한 자료를 날려본 경험이 있어서, 그때부터는 파일 시스템 선택에 정말 신중해졌습니다. Btrfs는 이런 걱정을 덜어줄 수 있는 강력한 기능들을 제공하더라고요. 과연 Btrfs가 여러분의 NAS 데이터를 안전하게 지켜줄 수 있을지, 함께 파헤쳐 봅시다!

    Btrfs 파일 시스템의 Copy-on-Write(CoW) 및 스냅샷 작동 방식 개념도

    Btrfs 파일 시스템의 Copy-on-Write(CoW) 및 스냅샷 작동 방식 개념도

    Btrfs, 너는 누구냐? 핵심 기능 파헤치기

    Btrfs는 ‘B-tree file system’의 약자로, 오라클에서 개발을 시작한 차세대 파일 시스템입니다. 리눅스 환경에서 널리 사용되고 있죠. 사실 처음엔 이게 뭔가 싶었는데, 몇 가지 핵심 기능들을 알고 나니 “이거 진짜 물건이더라고요!” 하는 생각이 들었습니다. 특히 NAS에 적용했을 때 빛을 발하는 기능들이 많더라고요.

    1. Copy-on-Write (CoW, 카피 온 라이트)

    이름 그대로 ‘쓸 때 복사한다’는 의미입니다. 기존 데이터를 변경할 때, 해당 데이터를 덮어쓰지 않고 새로운 위치에 변경된 데이터를 쓴 다음, 메타데이터(Metadata)만 업데이트하는 방식이죠. 이게 왜 중요하냐면요?

    • 데이터 손상 방지: 전원이 갑자기 나가거나 시스템에 문제가 생겨도, 작업 중이던 데이터는 손상될지언정 기존 데이터는 온전히 보존됩니다.
    • 스냅샷의 기반: 이 CoW 덕분에 스냅샷(Snapshot) 기능이 아주 효율적으로 작동합니다.

    사실 CoW 방식은 ZFS에서도 볼 수 있는 강력한 기능인데, Btrfs도 이걸 아주 잘 활용하고 있더라고요.

    2. 스냅샷 (Snapshot)

    스냅샷은 특정 시점의 파일 시스템 상태를 저장하는 기능입니다. 마치 게임에서 세이브 포인트를 만드는 것과 같아요. Btrfs의 스냅샷은 CoW 덕분에 용량을 거의 차지하지 않는다는 게 정말 큰 장점입니다. 변경된 블록만 저장하면 되니까요.

    • 실수로 파일 삭제/수정: 걱정 마세요! 스냅샷으로 쉽게 특정 시점으로 되돌릴 수 있어요.
    • 랜섬웨어 공격: 이것 때문에 저도 Btrfs를 더 신뢰하게 됐는데요, 만약 랜섬웨어에 감염되더라도 감염되기 전 스냅샷으로 복원하면 피해를 최소화할 수 있습니다. 정말 든든하죠!

    3. 데이터 무결성 (Data Integrity)을 위한 체크섬 (Checksum)

    Btrfs는 데이터 블록과 메타데이터 블록에 각각 체크섬을 적용합니다. 데이터를 읽을 때마다 체크섬을 확인해서, 혹시라도 데이터가 손상(Bit Rot, 비트 로트)되었는지 검사하죠. 만약 손상된 부분을 발견하면, RAID 1이나 RAID 10처럼 미러링된 구성에서는 자동으로 손상되지 않은 사본으로 복구해버립니다. 이게 바로 자가 복구(Self-Healing) 능력입니다.

    제가 실제로 써보니까, 이런 기능들이 작은 홈랩 NAS부터 기업용 스토리지까지 데이터의 신뢰성을 크게 높여주더라고요. 처음엔 “굳이 이렇게까지 해야 하나?” 싶었는데, 한 번 데이터를 잃고 나면 생각이 확 달라집니다.

    NAS에서 Btrfs 실전 활용: 어떻게 적용할까?

    많은 NAS 제조사들이 Btrfs를 채택하고 있습니다. 특히 Synology(시놀로지) 같은 경우 Btrfs를 적극적으로 활용해서 스냅샷, 데이터 무결성 기능을 사용자에게 제공하고 있죠. 하지만 직접 리눅스 서버에 NAS를 구축한다면, Btrfs를 직접 설정해야 합니다.

    1. Btrfs 파일 시스템 생성

    먼저 Btrfs로 포맷할 디스크를 준비해야 합니다. 저는 주로 여러 디스크를 묶어서 사용하는데요, Btrfs는 자체적으로 소프트웨어 RAID 기능을 제공합니다. (물론 안정성 측면에서는 하드웨어 RAID나 mdadm 위에 Btrfs를 쓰는 것도 고려할 수 있습니다.)

    # /dev/sdb, /dev/sdc 두 개의 디스크로 RAID1 Btrfs 파일 시스템 생성
    sudo mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc
    
    # 기존 디스크를 Btrfs 풀에 추가할 경우
    sudo btrfs device add /dev/sdd /mnt/btrfs_pool
    sudo btrfs balance start -dusage=50 /mnt/btrfs_pool # 데이터 분배

    이렇게 생성된 Btrfs 볼륨을 원하는 마운트 포인트에 마운트하면 됩니다.

    2. 서브볼륨 (Subvolume) 생성 및 관리

    Btrfs의 서브볼륨은 일반적인 디렉토리와 비슷하지만, 독립적인 스냅샷을 찍거나 할당량(Quota)을 설정할 수 있는 등 더 강력한 기능을 제공합니다. 저는 보통 용도별로 서브볼륨을 나눠서 사용해요. 예를 들어, ‘Documents’, ‘Media’, ‘Backup‘ 이런 식으로요.

    sudo mount /dev/sdb /mnt/btrfs_pool
    
    # 'data'라는 서브볼륨 생성
    sudo btrfs subvolume create /mnt/btrfs_pool/data
    
    # 'data' 서브볼륨을 /srv/nas에 마운트 (fstab에도 등록하여 부팅 시 자동 마운트)
    sudo mount -o subvol=data /dev/sdb /srv/nas

    3. 스냅샷 생성 및 관리

    이제 서브볼륨에 데이터를 저장하고, 주기적으로 스냅샷을 찍어줍니다. 스냅샷은 읽기 전용(Read-Only)으로 생성하는 것이 일반적입니다.

    # 'data' 서브볼륨의 스냅샷 생성
    sudo btrfs subvolume snapshot -r /srv/nas /srv/nas/.snapshots/data_$(date +%Y%m%d_%H%M%S)
    
    # 생성된 스냅샷 목록 확인
    sudo btrfs subvolume list -t -o /mnt/btrfs_pool

    스냅샷을 자동으로 찍어주는 스크립트나 서비스(예: <code>btrfs-autosnap, snapper)를 활용하면 훨씬 편리하게 관리할 수 있어요. 저도 처음엔 수동으로 찍다가, 나중엔 스크립트 걸어놓고 마음 편하게 쓰고 있습니다.

    Btrfs 파일 시스템을 활용한 NAS 구성 개념도

    Btrfs 파일 시스템을 활용한 NAS 구성 개념도

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

    Btrfs가 만능은 아닙니다. 제가 직접 써보면서 몇 가지 주의할 점과 삽질 경험을 공유해 드릴게요.

    1. 성능 오버헤드 (Performance Overhead)

    Copy-on-Write 방식은 데이터 무결성을 높여주지만, 쓰기(Write) 작업 시 약간의 성능 저하가 발생할 수 있습니다. 특히 랜덤 쓰기(Random Write)가 많은 환경에서는 체감될 수 있어요. 처음엔 “왜 이렇게 느리지?” 싶었는데, 알고 보니 CoW 때문이더라고요. 그래서 고성능이 최우선인 환경보다는 데이터 안정성이 중요한 환경에 더 적합하다고 생각합니다.

    2. 디스크 공간 관리 (Disk Space Management)

    스냅샷은 공간을 효율적으로 사용하지만, 너무 많은 스냅샷을 오랫동안 보관하면 결국 디스크 공간을 많이 차지하게 됩니다. 특히 삭제된 파일이 스냅샷에 남아있다면 실제 공간은 회수되지 않거든요. 주기적으로 오래된 스냅샷을 삭제해주는 정책이 필요해요.

    # 오래된 스냅샷 삭제 예시 (가장 최신 스냅샷 10개만 남기고 삭제)
    # 실제 사용 시에는 신중하게 접근해야 합니다.
    LATEST_SNAPSHOTS=$(sudo btrfs subvolume list -t -o /mnt/btrfs_pool | grep 'snapshots' | sort -r | head -n 10 | awk '{print $9}')
    ALL_SNAPSHOTS=$(sudo btrfs subvolume list -t -o /mnt/btrfs_pool | grep 'snapshots' | awk '{print $9}')
    
    for SNAPSHOT in $ALL_SNAPSHOTS; do
        IS_LATEST=false
        for LATEST in $LATEST_SNAPSHOTS; do
            if [ "$SNAPSHOT" == "$LATEST" ]; then
                IS_LATEST=true
                break
            fi
        done
        if ! $IS_LATEST; then
            echo "Deleting old snapshot: $SNAPSHOT"
            sudo btrfs subvolume delete "$SNAPSHOT"
        fi
    done

    ⚠️ 경고: 스냅샷 삭제는 신중하게! 복구 불가능합니다.

    3. RAID 기능의 성숙도

    Btrfs는 자체 RAID0, RAID1, RAID5, RAID6 기능을 제공해요. 하지만 RAID5/6의 경우 초기에는 안정성 문제가 보고되기도 했습니다. 지금은 많이 개선되었지만, 아직까지는 mdadm RAID1 위에 Btrfs를 사용하거나, RAID10을 선호하는 경우가 많습니다. 저도 안정성을 위해 RAID10을 주로 사용하거나, 디스크 두 개만 쓰는 NAS에는 Btrfs RAID1을 쓰는 편입니다.

    ✅ 검증 및 결과: 내 데이터는 안전한가?

    Btrfs를 설정하고 나면, 데이터가 정말 안전하게 관리되고 있는지 확인해야겠죠? 저는 주기적으로 btrfs scrub 명령어를 실행해서 파일 시스템의 데이터 무결성을 검사합니다. 이 명령은 모든 데이터와 메타데이터 블록의 체크섬을 확인하고, 손상된 부분이 있으면 자동으로 복구해줍니다.

    # Btrfs 파일 시스템 스크럽 시작
    sudo btrfs scrub start /mnt/btrfs_pool
    
    # 스크럽 진행 상황 확인
    sudo btrfs scrub status /mnt/btrfs_pool

    스크럽이 완료되면 “드디어 됐다!” 하는 안도감이 들어요. 이 기능을 통해서 디스크 자체의 물리적인 오류나 비트 로트 현상으로부터 데이터를 보호할 수 있습니다. NAS를 며칠씩 켜놓는 저에게는 정말 필수적인 기능이라고 생각해요.

    Btrfs scrub 및 스냅샷 목록 확인 터미널 출력 화면

    Btrfs scrub 및 스냅샷 목록 확인 터미널 출력 화면

    마무리: Btrfs, NAS 데이터 무결성을 위한 현명한 선택일까?

    결론부터 말씀드리자면, Btrfs는 NAS 환경에서 데이터 무결성과 관리 유연성을 크게 향상시켜 줄 수 있는 현명한 선택지가 될 수 있습니다. 특히 스냅샷 기능은 랜섬웨어 방어나 실수로 인한 데이터 손실 복구에 엄청난 강점을 보여주거든요. CoW 기반의 효율적인 공간 활용도 정말 매력적입니다.

    하지만 성능 오버헤드나 RAID 기능의 성숙도 등 고려해야 할 부분도 분명히 있습니다. 완벽한 파일 시스템은 없으니까요. 여러분의 NAS 사용 목적과 중요도에 따라 Btrfs가 최적의 선택이 될 수도, 아닐 수도 있겠죠. 저처럼 홈랩에서 다양한 시도를 해보면서 자신에게 맞는 최적의 조합을 찾아가는 과정 자체가 인프라 엔지니어의 숙명 아닐까요? ㅎㅎ

    다음 글에서는 Btrfs와 ZFS를 좀 더 심층적으로 비교해보는 시간을 가져볼까 합니다. 혹시 Btrfs를 사용하면서 겪었던 재미있는 삽질 경험이 있으시다면 댓글로 공유해주세요! 저도 배우는 재미가 쏠쏠하거든요. 긴 글 읽어주셔서 감사합니다!

    Btrfs 파일 시스템의 NAS 적용 장단점 인포그래픽 요약

    Btrfs 파일 시스템의 NAS 적용 장단점 인포그래픽 요약

  • [Proxmox] ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석

    [Proxmox] ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 주인장입니다.

    홈랩을 운영하다 보면 늘 새로운 기술에 대한 갈증과 함께 ‘어떻게 하면 더 효율적이고 안정적으로 운영할 수 있을까?’ 하는 고민에 빠지게 됩니다. 특히 스토리지 선택은 홈랩의 심장이나 다름없죠. Proxmox VE(Virtual Environment)를 사용하시는 분들이라면 한 번쯤은 ZFS와 Btrfs 사이에서 깊은 고민에 빠져보셨을 겁니다. 저도 처음엔 뭐가 뭔지 복잡하고, 어떤 게 제 홈랩 환경에 최적일지 갈피를 잡기 어려웠거든요. 스펙 시트만 봐서는 답이 안 나오더라고요.

    그래서 오늘은 제가 직접 Proxmox 홈랩에서 ZFS와 Btrfs 스토리지를 구성하고 사용해보면서 겪었던 경험과 함께, 실측 성능 (물론 ‘실측’이라는 게 제 개인적인 체감과 간단한 테스트 기준입니다만) 그리고 데이터 무결성 측면에서 두 파일 시스템을 꼼꼼하게 비교 분석해 보려고 합니다. 이 글이 여러분의 홈랩 스토리지 성능 고민과 ZFS, Btrfs 선택에 작은 이정표가 되었으면 좋겠네요. 삽질 끝에 얻은 저의 인사이트를 솔직하게 공유해 드릴게요! 🎉

    ZFS와 Btrfs는 Copy-on-Write(CoW) 개념을 기반으로 하는 최신 파일 시스템입니다. 이미지에서는 두 파일 시스템의 주요 특징과 구조를 시각적으로 비교하여 보여줍니다.

    ZFS와 Btrfs, 대체 뭐가 다른가요? (핵심 개념 파헤치기)

    본격적인 비교에 앞서, 두 파일 시스템의 핵심 개념을 먼저 짚고 넘어가야겠죠? 쉽게 말해 ZFS와 Btrfs 모두 ‘차세대 파일 시스템’으로 불리며, 기존 ext4 같은 파일 시스템보다 훨씬 강력한 기능들을 제공합니다.

    • Copy-on-Write (CoW, 카피 온 라이트): 이게 두 파일 시스템의 가장 중요한 공통점입니다. 데이터를 덮어쓰지 않고, 변경 사항이 생기면 새로운 블록에 쓰고 메타데이터만 업데이트하는 방식이죠. 덕분에 스냅샷(Snapshot) 생성이나 데이터 손상 복구에 아주 유리합니다.
    • 데이터 무결성 (Data Integrity): CoW 덕분에 데이터가 손상될 위험이 훨씬 적습니다. 체크섬(Checksum)을 사용해서 데이터가 올바른지 지속적으로 검증하거든요.

    ZFS(Zettabyte File System): 엔터프라이즈급 안정성의 대명사

    ZFS는 Oracle Solaris에서 시작되어 현재는 OpenZFS 프로젝트로 활발히 개발되고 있는 파일 시스템입니다. ‘강력한 데이터 무결성’이라는 키워드가 가장 잘 어울립니다. 제가 써보니 이 친구는 정말 든든하더라고요. 주요 특징은 다음과 같습니다.

    • 트랜잭션 기반 (Transactional): 모든 쓰기 작업이 트랜잭션으로 처리되어 데이터 손실 위험이 거의 없습니다.
    • 풀 관리 (Pool Management): 여러 디스크를 묶어 스토리지 풀(Storage Pool)을 구성하고, 그 위에 파일 시스템을 생성합니다. RAID-Z (RAID-Z1, RAID-Z2, RAID-Z3)와 같은 소프트웨어 RAID 기능이 내장되어 있어 별도의 하드웨어 RAID 컨트롤러 없이도 강력한 데이터 보호 기능을 제공합니다.
    • 자가 복구 (Self-Healing): 데이터 손상이 감지되면 체크섬을 통해 자동으로 복구하려고 시도합니다. 이게 진짜 매력적이죠.
    • 스냅샷 (Snapshot) 및 클론 (Clone): 거의 즉각적으로 스냅샷을 생성하고 관리할 수 있습니다. 백업이나 테스트 환경 구성에 아주 유용하죠.
    • 압축 (Compression) 및 중복 제거 (Deduplication): 데이터를 압축하여 공간을 절약하고, 중복되는 데이터를 제거하여 효율성을 높일 수 있습니다. 다만, 중복 제거는 RAM을 많이 사용해서 홈랩에서는 신중하게 접근해야 합니다.

    Btrfs (B-tree File System): 리눅스 친화적인 유연성

    Btrfs는 Linux 커널에 통합되어 개발된 파일 시스템으로, ZFS와 유사한 CoW 기반의 고급 기능을 제공하면서도 좀 더 리눅스 친화적인 면모를 보입니다. 제가 처음 Btrfs를 접했을 땐 ‘오, ZFS만큼 강력한데 더 가볍고 유연하네?’ 싶었거든요.

    • 서브볼륨 (Subvolume): 파티션처럼 작동하지만 훨씬 유연하게 생성하고 관리할 수 있습니다. 스냅샷의 기반이 되기도 하고요.
    • 파일 시스템 수준 RAID (File System Level RAID): ZFS의 RAID-Z처럼 디스크 여러 개를 묶어 RAID0, RAID1, RAID10 등을 구성할 수 있습니다. 다만, RAID5/6은 아직 안정성 문제로 권장되지 않는 경우가 많습니다. 제가 한 번 써봤는데, 썩 만족스럽지 못했죠. ⚠️
    • 스냅샷 (Snapshot): ZFS와 마찬가지로 빠르고 효율적인 스냅샷 기능을 제공합니다. 서브볼륨 기반이라 관리도 편리하고요.
    • 데이터 및 메타데이터 체크섬 (Data and Metadata Checksum): ZFS와 유사하게 데이터 무결성을 검증합니다.
    • 온라인 리사이징 (Online Resizing): 파일 시스템 크기를 온라인 상태에서 유연하게 조절할 수 있습니다.

    두 파일 시스템의 주요 특징을 표로 비교해볼까요?

    특징 ZFS Btrfs
    개발 주체 Oracle Solaris (현재 OpenZFS) Linux 커널
    기반 기술 Copy-on-Write (CoW) Copy-on-Write (CoW)
    데이터 무결성 매우 강력 (체크섬, 자가 복구, 트랜잭션) 강력 (체크섬)
    RAID 기능 내장 (RAID-Z1/2/3) 내장 (RAID0/1/10, 5/6은 주의 필요)
    스냅샷 매우 효율적, 클론 가능 매우 효율적, 서브볼륨 기반
    중복 제거 지원 (RAM 소모 큼) 지원 (RAM 소모 큼)
    압축 지원 지원
    메모리 요구량 높음 (ARC 캐시) 상대적으로 낮음
    주요 사용처 NAS, 서버, 엔터프라이즈 스토리지 데스크톱, 홈랩, 경량 서버

    Proxmox에서 ZFS, Btrfs 스토리지 구성하기 (실전 구현)

    이제 Proxmox 환경에서 실제로 두 스토리지를 어떻게 구성할 수 있는지 알아볼 시간입니다. 제가 직접 해보니 Proxmox 설치 시 ZFS 루트 파일 시스템을 선택하는 게 가장 편하더라고요. 설치 단계에서 바로 ZFS 풀을 구성할 수 있거든요. 하지만 이미 설치된 Proxmox에 추가하거나 Btrfs를 사용하려면 몇 가지 수동 설정이 필요합니다.

    ZFS 스토리지 구성 예시 (Proxmox 설치 후 추가)

    Proxmox에 새로운 디스크로 ZFS 풀을 추가하는 과정입니다.

    1. 디스크 확인: 먼저 사용할 디스크의 경로를 확인합니다.
    2. lsblk

      예를 들어 /dev/sdb, /dev/sdc를 사용할 경우입니다.

    3. ZFS 풀 생성: RAID-Z1 (패리티 디스크 1개)으로 풀을 생성합니다.
    4. zpool create -f myzfsraidz1 raidz1 /dev/sdb /dev/sdc /dev/sdd

      여기서 myzfsraidz1은 제가 임의로 정한 풀 이름입니다. 실제 환경에서는 디스크 개수와 보호 수준에 맞춰 RAID-Z2 등을 선택할 수 있습니다.

    5. Proxmox에 ZFS 스토리지 추가: Proxmox Web UI에 접속하여 데이터센터 > 스토리지 > 추가 > ZFS를 선택하고, 생성한 myzfsraidz1 풀을 연결해 줍니다. 콘텐츠 타입(Content type)은 VM 디스크 이미지, 컨테이너, 백업 등 필요한 것을 선택하면 됩니다.

    Btrfs 스토리지 구성 예시 (Proxmox 설치 후 추가)

    Btrfs는 Proxmox의 기본 스토리지 타입으로 직접 지원하지 않아, 일반 디렉토리 스토리지로 활용해야 합니다. 이 부분이 Btrfs를 홈랩에서 쓰려는 분들께는 첫 번째 삽질 포인트가 되더라고요. ⚠️

    1. 디스크 확인 및 Btrfs 파일 시스템 생성:
    2. lsblk
      mkfs.btrfs -f /dev/sde

      /dev/sde는 예시 디스크입니다. 여러 디스크를 Btrfs RAID로 묶으려면 mkfs.btrfs -d raid1 -m raid1 /dev/sde /dev/sdf 와 같이 명령어를 사용합니다.

    3. 마운트 포인트 생성 및 마운트:
    4. mkdir /mnt/mybtrfs
      mount /dev/sde /mnt/mybtrfs
    5. fstab에 등록 (재부팅 시 자동 마운트): UUID를 사용해 등록하는 것이 좋습니다.
    6. echo "UUID=$(blkid -s UUID -o value /dev/sde) /mnt/mybtrfs btrfs defaults 0 0" >> /etc/fstab
    7. Proxmox에 디렉토리 스토리지 추가: Proxmox Web UI에서 데이터센터 > 스토리지 > 추가 > 디렉토리를 선택하고, 경로를 /mnt/mybtrfs로 지정합니다. 콘텐츠 타입은 ZFS와 마찬가지로 필요에 따라 선택합니다.
    Proxmox 웹 인터페이스에서 새로운 ZFS 또는 Btrfs 기반 디렉토리 스토리지를 추가하는 설정 화면입니다.

    Proxmox 웹 인터페이스에서 새로운 스토리지를 추가하는 화면입니다. ZFS 풀이나 Btrfs 서브볼륨을 Proxmox에 연결하는 과정을 보여줍니다.

    삽질 경험: 성능과 데이터 무결성 사이의 고민

    솔직히 말씀드리면, 처음엔 Btrfs의 유연성과 서브볼륨 기능에 혹했었습니다. ‘오, 이거 하나로 다 되겠네!’ 싶었거든요. 그런데 막상 홈랩 환경에서 여러 VM과 컨테이너를 돌려보니, 생각보다 여러 부분에서 차이를 느끼게 되더라고요.

    ZFS는 메모리 사용량(ARC, Adaptive Replacement Cache)이 높은 편입니다. 그래서 Proxmox 호스트의 RAM이 충분하지 않으면 성능 저하가 올 수 있다는 경고를 많이 봤었죠. 제 홈랩 서버는 RAM이 넉넉한 편이라 크게 문제는 없었습니다만, 만약 8GB 같은 최소 사양으로 Proxmox를 운영한다면 ZFS는 조금 부담스러울 수 있습니다. 반면 Btrfs는 상대적으로 메모리 요구량이 낮아 경량 환경에 더 적합할 수 있습니다. 하지만 이게 다가 아니더라고요.

    특히 랜덤 I/O 성능에서 ZFS가 강점을 보였습니다. VM 부팅이나 데이터베이스 작업처럼 작은 파일들이 불규칙하게 읽고 쓰이는 작업에서는 ZFS가 확실히 더 빠릿빠릿한 체감을 줬습니다. SSD 환경에서는 그 차이가 더 두드러지더라고요. Btrfs는 스냅샷 관리나 서브볼륨의 유연성에서는 좋았지만, 특정 I/O 패턴에서는 ZFS만큼의 안정적인 성능을 보여주지는 못했습니다. 특히 Btrfs에서 RAID5/6은 아직 프로덕션 환경에서는 조심해야 한다는 이야기가 많죠? 저도 홈랩에서 시도했다가 데이터 날릴 뻔했습니다. ⚠️ 그래서 Btrfs로 RAID를 구성할 때는 RAID1이나 RAID10을 권장하는 편입니다.

    홈랩 환경에서의 실측 성능 분석 (결과 검증)

    구체적인 벤치마크 수치를 나열하는 것은 의미가 없다고 생각합니다. 왜냐하면 제 홈랩 환경과 여러분의 환경은 디스크 종류, CPU, RAM, 워크로드 등 모든 것이 다르기 때문이죠. 하지만 제가 ‘체감’하고 ‘관찰’한 바는 명확합니다.

    • VM/컨테이너 I/O 성능:
      • ZFS: SSD 환경에서 VM의 부팅 속도나 디스크 집약적인 애플리케이션(예: 데이터베이스, CI/CD 빌드 에이전트) 실행 시, 더 안정적이고 예측 가능한 성능을 보여줬습니다. 특히 ARC 캐시가 활성화되면 읽기 성능이 매우 뛰어났습니다.
      • Btrfs: 일반적인 VM 운영에는 무리가 없었지만, 고부하 랜덤 I/O 상황에서는 ZFS 대비 미세하게 느리거나 불안정한 모습을 보일 때가 있었습니다. 하지만 스냅샷 생성 및 복구는 ZFS보다 빠르고 가벼운 느낌을 줬습니다.
    • 데이터 무결성 및 복구:
      • ZFS: 이건 정말 ‘철옹성’ 같다는 느낌을 받았습니다. 한 번은 불안정한 전원 공급으로 인해 시스템이 갑자기 꺼진 적이 있었는데, ZFS 풀은 아무 문제 없이 잘 복구되더라고요. 체크섬 기반의 자가 복구 기능 덕분인 것 같습니다. zpool scrub 명령어로 주기적으로 풀 상태를 확인하면 마음이 편안해집니다.
      • Btrfs: Btrfs 역시 체크섬을 사용하기 때문에 데이터 무결성이 우수합니다. 하지만 ZFS만큼 ‘강력하다’는 인상은 받지 못했습니다. 커뮤니티에서도 ZFS가 데이터 손상 방지 및 복구 측면에서 좀 더 검증된 안정성을 가지고 있다고 평가하는 분위기입니다.

    결론적으로, 제 홈랩 환경(주로 VM 여러 개와 컨테이너, 그리고 미디어 서버)에서는 SSD를 기반으로 한 ZFS가 전반적인 성능과 안정성, 그리고 무엇보다 ‘데이터 무결성’ 측면에서 더 높은 만족도를 줬습니다. Btrfs는 스냅샷을 자주 사용하고, 유연한 볼륨 관리가 필요하며, RAM 사용량에 민감한 특정 워크로드에서 진가를 발휘할 수 있을 것 같더라고요.

    Proxmox 가상 머신의 디스크 읽기 및 쓰기 I/O 성능를 시간대별로 보여주는 모니터링 그래프입니다.

    Proxmox 가상 머신의 디스크 I/O 성능 모니터링 그래프입니다. ZFS와 Btrfs 스토리지에서 각각 운영되는 VM의 I/O 처리량을 시각적으로 비교할 수 있습니다.

    그래서, 어떤 걸 선택해야 할까요? (결론 및 제안)

    제 경험을 바탕으로 여러분의 홈랩 스토리지 선택에 대한 가이드를 드려볼게요. 정답은 없지만, 어떤 상황에 더 적합한지는 분명히 있습니다.

    • ZFS를 추천하는 경우:
      • ✅ 데이터 무결성과 안정성을 최우선으로 생각한다면 ZFS가 최고의 선택입니다.
      • ✅ Proxmox 호스트의 RAM이 충분하다면 (최소 16GB 이상, 많을수록 좋습니다).
      • ✅ 하드웨어 RAID 컨트롤러 없이 소프트웨어 RAID (RAID-Z)로 강력한 데이터 보호를 원한다면.
      • ✅ VM 디스크 I/O 성능이 중요한 워크로드(데이터베이스, 개발 환경 등)를 운영한다면.
    • Btrfs를 고려할 수 있는 경우:
      • ✅ 유연한 스냅샷 관리와 서브볼륨 기능을 적극적으로 활용하고 싶다면.
      • ✅ Proxmox 호스트의 RAM이 상대적으로 부족한 환경에서 CoW 기반 파일 시스템을 쓰고 싶다면.
      • ✅ 특정 실험적인 워크로드나, 파일 시스템 수준의 RAID1/10을 구성하려 한다면 (단, RAID5/6은 아직 주의).
      • ✅ 스토리지를 자주 확장하거나 축소하는 등 유연한 볼륨 관리가 필요하다면.

    결론적으로, 저는 안정성과 강력한 데이터 무결성 때문에 Proxmox 루트 파일 시스템은 ZFS로, 그리고 특정 실험용 VM이나 컨테이너 스토리지로는 Btrfs를 별도로 구성하는 하이브리드 방식을 선호하게 되더라고요. 이렇게 하면 두 파일 시스템의 장점을 모두 활용할 수 있습니다. 💡

    ZFS와 Btrfs 파일 시스템의 주요 장점과 단점을 직관적으로 비교하는 인포그래픽입니다.

    ZFS와 Btrfs 파일 시스템의 주요 장점과 단점을 한눈에 비교할 수 있는 인포그래픽입니다. 홈랩 환경에서의 스토리지 성택에 도움을 줄 수 있는 핵심 정보를 담고 있습니다.

    마무리하며: 나의 홈랩, 나의 스토리지

    오늘 글을 통해 Proxmox 환경에서 ZFS와 Btrfs 비교를 해봤습니다. 저의 13년차 인프라 엔지니어의 경험과 홈랩에서의 삽질(?)을 바탕으로 이야기했지만, 결국 여러분의 환경과 목적에 맞는 최적의 선택을 하는 것이 가장 중요합니다. 어떤 파일 시스템을 선택하시든, 스냅샷과 백업은 선택이 아닌 필수라는 점, 잊지 마세요!

    이 글이 여러분의 홈랩 스토리지 성능과 데이터 무결성 고민에 작은 도움이 되었으면 좋겠습니다. 혹시 더 궁금한 점이나 여러분의 경험이 있다면 댓글로 공유해 주세요! 다음에는 ZFS ARC 캐싱 최적화에 대해 좀 더 깊이 다뤄볼 예정이니 기대해 주세요!