13년차의 서버실

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

[태그:] ZFS

  • [NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

    [NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

    목차

    [NAS] TrueNAS ZFS 풀 확장: 성능 저하 없이 용량 늘리는 방법 분석

    홈랩(Home Lab, 개인 실험실) NAS를 오래 굴리다 보면 결국 한 번은 맞닥뜨리는 문제가 있습니다. 분명 처음엔 넉넉하다고 생각했는데, 백업 데이터와 미디어 파일, VM 이미지가 쌓이면서 어느 순간 용량이 바닥을 보더라고요. 저도 TrueNAS ZFS 확장을 몇 번 직접 해보면서 느낀 건, 그냥 디스크 하나 더 꽂는다고 끝나는 구조가 아니라는 점이었습니다. 특히 TrueNAS ZFS 확장은 성능과 안정성을 같이 봐야 해서, 잘못 접근하면 NAS 용량 증설은 됐는데 ZFS 성능이 애매해지는 경우가 생깁니다.

    처음엔 저도 “디스크 추가만 하면 되겠지?”라고 생각했었는데, ZFS(제트에프에스, 파일시스템+볼륨 매니저 통합 구조)는 생각보다 설계 철학이 명확합니다. 그래서 오늘은 성능 저하 없이 용량을 늘리는 방법에 초점을 맞춰서, 어떤 방식이 안전한지, 어떤 방식은 조심해야 하는지, 그리고 실제로 확인해야 할 명령어까지 한 번에 정리해보겠습니다.

    TrueNAS ZFS 확장 개요를 보여주는 아키텍처 이미지

    TrueNAS ZFS 확장 전략을 한눈에 보여주는 개요 다이어그램입니다. 기존 풀, vdev, 디스크 추가 방향을 직관적으로 이해할 수 있게 배치하면 좋습니다.

    왜 TrueNAS ZFS 확장이 까다로운가

    쉽게 말해 ZFS는 단순히 디스크 몇 개를 묶는 수준이 아니라, vdev(Virtual Device, 가상 장치) 단위로 성능과 안정성을 관리합니다. 그리고 여러 vdev가 모여 하나의 pool(풀)을 만들죠. 여기서 중요한 포인트가 있습니다. 풀은 확장하기 쉬워 보여도, 기존 vdev 구조는 생각보다 보수적으로 다뤄야 한다는 점입니다.

    예를 들어 mirror(미러, 동일 데이터 복제) vdev 2개로 풀을 만들었다면, 나중에 같은 형태의 mirror vdev를 하나 더 추가하는 건 비교적 자연스럽습니다. 반면 RAIDZ(레이드지, 패리티 기반 보호) vdev 하나로 구성한 풀은, 전통적으로는 그 vdev에 디스크 하나만 툭 추가하는 방식이 깔끔하지 않았거든요. 여기서 많은 분들이 삽질을 시작합니다. 저도 처음엔 이게 뭔가 싶었는데, 구조를 이해하고 나니 왜 ZFS가 그렇게 동작하는지 보이더라고요.

    핵심 개념: 성능 저하 없이 용량 늘린다는 말의 의미

    “성능 저하 없이”라는 표현을 좀 더 정확히 풀어보겠습니다. ZFS에서 성능은 대체로 다음 요소에 영향을 받습니다.

    • vdev 개수: 일반적으로 vdev가 늘어나면 병렬성이 좋아질 수 있습니다.
    • 각 vdev의 디스크 수와 형태: mirror인지 RAIDZ인지에 따라 IOPS(Input/Output Operations Per Second, 초당 입출력 작업 수) 특성이 달라집니다.
    • 디스크 크기와 속도의 균형: 느린 디스크가 섞이면 전체 체감이 나빠질 수 있습니다.
    • 확장 과정 중 resilver(리실버, 데이터 재동기화) 부하: 이 과정에서 일시적으로 성능이 떨어질 수 있습니다.

    즉, 용량만 늘어나는 방식과 용량과 성능 특성을 함께 유지하는 방식은 다릅니다. 실제로 써보니까 가장 덜 후회하는 방법은 아래 두 가지였습니다.

    1. 기존과 동일한 성격의 vdev를 추가해서 풀 병렬성을 유지하는 방법
    2. 기존 디스크를 하나씩 더 큰 디스크로 교체한 뒤 자동 확장(autoexpand, 자동 확장)을 활용하는 방법

    반대로, 크기나 성능이 제각각인 디스크를 즉흥적으로 추가하면 NAS 용량 증설은 되더라도 장기적으로 운영이 피곤해집니다. 특히 장애 대응할 때 구조가 복잡해지더라고요.

    TrueNAS ZFS 확장 방법 비교

    방법 언제 적합한가 ZFS 성능 영향 장점 주의점
    동일한 새 vdev 추가 베이에 여유가 있고 구조를 깔끔하게 유지하고 싶을 때 대체로 유리 병렬성 유지, 확장 논리 명확 같은 급의 디스크를 여러 개 준비해야 함
    기존 디스크 순차 교체 후 확장 베이 여유가 없고 현재 구조를 유지해야 할 때 구조 유지 측면에서 안정적 기존 풀 레이아웃 유지 리실버 시간이 길고 교체 순서가 중요
    서로 다른 특성의 vdev 혼합 추가 임시 증설이 급할 때 예측 어려움 당장 공간 확보 가능 장기 운영, 장애 대응, 체감 성능 모두 애매해질 수 있음

    여기서 제 경험상 가장 추천하는 건 “같은 성격으로 확장하기”입니다. 처음 설계를 mirror로 했다면 mirror로, RAIDZ로 했다면 이후 확장 시에도 같은 패턴을 유지하는 쪽이 관리가 편합니다.

    TrueNAS ZFS 확장 구조에서 pool과 vdev 관계를 설명하는 이미지

    pool 아래에 여러 vdev가 있고, 각 vdev 아래에 디스크가 연결되는 구조를 시각적으로 보여주는 이미지가 들어가면 이해가 훨씬 빠릅니다.

    실전 1: 새 vdev 추가로 TrueNAS ZFS 확장하기

    이 방법은 제가 홈랩에서 가장 선호하는 방식입니다. 이유는 단순합니다. 설계 의도를 망가뜨리지 않고 확장할 수 있거든요. 예를 들어 2디스크 mirror vdev 두 개로 운영 중이었다면, 같은 2디스크 mirror vdev를 하나 더 추가하는 식입니다.

    확장 전 확인

    먼저 현재 풀 구성을 확인합니다.

    zpool status
zpool list
zpool iostat -v 1

    zpool status는 현재 풀과 vdev 상태를, zpool list는 용량과 사용률을, zpool iostat -v 1은 vdev별 I/O 흐름을 보는 데 유용합니다. 저는 확장 전에 이 세 개는 거의 습관처럼 확인합니다. 나중에 비교하기 좋거든요.

    절차

    1. 새 디스크를 장착하고 시스템이 정상 인식하는지 확인합니다.
    2. 기존 풀의 vdev 레이아웃과 동일한 방식으로 새 vdev를 구성합니다.
    3. TrueNAS GUI 또는 CLI(Command Line Interface, 명령줄 인터페이스)에서 풀에 추가합니다.
    4. 추가 직후 I/O 분산과 용량 변화를 확인합니다.

    CLI 예시는 아래처럼 볼 수 있습니다. 디바이스 이름은 환경마다 다르니 반드시 직접 확인하셔야 합니다.

    zpool add tank mirror /dev/disk/by-id/driveA /dev/disk/by-id/driveB

    예시에서 tank는 풀 이름입니다. 이 명령은 새 mirror vdev를 기존 풀에 추가하는 형태입니다. 한 번 추가한 vdev는 쉽게 되돌리기 어렵다는 점, 꼭 기억하셔야 합니다. 제가 예전에 이름 비슷한 디스크를 잘못 보고 진행했다가 식은땀 좀 흘렸습니다 ㅎㅎ

    이 방식이 성능 면에서 유리한 이유

    새 vdev가 추가되면 풀은 더 많은 vdev에 I/O를 분산할 수 있습니다. 물론 워크로드 특성에 따라 체감은 다르지만, 최소한 구조적으로 병렬 처리 경로를 늘리는 방향이라 논리가 깔끔합니다. 특히 VM 저장소나 작은 파일이 많은 환경에서는 이 차이가 은근히 보이더라고요.

    실전 2: 디스크를 하나씩 교체해서 NAS 용량 증설하기

    베이(Bay, 디스크 장착 슬롯)가 꽉 찬 경우에는 이 방법이 현실적입니다. 기존 풀 구조는 유지하면서 디스크 용량만 키우는 방식이죠. mirror든 RAIDZ든 많이 쓰는 패턴인데, 핵심은 한 번에 하나씩 교체하고, 각 교체마다 리실버가 완전히 끝날 때까지 기다리는 것입니다.

    기본 흐름

    1. 현재 상태를 확인합니다.
    2. 기존 디스크 하나를 오프라인 처리하거나 교체 절차에 맞춰 분리합니다.
    3. 더 큰 디스크로 교체합니다.
    4. 리실버 완료를 기다립니다.
    5. 다음 디스크로 같은 작업을 반복합니다.
    6. 모든 디스크가 교체된 뒤 풀 확장 여부를 확인합니다.
    zpool status
zpool offline tank /dev/disk/by-id/old-drive
zpool replace tank /dev/disk/by-id/old-drive /dev/disk/by-id/new-drive
zpool status

    실제 명령은 환경과 장치 식별 방식에 따라 달라질 수 있습니다. 그래서 저는 항상 /dev/disk/by-id 경로처럼 상대적으로 식별이 명확한 쪽을 선호합니다. /dev/sdX 같은 이름은 재부팅이나 장치 순서에 따라 헷갈릴 수 있거든요.

    자동 확장 확인

    디스크를 모두 더 큰 용량으로 바꾼 뒤에도 풀 크기가 바로 기대만큼 안 늘어나는 경우가 있습니다. 이럴 때는 autoexpand(자동 확장) 설정과 풀 상태를 확인해봐야 합니다.

    zpool get autoexpand tank
zpool set autoexpand=on tank
zpool online -e tank /dev/disk/by-id/new-drive

    처음엔 저도 “왜 디스크는 바뀌었는데 용량이 그대로지?” 싶었는데, 이런 부분에서 한 번씩 막히더라고요. 특히 교체 직후 바로 결과만 보고 판단하면 놓치는 게 있습니다. 리실버가 완전히 끝났는지부터 확인하셔야 합니다.

    리실버 진행 상태, 풀 상태, 디스크 교체 흐름을 보여주는 운영 화면 이미지가 있으면 실전 감각이 살아납니다.

    TrueNAS GUI에서 볼 때 체크할 포인트

    CLI가 제일 명확하긴 하지만, 실제 운영에서는 TrueNAS GUI도 꽤 자주 보게 됩니다. 제가 보통 체크하는 항목은 이 정도입니다.

    • Pool 상태: ONLINE인지, DEGRADED인지
    • Disk 상태: 새 디스크가 정상 인식됐는지
    • 작업 진행률: 리실버가 끝났는지
    • Capacity 변화: 예상한 만큼 용량이 반영됐는지
    • Alert: SMART 관련 경고나 I/O 오류가 없는지

    GUI가 편하긴 한데, 중요한 작업일수록 CLI로 최종 확인하는 습관을 추천드립니다. 화면상으론 정상처럼 보여도 세부 상태는 zpool status 쪽이 더 직설적입니다.

    ⚠️ 주의사항과 트러블슈팅

    여기서부터는 정말 실전 얘기입니다. 이 부분 때문에 삽질 좀 했습니다 ㅎㅎ

    1. 디스크 하나만 추가해서 RAIDZ를 키우려는 시도

    많이 하는 착각입니다. 기존 RAIDZ vdev가 있다고 해서, 거기에 디스크 하나를 단순 추가하는 방식이 항상 안전하고 익숙한 운영 패턴은 아닙니다. 운영 환경에서는 지원 여부와 절차를 현재 문서로 꼭 재확인하셔야 하고, 검증된 방식은 동일한 새 vdev 추가 또는 순차 교체라고 보시는 게 안전합니다.

    2. 크기가 다른 디스크를 섞어 넣는 문제

    ZFS는 동작은 하더라도, 실제 활용 가능한 용량과 균형은 가장 작은 축에 맞춰 생각해야 하는 경우가 많습니다. 그리고 확장 계획이 지저분해집니다. 처음엔 급해서 그렇게 넣고 싶어지는데, 나중에 교체 주기 맞출 때 정말 귀찮아집니다.

    3. 리실버 중 성능 저하를 무시하는 문제

    성능 저하 없이라는 말은 확장 중에도 항상 아무 영향이 없다는 뜻은 아닙니다. 리실버 중에는 읽기/쓰기 지연이 늘 수 있습니다. 그래서 중요한 건 최종 구조가 성능 저하를 만들지 않는 방향이어야 한다는 겁니다. 저는 대용량 복제나 스크럽(scrub, 무결성 검사) 작업과 겹치지 않게 시간대를 따로 잡습니다.

    4. 백업 없이 확장 작업부터 들어가는 문제

    이건 정말 강조하고 싶습니다. ZFS가 안정적이라고 해도, 확장 작업은 결국 저장장치 구성 변경입니다. 디스크 자체 불량, 케이블 문제, 슬롯 접촉 불량 같은 변수는 늘 있습니다. 백업 없는 확장은 자신감이 아니라 도박에 가깝습니다.

    5. 디바이스 이름을 대충 보고 진행하는 문제

    /dev/sda, /dev/sdb 같은 이름만 믿고 교체하다가 엉뚱한 디스크를 건드리면 정말 아찔합니다. 가능하면 시리얼 기반 식별 경로를 쓰시고, 작업 전후로 꼭 대조해보세요. 저는 메모장에 디스크 시리얼과 베이 위치를 적어두고 합니다. 이거 진짜 편하더라고요.

    검증: 확장 후 무엇을 확인해야 하나

    확장이 끝났다고 바로 안심하시면 안 됩니다. 최소한 아래 항목은 체크하시는 게 좋습니다.

    1. 풀이 ONLINE 상태인지 확인
    2. 예상한 만큼 총 용량이 늘었는지 확인
    3. 각 vdev에 I/O가 비정상적으로 쏠리지 않는지 확인
    4. 에러 카운터가 증가하지 않는지 확인
    5. SMART 상태와 온도를 점검
    zpool status -v
zpool list
zpool iostat -v 5
smartctl -a /dev/sdX

    zpool iostat -v 5는 5초 단위로 상태를 보기에 좋습니다. 제가 직접 해보니 확장 직후에는 단순히 용량만 보지 말고, 실제로 파일 복사나 백업 작업을 한 번 흘려보내면서 vdev 반응을 같이 보는 게 좋았습니다. 그래야 “늘긴 늘었는데 뭔가 이상하게 굼뜬다” 같은 문제를 빨리 잡을 수 있거든요.

    TrueNAS ZFS 확장 전후 용량과 성능 비교 이미지

    확장 전후의 총 용량, 사용률, I/O 분산 상태를 비교한 대시보드 이미지가 들어가면 결과 섹션의 설득력이 높아집니다.

    어떤 확장 전략이 가장 현실적인가

    환경별로 정리해보면 이렇습니다.

    상황 추천 전략 이유
    디스크 베이에 여유가 있음 동일한 새 vdev 추가 구조 확장이 자연스럽고 병렬성 유지에 유리
    베이가 꽉 참 디스크 순차 교체 현재 레이아웃을 유지하면서 용량만 키우기 좋음
    임시로 공간만 급함 가능하면 정식 확장 전 임시 데이터 정리 무리한 혼합 구성은 장기적으로 손해

    혹시 이런 경험 있으신가요? 급하게 공간이 필요해서 손에 잡히는 디스크부터 넣고 싶은 순간이요. 저도 그랬습니다. 그런데 ZFS는 급한 마음으로 건드릴수록 나중에 구조가 발목을 잡는 편이더라고요. 그래서 제 기준에선 “지금 가장 쉬운 방법”보다 “3년 뒤에도 설명 가능한 구조”가 더 중요했습니다.

    자주 묻는 질문

    Q1. 디스크 추가만 하면 자동으로 성능도 같이 좋아지나요?

    항상 그렇진 않습니다. 어떤 형태의 vdev를 추가했는지, 워크로드가 순차 읽기 위주인지, 랜덤 I/O 위주인지에 따라 다릅니다. 다만 동일한 성격의 vdev를 추가하는 방식은 구조적으로 예측 가능성이 높습니다.

    Q2. NAS 용량 증설 시 제일 먼저 볼 명령은 뭔가요?

    저는 zpool status부터 봅니다. 상태를 모르고 작업하는 건 위험합니다. 그다음 zpool list, 필요하면 zpool iostat -v를 봅니다.

    Q3. ZFS 성능을 위해 SSD 캐시만 추가하면 해결되나요?

    캐시 장치는 특정 워크로드에서 도움이 될 수 있지만, 기본 풀 구조가 좋지 않으면 근본 해결은 아닙니다. 먼저 풀 레이아웃과 vdev 구성을 정리하는 게 우선입니다. 캐시는 그 다음입니다.

    정리: TrueNAS ZFS 확장은 구조를 지키는 쪽이 결국 이깁니다

    오늘 정리한 내용을 한 줄로 줄이면 이렇습니다. TrueNAS ZFS 확장은 단순히 디스크 추가가 아니라, vdev 구조를 어떻게 유지하느냐의 문제입니다. 성능 저하 없이 가고 싶다면 검증된 방식으로 접근하시는 게 맞습니다. 즉, 베이에 여유가 있으면 동일한 새 vdev를 추가하고, 여유가 없으면 기존 디스크를 하나씩 더 큰 용량으로 교체하는 쪽이 가장 현실적입니다.

    저도 처음엔 용량만 보면 되는 줄 알았는데, 실제로 써보니까 결국 중요한 건 장기 운영의 일관성이었습니다. ZFS 성능, 장애 대응, 다음 증설 계획까지 생각하면 설계를 흐트러뜨리지 않는 게 제일 낫더라고요. 다음 글에서는 스크럽 주기, SMART 모니터링, 백업 전략까지 묶어서 홈랩 NAS 운영 체크리스트로 정리해보겠습니다. 이전 글에서 다뤘던 스토리지 모니터링 내용과 같이 보시면 더 도움이 되실 겁니다.

    TrueNAS ZFS 확장 전략을 요약한 인포그래픽 이미지

    추천 확장 방식, 피해야 할 방식, 점검 명령어를 한 장으로 정리한 요약 인포그래픽 이미지가 마무리용으로 잘 어울립니다.

  • [NAS] TrueNAS SCALE로 NAS OS 마이그레이션: OpenMediaVault에서 안전하게 전환하기

    [NAS] TrueNAS SCALE로 NAS OS 마이그레이션: OpenMediaVault에서 안전하게 전환하기

    목차

    [NAS] TrueNAS SCALE로 NAS OS 마이그레이션: OpenMediaVault에서 안전하게 전환하기

    안녕하세요, 13년차 서버 관리자입니다. 오늘은 최근 홈랩에서 진행한 꽤 큰 프로젝트, 바로 NAS OS 마이그레이션 경험담을 풀어볼까 합니다. 저의 든든한 파일 서버 역할을 해왔던 OpenMediaVault를 뒤로하고, 새로운 강력한 친구 TrueNAS SCALE로 갈아탔거든요. 혹시 여러분 중에도 OMV의 한계를 느끼고 더 강력하고 유연한 NAS OS를 찾아 헤매고 계신 분이 있다면, 이 글이 좋은 길잡이가 될 거라고 생각합니다. 제가 겪었던 삽질까지 솔직하게 공유할 테니, 편하게 따라오실 수 있을 거예요!

    OpenMediaVault에서 TrueNAS SCALE로의 NAS OS 마이그레이션 전체 흐름도

    NAS OS 마이그레이션의 전체 흐름: OMV에서 TrueNAS SCALE로의 여정

    왜 OpenMediaVault에서 TrueNAS SCALE로 옮겼을까?

    사실 OpenMediaVault는 가볍고 안정적인 NAS OS였습니다. 초기 홈랩을 꾸릴 때 정말 많은 도움을 줬죠. 하지만 시간이 흐르고 제가 원하는 기능들이 많아지면서, OMV만으로는 뭔가 부족하다는 느낌을 지울 수 없었습니다. 특히 컨테이너 기반의 애플리케이션(Docker, Kubernetes)을 더 유연하게 활용하고 싶었고, ZFS 파일 시스템의 강력함에 점점 매료되었거든요.

    • OpenMediaVault (OMV): Debian 기반의 NAS 솔루션으로, 웹 UI를 통해 파일 공유(SMB/NFS), RAID 관리, 플러그인 설치 등을 쉽게 할 수 있습니다. 가볍고 안정적이라는 장점이 있지만, ZFS 지원이 제한적이고, 컨테이너 오케스트레이션 기능은 외부 플러그인에 의존해야 하는 한계가 있었어요.
    • TrueNAS SCALE: TrueNAS CORE의 FreeBSD 기반과 달리, Linux 기반(Debian)으로 개발된 TrueNAS의 새로운 버전입니다. ZFS (Zettabyte File System) 기반의 강력한 데이터 무결성 및 스냅샷 기능은 물론, KVM (Kernel-based Virtual Machine) 가상화와 Kubernetes (쿠버네티스) 기반의 컨테이너 앱(Docker 컨테이너를 쉽게 배포할 수 있는 환경)을 기본으로 제공합니다. 쉽게 말해, 스토리지뿐만 아니라 가상화 및 컨테이너 플랫폼 역할까지 한 번에 할 수 있는 만능 인프라 서버인 셈이죠!

    저는 더 이상 OMV가 제공하지 못하는 유연성과 확장성이 필요했고, TrueNAS SCALE이 그 해답이라고 확신했습니다. 특히 데이터 안정성에 집착하는 저로서는 ZFS의 매력을 뿌리칠 수 없었거든요. 결국 이 대대적인 마이그레이션 프로젝트를 감행하게 되었습니다.

    마이그레이션 준비: 철저함이 생명!

    NAS OS 마이그레이션은 단순히 새 OS를 설치하는 것과는 다릅니다. 기존 데이터를 안전하게 옮기는 것이 가장 중요하죠. 제가 가장 중요하게 생각했던 준비물은 바로 이것들이었습니다.

    1. 데이터 백업 (Data Backup): ⚠️ 가장 중요합니다! 모든 데이터는 소중하니까요. 저는 마이그레이션 전에 외장 하드나 다른 NAS로 데이터를 한 번 더 백업해두었습니다. 혹시 모를 사태에 대비하는 건 인프라 엔지니어의 기본 소양이거든요.
    2. 하드웨어 호환성 확인: TrueNAS SCALE은 OMV보다 리소스 요구량이 높은 편입니다. 특히 ZFS는 RAM을 많이 사용하므로, 최소 8GB 이상의 RAM을 권장합니다. 제 홈랩 서버는 다행히 충분한 사양이라 걱정은 없었습니다.
    3. 기존 OMV 설정 기록: 공유 폴더(SMB/NFS), 사용자 계정, 네트워크 설정 등 OMV에서 사용하던 모든 설정을 스크린샷이나 메모로 남겨두었습니다. 새 OS에서 똑같이 재현해야 하니까요.
    4. 새로운 OS 설치용 드라이브: TrueNAS SCALE은 OS 전용 드라이브를 따로 사용하는 것을 권장합니다. 데이터 드라이브와 분리해야 나중에 관리하기 편하고, ZFS 풀에 영향을 주지 않습니다. 저는 작은 SSD를 OS용으로 준비했습니다.
    5. 부팅 USB: TrueNAS SCALE 설치를 위한 부팅 USB를 미리 만들어 두어야겠죠.

    TrueNAS SCALE 설치와 ZFS Pool 임포트 삽질기

    준비가 끝났으니 이제 실전입니다. TrueNAS SCALE 설치 자체는 크게 어렵지 않아요. 공식 웹사이트에서 ISO 파일을 다운로드받아 Rufus 같은 툴로 부팅 USB를 만들고, 서버에 연결해서 부팅하면 됩니다.

    1. TrueNAS SCALE 설치:

      서버를 부팅 USB로 부팅하고, 설치 마법사를 따라 OS 전용 드라이브(미리 준비한 SSD)에 TrueNAS SCALE을 설치합니다. 이때 데이터 드라이브를 잘못 선택하지 않도록 조심하세요! 저는 항상 긴장하면서 더블 체크하는 편입니다.

      # 설치 완료 후 첫 부팅 시, 콘솔 화면에서 네트워크 설정 등을 확인할 수 있습니다.
# 예를 들어, IP 주소를 확인하여 웹 UI에 접속합니다.
# ifconfig
    2. 초기 네트워크 및 관리자 설정:

      설치가 완료되고 재부팅하면, 콘솔 화면에 접속할 IP 주소가 표시됩니다. 웹 브라우저로 접속해서 초기 관리자 계정(root) 비밀번호를 설정하고, 필요한 네트워크 설정을 진행합니다. 저의 경우엔 고정 IP를 할당해줬습니다.

    3. ZFS Pool 임포트 (Import Pool): 🎉 드디어 핵심!

      이 부분이 가장 중요하면서도 제가 삽질을 가장 많이 했던 부분입니다. OpenMediaVault에서 사용하던 데이터 디스크들을 TrueNAS SCALE이 인식하고, 기존 데이터를 유지한 채 가져오는 과정이 필요합니다. OMV에서는 ZFS를 사용하지 않았었기 때문에, TrueNAS SCALE에서 새로운 ZFS Pool을 생성하고, OMV에서 사용하던 디스크의 데이터를 옮겨야 하는 상황이었습니다. 하지만 저는 OMV에서 이미 데이터를 RAID로 묶어 사용하고 있었기 때문에, 이 디스크들을 TrueNAS SCALE에서 바로 ZFS Pool로 임포트하는 과정이 순탄치 않았습니다. 만약 OMV에서 ZFS를 사용했다면 훨씬 쉬웠겠지만, 일반적인 EXT4 등으로 구성된 데이터 디스크라면 아래와 같이 새로운 ZFS Pool을 만들고 데이터를 옮겨야 합니다.

      🚨 중요: 이 과정에서 기존 데이터가 삭제될 수 있으니, 반드시 백업을 먼저 하세요!

      저는 결국 새로운 ZFS Pool을 만들고 기존 OMV 데이터를 네트워크를 통해 복사하는 방식을 택했습니다. OMV가 설치된 드라이브는 OS용으로 사용하고, 데이터 드라이브는 TrueNAS SCALE에서 새로운 ZFS Pool로 구성하는 거죠.

      1. Storage > Pools > Add 메뉴로 이동합니다.
      2. Create new Pool을 선택하고 이름을 지정합니다 (예: data_pool).
      3. 기존 OMV에서 사용하던 데이터 디스크들을 선택하여 새로운 Pool을 구성합니다. 이때 RAIDZ1, RAIDZ2 등 원하는 RAID 레벨을 선택합니다. 저는 RAIDZ2로 구성하여 데이터 안정성을 높였습니다.
      4. Pool 생성을 진행하면, 선택된 디스크의 모든 데이터가 지워집니다! 다시 한번 강조하지만, 백업이 필수입니다.

      새로운 ZFS Pool이 생성되면, 이제 기존 OMV 서버에 접속하여 rsync 명령어나 SMB/NFS 마운트를 통해 데이터를 새로운 TrueNAS SCALE 서버로 복사합니다. 저는 rsync를 사용했습니다.

      # 기존 OMV 서버에서 TrueNAS SCALE로 데이터 복사 (예시)
# rsync -avh --progress /path/to/old/data/ user@truenas_ip:/path/to/new/pool/
# -a: 아카이브 모드 (권한, 시간 정보 등 유지)
# -v: 자세한 정보 출력
# -h: 사람이 읽기 쉬운 형식으로 출력
# --progress: 진행 상황 표시

      이 과정이 시간이 가장 오래 걸렸습니다. 테라바이트 단위의 데이터를 옮기려면 인내심이 필요하더라고요. 저는 밤새도록 rsync를 돌려놓고 잠들었습니다.

    TrueNAS SCALE 웹 인터페이스에서 새로운 ZFS Pool을 생성하고 디스크를 선택하는 과정

    TrueNAS SCALE 웹 인터페이스에서 새로운 ZFS Pool을 생성하고 디스크를 선택하는 과정

    주의사항 및 트러블슈팅: 제가 겪었던 문제들

    마이그레이션은 언제나 예상치 못한 변수가 생기기 마련이죠. 저도 몇 가지 문제에 부딪혔습니다.

    • ⚠️ 기존 OMV에서 ZFS를 사용하지 않은 경우의 Pool 임포트: 위에서 설명했듯이, OMV가 EXT4 등으로 구성된 볼륨이었다면 TrueNAS SCALE에서 바로 Pool 임포트가 불가능합니다. 이 경우 반드시 새로운 ZFS Pool을 생성하고 데이터를 복사해야 합니다. 이 점을 간과하고 “Import Pool” 메뉴에서 계속 헤맸던 것이 첫 번째 삽질이었습니다. OMV에서 ZFS를 사용하지 않았다면, 무조건 새로운 Pool을 만들고 데이터를 복사하세요!
    • ⚠️ 네트워크 설정 문제: TrueNAS SCALE 설치 후 웹 UI 접속이 안 되는 경우가 있었습니다. 대부분 네트워크 인터페이스 설정이 잘못되었거나 DHCP 서버에서 IP를 제대로 받지 못했을 때 발생하더군요. 콘솔에서 ifconfig 명령어로 IP 주소를 확인하고, 필요하면 네트워크 설정을 다시 했습니다.
    • ⚠️ 권한 문제: 데이터를 옮긴 후 SMB/NFS 공유를 설정했는데, 특정 사용자나 그룹이 접근하지 못하는 문제가 발생했습니다. ZFS는 강력한 ACL (Access Control List)을 지원하지만, 그만큼 설정이 복잡할 수 있습니다. 저는 chmod, chown 명령어를 사용하거나 웹 UI에서 데이터셋(Dataset)의 권한을 다시 설정하며 해결했습니다. 특히 Windows에서 접근할 때는 SMB 공유 설정 시 “Guest access”나 “Auxiliary parameters”를 잘 활용해야 합니다.

    결과 및 활용: 드디어 TrueNAS SCALE!

    데이터 복사가 끝나고 모든 설정이 완료되었을 때의 그 쾌감이란! 드디어 제가 원하던 TrueNAS SCALE 기반의 NAS가 완성되었습니다. 웹 UI에 접속해서 모든 데이터가 정상적으로 올라와 있고, ZFS Pool 상태가 Healthy임을 확인했을 때, “드디어 됐다!” 하고 외쳤습니다. 🎉

    TrueNAS SCALE 대시보드에서 시스템 상태와 ZFS Pool 정보가 Healthy로 표시된 화면

    TrueNAS SCALE 대시보드에서 ZFS Pool 상태와 시스템 리소스를 한눈에 확인하는 모습

    이제 TrueNAS SCALE의 강력한 기능을 마음껏 활용할 수 있게 되었습니다. 특히 Apps (앱스) 기능을 통해 다양한 컨테이너 기반 서비스를 쉽게 배포할 수 있는 점이 너무 좋더라고요. 저는 바로 Plex Media Server, Nextcloud, 그리고 Home Assistant를 설치했습니다. 이전 OMV에서는 Docker를 수동으로 설치하고 관리해야 했지만, TrueNAS SCALE에서는 몇 번의 클릭만으로 손쉽게 배포하고 관리할 수 있으니 정말 편하더라고요.

    • Plex Media Server: 제 미디어 라이브러리를 스트리밍하는 데 필수죠.
    • Nextcloud: 개인 클라우드 스토리지를 구축하여 파일을 동기화하고 공유합니다.
    • Home Assistant: 홈 자동화를 위한 핵심 플랫폼입니다.

    OpenMediaVault vs. TrueNAS SCALE 비교

    제가 직접 두 OS를 모두 사용해본 경험을 바탕으로 간단히 비교해보겠습니다.

    카테고리 OpenMediaVault (OMV) TrueNAS SCALE
    기반 OS Debian Linux Debian Linux
    파일 시스템 EXT4, XFS 등 (ZFS는 플러그인 통해 제한적 지원) ZFS (네이티브 지원, 핵심 기능)
    컨테이너/가상화 Docker (플러그인), VM (VirtualBox 플러그인) Kubernetes (Apps), KVM (가상화) 네이티브 지원
    데이터 무결성 파일 시스템 자체 기능에 의존 ZFS 체크섬, 스냅샷, 데이터 스크러빙 등 강력한 기능
    UI/관리 편의성 간단하고 직관적 초기 학습 곡선이 있지만, 강력하고 세밀한 설정 가능
    리소스 요구량 비교적 낮음 ZFS 때문에 RAM 요구량 높음 (최소 8GB 권장)
    주요 사용처 가볍고 안정적인 홈 NAS, 파일 공유 고성능/고안정성 홈랩/소규모 서버, 통합 스토리지/가상화/컨테이너 플랫폼
    OpenMediaVault와 TrueNAS SCALE의 주요 기능 비교 인포그래픽

    두 NAS OS의 주요 기능과 특징을 한눈에 비교한 표

    마무리하며: 또 한 번 성장한 삽질 경험

    OpenMediaVault에서 TrueNAS SCALE로의 마이그레이션은 저에게 또 하나의 소중한 경험이 되었습니다. 단순히 OS를 바꾸는 것을 넘어, ZFS 파일 시스템의 깊이와 컨테이너 오케스트레이션의 중요성을 다시 한번 깨달았거든요. 물론 중간에 삽질도 많이 했지만, 그 과정에서 얻은 지식과 해결 능력은 어떤 기술 서적에서도 얻을 수 없는 값진 것이었습니다.

    TrueNAS SCALE은 홈랩 환경에서 강력한 스토리지와 유연한 애플리케이션 플랫폼을 동시에 원하는 분들에게 정말 좋은 선택지가 될 거라고 생각합니다. 혹시 마이그레이션을 고민하고 계시다면, 제 경험담이 조금이나마 도움이 되었으면 좋겠네요. 다음번에는 TrueNAS SCALE의 Apps 기능을 활용해서 제가 운영하는 컨테이너 서비스들을 좀 더 자세히 소개하는 글을 들고 오겠습니다. 그때까지 모두 즐거운 삽질(?) 되세요! 감사합니다.

  • [Nas] TrueNAS SCALE vs OpenMediaVault: 13년차 서버 엔지니어의 1년 사용 후 NAS 선택 가이드

    [Nas] TrueNAS SCALE vs OpenMediaVault: 13년차 서버 엔지니어의 1년 사용 후 NAS 선택 가이드

    목차

    TrueNAS SCALE vs OpenMediaVault: 13년차 서버 엔지니어의 1년 사용 후 NAS 선택 가이드

    안녕하세요! 13년차 서버 엔지니어, ’13년차의 서버실’ 블로그를 운영하고 있는 엔지니어입니다. 홈랩(Homelab)을 운영하며 다양한 서버와 스토리지 솔루션을 직접 만져보고 경험하는 것을 즐기는데요. 오늘은 많은 분들이 홈 서버 구축 시 가장 많이 고민하시는 두 가지 NAS 운영체제, TrueNAS SCALE와 OpenMediaVault (OMV)에 대한 제 1년간의 실사용 경험을 바탕으로 솔직한 비교 가이드를 공유해볼까 합니다.

    혹시 이런 고민, 해보신 적 없으신가요? “NAS를 새로 사거나 기존 장비를 업그레이드해야 하는데, 어떤 운영체제를 써야 할까?” “ZFS가 좋다고는 하는데, Btrfs는 뭐가 다를까?” “설치도 어렵고 설정도 복잡하면 어쩌지?” 저도 처음에는 비슷한 고민을 했더라고요. 그래서 직접 두 시스템을 설치하고 1년 가까이 사용해보면서 얻은 경험들을 정리해봤습니다. 이 글을 통해 여러분의 홈 서버 환경에 딱 맞는 NAS 솔루션을 찾으시길 바랍니다.

    [개요] TrueNAS SCALE vs OpenMediaVault: 선택의 기로

    1. NAS와 파일 시스템 선택: ZFS vs Btrfs 완벽 비교

    NAS(Network Attached Storage)는 말 그대로 네트워크에 연결된 저장 장치입니다. 개인적인 파일 저장, 미디어 서버 구축, 백업 솔루션, 심지어는 가상 머신(VM)이나 컨테이너(Container)를 운영하는 홈 서버의 핵심 인프라로도 활용될 수 있죠. 특히 요즘처럼 데이터 손실이 큰 문제가 되는 시대에는 어떤 파일 시스템을 사용하느냐가 NAS 선택의 가장 중요한 기준이 됩니다.

    여기서 핵심적인 두 가지 파일 시스템이 등장합니다. 바로 ZFS와 Btrfs입니다.

    • ZFS: 데이터 무결성(Data Integrity)이라고 하면, ZFS는 정말 거의 최고 수준이거든요. 데이터 복제(Mirroring) 및 패리티(Parity)를 통한 RAID 기능은 물론, 스냅샷(Snapshot) 기능으로 특정 시점의 데이터로 복구하는 게 정말 쉬워요. 특히 데이터가 저장될 때마다 체크섬(Checksum)을 생성하여 손상을 자동으로 감지하고 복구하는 기능(Scrubbing)은 ZFS의 가장 강력한 장점입니다. 다만, 메모리(RAM)를 상대적으로 많이 요구하는 편이고, RAID 구성 시 유연성이 다소 떨어진다는 게 단점입니다.
    • Btrfs: ZFS와 유사한 스냅샷, 데이터 무결성 검사, 온라인 RAID 재구성 등 다양한 고급 기능을 제공합니다. ZFS보다 상대적으로 시스템 요구 사양이 낮고, 유연한 볼륨 관리가 가능하다는 게 장점입니다. 다만 ZFS만큼 오랜 기간 검증되지는 않았다는 인식이 있으며, 특히 RAID 5/6 구성에서의 안정성에 대한 논란이 과거에 있었죠. (물론 지금은 많이 개선되고 있습니다.)

    TrueNAS SCALE은 기본적으로 ZFS를, OpenMediaVault는 주로 Btrfs (또는 ext4, XFS 등 다양한 파일 시스템도 선택 가능)를 사용합니다. 이 파일 시스템의 차이가 두 시스템의 성격과 사용성을 크게 결정짓는다고 볼 수 있어요. 쉽게 말해, ZFS는 ‘안정성’에, Btrfs는 ‘유연성’에 좀 더 초점을 맞춘다고 생각하시면 이해하기 쉬울 겁니다.

    2. TrueNAS SCALE: ZFS 기반의 강력한 데이터 보호

    TrueNAS는 오랜 기간 스토리지 솔루션의 강자로 자리매김해왔습니다. 특히 엔터프라이즈 환경에서 그 성능과 안정성을 인정받았죠. TrueNAS SCALE은 리눅스 기반(Debian)으로 전환하면서 기존의 FreeBSD 기반 TrueNAS CORE보다 훨씬 더 많은 유연성을 확보했어요. Docker 컨테이너와 가상 머신(KVM) 지원이 강화된 것이 가장 큰 특징입니다.

    2.1. 설치 과정: 꽤나 직관적이지만…

    설치 자체는 ISO 이미지를 USB에 굽고 부팅하여 진행하는 방식으로, 일반적인 리눅스 배포판 설치와 크게 다르지 않습니다. 다만, ZFS 풀(Pool)을 구성해야 하므로, 설치 시 디스크 구성에 대한 사전 이해가 필요해요. 처음엔 디스크 할당 방식이 조금 낯설 수 있지만, 차근차근 따라 하면 큰 어려움은 없습니다.

    TrueNAS SCALE 설치 시 디스크 할당 화면

    [설치] 디스크 할당 과정

    2.2. 주요 기능 및 사용성: ZFS의 강력함을 경험하다

    TrueNAS SCALE의 가장 큰 매력은 역시 ZFS입니다. 제가 1년간 사용하면서 가장 만족했던 부분은 데이터 무결성에 대한 압도적인 신뢰감이었어요. 데이터가 손상될까 봐 불안해하는 마음이 정말 사라지더라고요. 정기적인 스크럽(Scrub) 기능은 마치 데이터의 건강검진 같은 기분이었습니다.

    또한, 웹 UI(Web User Interface)가 정말 잘 갖춰져 있습니다. 스토리지 풀(Pool) 관리, 데이터셋(Dataset) 생성, 스냅샷 관리, 공유(SMB/NFS) 설정 등이 직관적으로 가능하거든요. 특히, Docker와 KVM을 지원하면서 단순 NAS를 넘어 홈 서버로서의 확장성이 정말 뛰어나요. Plex, Jellyfin 같은 미디어 서버, Home Assistant, Pi-hole 등 다양한 애플리케이션을 손쉽게 설치하고 운영할 수 있다는 게 정말 좋았습니다.

    2.3. 삽질 경험: 메모리와 디스크 구성의 중요성

    TrueNAS SCALE을 사용하면서 가장 크게 느낀 점은 메모리(RAM)의 중요성입니다. ZFS는 메모리를 많이 사용할수록 성능이 향상되는 경향이 있거든요. 제가 처음에는 8GB 램으로 시작했는데, 아무래도 부족하다는 느낌을 받았어요. 특히 VM을 여러 개 돌리거나 Docker 컨테이너를 많이 사용할 때는 메모리 부족 현상이 정말 두드러지더라고요. 결국 16GB, 지금은 32GB로 업그레이드하면서 훨씬 쾌적한 사용이 가능해졌습니다. 최소 16GB, 권장 32GB 이상을 추천드립니다.

    디스크 구성도 정말 중요합니다. ZFS는 단일 디스크보다는 여러 개의 디스크를 묶어 풀(Pool)을 구성하는 것이 일반적이거든요. 미러(Mirror) 구성이나 RAID-Z 구성 등 데이터 보호 수준에 따라 선택해야 하는데, 한번 구성하면 변경이 어렵기 때문에 처음부터 신중하게 계획해야 해요. 저도 처음에는 디스크 개수와 구성 방식을 두고 한참을 고민했습니다. 실수로 데이터를 날릴 수도 있으니, 중요한 데이터는 반드시 별도로 백업하는 습관이 정말 중요합니다.

    3. OpenMediaVault (OMV): 간편함과 유연성의 결합

    OpenMediaVault(OMV)는 Debian Linux 기반의 NAS 솔루션으로, 정말 가볍고 유연한 게 특징입니다. 다양한 하드웨어에서 잘 작동하며, 설치 및 설정이 TrueNAS SCALE에 비해 훨씬 간편하다는 게 가장 큰 장점입니다.

    3.1. 설치 과정: 정말 쉽고 빠르다!

    OMV 설치는 정말 간단합니다. ISO 이미지를 USB에 굽고 부팅하면 몇 번의 클릭만으로 설치가 금방 끝나요. 파일 시스템 역시 Btrfs, ext4, XFS 등 사용자가 원하는 것을 자유롭게 선택할 수 있어서 유연성이 정말 높습니다. 제 경우에는 기존에 사용하던 저사양 미니PC에 설치했는데, 정말 금방 세팅이 끝나서 깜짝 놀랐습니다.

    OpenMediaVault 웹 UI 메인 대시보드

    [설치] OMV 웹 UI 대시보드

    3.2. 주요 기능 및 사용성: 플러그인 생태계의 매력

    OMV의 가장 큰 강점은 간편한 설정과 뛰어난 확장성입니다. 웹 UI가 정말 직관적이고 사용하기 쉬워서 NAS 초보자도 금방 익숙해질 수 있거든요. SMB/CIFS, NFS, FTP 등 기본적인 파일 공유 설정은 물론, Plex, Transmission, Docker 등 다양한 서비스들을 플러그인(Plugin) 형태로 손쉽게 추가하고 관리할 수 있습니다. 특히, Docker 플러그인을 통해 컨테이너 기반의 애플리케이션을 운영하는 게 정말 편리하더라고요.

    제가 OMV를 사용하면서 정말 좋았던 부분은 Btrfs의 유연성입니다. ZFS처럼 엄격하게 디스크 구성을 강요하지 않으면서도, 스냅샷 기능 등을 활용할 수 있다는 게 정말 매력적이었어요. 다양한 파일 시스템을 지원하기 때문에 하드웨어 환경에 맞춰 최적의 선택을 할 수 있다는 것도 큰 장점입니다.

    3.3. 삽질 경험: 플러그인 호환성과 Btrfs의 주의점

    OMV도 완벽하지는 않더라고요. 가끔 특정 플러그인이 최신 버전의 OMV와 호환되지 않거나, 설정이 꼬여서 문제를 일으키는 경우가 있었습니다. ⚠️ 이런 경우에는 플러그인 개발자 커뮤니티나 OMV 포럼을 확인하며 해결해야 했어요. 모든 플러그인이 항상 안정적인 것은 아니라는 점을 꼭 염두에 두어야 합니다.

    Btrfs 파일 시스템을 사용할 때는 몇 가지 주의할 점이 있습니다. 앞서 언급했듯이, 과거 RAID 5/6 구성에서의 안정성 이슈가 있었거든요. 물론 현재는 많이 개선되었지만, 여전히 데이터의 절대적인 안정성이 최우선이라면 ZFS를 사용하는 것이 더 안전하다고 생각합니다. 저는 OMV에서는 주로 Btrfs의 스냅샷 기능을 활용하고, 중요한 데이터는 별도의 백업 시스템으로 관리하는 방식으로 사용하고 있습니다.

    4. TrueNAS SCALE vs OpenMediaVault: 1년 사용 후 솔직한 비교 분석

    1년간 두 시스템을 직접 사용해보면서 느낀 점들을 표로 정리해 봤습니다. 어떤 환경과 목적에 더 적합할지 판단하시는 데 도움이 되기를 바랍니다.

    구분 TrueNAS SCALE OpenMediaVault (OMV)
    기반 OS Debian Linux Debian Linux
    주요 파일 시스템 ZFS Btrfs, ext4, XFS 등
    데이터 안정성 최상 (ZFS) 좋음 (Btrfs, ext4 등)
    시스템 요구 사양 높음 (특히 RAM) 낮음 ~ 보통
    설치 및 설정 난이도 중간 (ZFS 이해 필요) 쉬움
    컨테이너/VM 지원 강력함 (Docker, KVM) 좋음 (주로 Docker 플러그인)
    확장성 (플러그인/앱) 좋음 (TrueCharts 등) 매우 좋음 (다양한 플러그인)
    UI/UX 전문적, 기능 중심 직관적, 사용자 친화적
    추천 사용자 데이터 안정성 최우선, 홈 서버 확장성 중시, ZFS 경험자 NAS 초보자, 간편한 설정 선호, 다양한 서비스 실험 희망자
    TrueNAS SCALE vs OpenMediaVault 주요 특징 비교 인포그래픽

    [비교] 핵심 기능 비교 요약

    5. 결론: 당신에게 맞는 NAS는?

    1년이라는 시간 동안 TrueNAS SCALE과 OpenMediaVault를 직접 사용해보니, 두 시스템 모두 정말 훌륭한 NAS 운영체제라는 걸 다시 한번 느꼈어요. 하지만 명확한 차이점이 존재하며, 어떤 시스템이 더 좋다고 단정하기보다는 각자의 환경과 목적에 맞는 선택이 정말 중요합니다.

    • 데이터의 절대적인 안정성과 신뢰성이 최우선이고, RAM 등 시스템 사양에 대한 투자가 가능하다면 TrueNAS SCALE을 강력하게 추천합니다. ZFS의 강력한 데이터 보호 기능과 함께 Docker, KVM을 활용한 홈 서버 확장까지 고려한다면 정말 최고의 선택이 될 거예요.
    • 설치가 간편하고 빠르게 NAS를 구축하고 싶거나, 다양한 서비스를 유연하게 추가하며 사용하고 싶다면 OpenMediaVault가 정말 좋은 선택입니다. 특히 NAS를 처음 접하는 분들에게는 OMV가 훨씬 친숙하게 다가갈 수 있을 거라고 확신합니다.

    저 같은 경우, 현재는 두 시스템을 병행하여 사용하고 있습니다. 중요한 데이터 저장 및 백업용으로는 TrueNAS SCALE을, 다양한 실험용 홈 서버로는 OpenMediaVault를 활용하고 있죠. 이렇게 듀얼 시스템을 운영하는 것도 하나의 좋은 방법이 될 수 있습니다. 😊

    궁극적으로 NAS 선택은 개인의 경험과 선호도에 따라 달라질 수 있습니다. 이 글이 여러분의 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를 사용할 경우입니다.

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

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

    3. 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 와 같이 명령어를 사용합니다.

    2. 마운트 포인트 생성 및 마운트:
      3. mkdir /mnt/mybtrfs
mount /dev/sde /mnt/mybtrfs
    3. fstab에 등록 (재부팅 시 자동 마운트): UUID를 사용해 등록하는 것이 좋습니다.
      4. echo "UUID=$(blkid -s UUID -o value /dev/sde) /mnt/mybtrfs btrfs defaults 0 0" >> /etc/fstab
    4. 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 캐싱 최적화에 대해 좀 더 깊이 다뤄볼 예정이니 기대해 주세요!

  • [Nas] TrueNAS & Synology NAS SMB 속도 저하, 원인 진단부터 해결까지

    [Nas] TrueNAS & Synology NAS SMB 속도 저하, 원인 진단부터 해결까지

    목차

    안녕하세요, 13년차의 서버실입니다. 오늘은 많은 분들이 홈랩이나 소규모 오피스 환경에서 겪으실 법한 골치 아픈 문제, 바로 NAS SMB 속도 저하에 대해 이야기해보려고 합니다. 저도 이 문제 때문에 꽤나 삽질을 많이 했었거든요.

    TrueNAS나 Synology NAS를 사용하면서, 파일 전송 속도가 기대 이하라 실망했던 경험, 혹시 있으신가요? 특히 대용량 파일을 옮기거나 여러 명이 동시에 접근할 때 속도가 뚝 떨어지는 현상 말이죠. 오늘은 이 NAS SMB 속도 저하의 원인을 진단하고, 제가 직접 해봤던 해결 방법들을 멘토처럼 자세히 알려드리겠습니다. TrueNAS SMB, Synology SMB 환경에서 쾌적한 파일 전송 속도를 위한 여정, 저와 함께 떠나보시죠!

    NAS SMB 속도 저하 문제 진단 및 해결을 위한 흐름도

    NAS SMB 속도 저하 문제 진단 및 해결을 위한 전체 흐름도입니다.

    🤔 NAS SMB 속도 저하, 왜 발생할까요? (개념 설명)

    먼저, 문제가 어디서 오는지 파악하려면 기본 개념부터 알아야겠죠? SMB(Server Message Block)는 Windows 운영체제에서 파일을 공유하고 접근하기 위해 주로 사용되는 네트워크 프로토콜입니다. 쉽게 말해, 윈도우 탐색기에서 네트워크 드라이브 연결해서 파일을 주고받을 때 쓰는 방식이라고 생각하시면 돼요.

    이 SMB 속도가 느려지는 원인은 크게 세 가지로 볼 수 있습니다.

    • 네트워크 병목(Network Bottleneck): 가장 흔한 원인 중 하나죠. NAS와 클라이언트 PC를 연결하는 네트워크 장비(케이블, 스위치, Wi-Fi)나 NIC(Network Interface Card, 네트워크 인터페이스 카드)의 성능이 파일 전송 속도를 따라가지 못하는 경우입니다.
    • 하드웨어 한계(Hardware Limitations): NAS 자체의 하드웨어 성능이 부족할 수도 있어요. CPU, RAM, 그리고 가장 중요한 디스크 I/O(Input/Output) 성능이 병목 지점이 될 수 있거든요. 특히 여러 개의 HDD로 구성된 NAS의 경우, 디스크의 읽기/쓰기 속도 자체가 한계일 수 있습니다.
    • 소프트웨어/설정 문제(Software/Configuration Issues): SMB 서비스 설정, 네트워크 드라이버 설정, 심지어 클라이언트 PC의 방화벽이나 안티바이러스 프로그램이 속도를 저하시킬 수도 있어요. 특히 Jumbo Frames(점보 프레임) 같은 고급 네트워크 설정은 잘못 건드리면 오히려 독이 될 수 있죠.

    🛠️ 실전! 원인 진단부터 해결까지

    이제 본격적으로 NAS SMB 속도 저하의 원인을 찾아내고 해결하는 과정을 단계별로 살펴보겠습니다. 제가 직접 겪었던 경험을 바탕으로 설명해 드릴게요.

    1. 네트워크 환경 점검하기

    가장 먼저 의심해야 할 부분은 바로 네트워크입니다. “혹시 기가비트가 아닌가?” 하는 의심부터 시작해야 해요.

    1. 케이블 확인: 사용하는 이더넷 케이블이 CAT5e 이상인지 확인하세요. 오래된 CAT5 케이블은 기가비트(Gigabit) 속도를 지원하지 않거나 불안정할 수 있어요. 꼬임 방식이나 차폐 여부에 따라 CAT5e, CAT6, CAT7 등으로 나뉘는데, 최소 CAT5e 이상, 가능하다면 CAT6 이상을 권장합니다.
    2. 스위치 및 라우터 확인: NAS와 클라이언트 PC가 연결된 스위치(Switch)나 라우터(Router)가 기가비트 이더넷(Gigabit Ethernet)을 지원하는지 확인하세요. 의외로 오래된 공유기나 스위치는 100Mbps까지만 지원하는 경우가 많으니까요. 10기가비트(10GbE) 환경이라면 더욱 신경 써야겠죠.
    3. NIC(네트워크 인터페이스 카드) 속도 확인:
      • TrueNAS/리눅스 기반 NAS: SSH로 접속하여 ethtool <인터페이스명> 명령어로 NIC 속도를 확인할 수 있어요. 예를 들어, ethtool enp0s25와 같이 입력해 보세요. “Speed: 1000Mb/s” 또는 “Speed: 10000Mb/s”가 나와야 합니다.
      • Synology NAS: DSM 웹 UI의 제어판(Control Panel) > 네트워크(Network) > 네트워크 인터페이스(Network Interface)에서 각 LAN 포트의 속도를 확인할 수 있습니다.
      • 클라이언트 PC (Windows): 작업 관리자(Task Manager) > 성능(Performance) 탭 > 이더넷(Ethernet)에서 연결 속도를 확인할 수 있어요.
    4. iperf3 테스트: NAS와 클라이언트 PC 간의 순수한 네트워크 대역폭(Bandwidth)을 측정하는 데 iperf3가 아주 유용합니다. 
      # NAS에서 서버 모드 실행 (터미널)
iperf3 -s

# 클라이언트 PC에서 테스트 (터미널)
# -c 뒤에는 NAS의 IP 주소를 입력합니다.
iperf3 -c 192.168.1.100 -P 4 # -P는 병렬 스트림 수

      이 테스트에서 기가비트 환경이라면 800-900Mbps 이상이 나와야 정상입니다. 만약 100Mbps 근처가 나온다면 네트워크 장비 중 어딘가에 병목이 있다는 뜻이죠.

    TrueNAS SMB 서비스의 고급 설정 화면 스크린샷

    TrueNAS SMB 서비스의 고급 설정 화면입니다. 여기서 다양한 옵션을 조정할 수 있습니다.

    2. NAS 하드웨어 및 디스크 I/O 점검

    네트워크가 이상 없다면, 이제 NAS 자체의 성능을 봐야 합니다.

    1. CPU 및 RAM 사용량: 대용량 파일 전송 중 NAS의 CPU와 RAM 사용량을 확인하세요.
      • TrueNAS: Web UI의 Dashboard나 htop 명령어로 확인할 수 있어요.
      • Synology NAS: DSM의 자원 모니터(Resource Monitor)에서 확인할 수 있습니다.

      만약 CPU 사용률이 100%에 가깝거나 RAM이 부족하여 스왑(Swap)이 발생한다면, 하드웨어 업그레이드를 고려해야 해요.

    2. 디스크 I/O 성능: NAS의 저장장치 자체의 읽기/쓰기 속도를 확인하는 것이 중요합니다.
      • TrueNAS (ZFS): zpool iostat -v 1 명령어로 ZFS 풀의 디스크별 I/O 통계를 실시간으로 확인할 수 있어요. 병목이 되는 디스크를 찾아낼 수 있으니까요.
      • Synology NAS: 자원 모니터에서 디스크 사용률 그래프를 확인합니다. 특정 디스크의 사용률이 지속적으로 높다면 그 디스크가 병목일 가능성이 있어요.
      • dd 명령어로 직접 디스크 속도 측정 (주의 필요): 파일 시스템에 직접 큰 파일을 쓰고 읽어보며 성능을 측정할 수 있습니다. 
        # 쓰기 속도 측정 (1GB 파일 생성)
dd if=/dev/zero of=/mnt/pool/testfile bs=1M count=1024 oflag=direct

# 읽기 속도 측정 (캐시 영향을 줄이기 위해)
sync; echo 3 > /proc/sys/vm/drop_caches
dd if=/mnt/pool/testfile of=/dev/null bs=1M

        ⚠️ dd 명령어는 잘못 사용하면 데이터 손실 위험이 있으니 주의하세요. oflag=direct 옵션으로 캐시 영향을 최소화할 수 있어요.

    3. SMB 서비스 설정 최적화

    네트워크와 하드웨어에 이상이 없다면, SMB 서비스 설정을 건드려볼 차례입니다. 여기서 제가 삽질을 꽤 했었죠.

    1. SMB 프로토콜 버전 조절:
      • TrueNAS: Services > SMB > Edit > Advanced Options에서 “Server Minimum Protocol”과 “Server Maximum Protocol”을 설정할 수 있어요. 구형 클라이언트와의 호환성을 위해 낮게 설정되어 있는 경우가 있는데, 최신 환경이라면 “SMB2” 또는 “SMB3”으로 올려주는 것이 좋습니다. (SMB1은 보안상 취약점이 많아 사용하지 않는 것을 권장해요.)
      • Synology NAS: 제어판 > 파일 서비스 > SMB/AFP/NFS > 고급 설정에서 “최소 SMB 프로토콜”과 “최대 SMB 프로토콜”을 설정할 수 있습니다. 마찬가지로 SMB2 또는 SMB3으로 설정하세요.

      저는 처음에 이 부분이 “SMB1″으로 되어 있어서 속도가 잘 안 나왔던 경험이 있어요. “SMB2″로 올리자마자 속도가 확 올라가더라고요! 🎉

    2. Jumbo Frames (점보 프레임) 설정 ⚠️:

      Jumbo Frames는 이더넷 프레임의 MTU(Maximum Transmission Unit, 최대 전송 단위) 크기를 기본값인 1500바이트보다 크게 설정하는 기술입니다. 프레임당 전송할 수 있는 데이터 양이 늘어나 네트워크 오버헤드를 줄여줄 수 있어요. 이론적으로는 속도 향상에 도움이 될 수 있죠.

      하지만 NAS, 스위치, 클라이언트 PC의 NIC 모두 Jumbo Frames를 동일하게 지원하고 설정해야만 효과를 볼 수 있어요. 어느 한쪽이라도 설정이 안 되어 있거나 다르게 설정되어 있으면 오히려 통신 오류나 속도 저하를 유발할 수 있습니다. 제가 이걸로 며칠 밤낮을 헤맸거든요… 반드시 모든 장비를 확인하고 일관된 MTU 값을 설정해야 해요. 일반적으로 9000이 많이 사용됩니다.

      • TrueNAS: Network > Interfaces > Edit > Advanced Options에서 “MTU” 값을 변경할 수 있어요.
      • Synology NAS: 제어판 > 네트워크 > 네트워크 인터페이스 > 편집 > IPv4 탭에서 “점보 프레임 활성화” 옵션을 체크하고 MTU 값을 설정할 수 있습니다.
      • 클라이언트 PC (Windows): 장치 관리자(Device Manager) > 네트워크 어댑터(Network Adapters) > 해당 NIC 속성(Properties) > 고급(Advanced) 탭에서 “Jumbo Frame” 또는 “Jumbo Packet” 옵션을 찾아 설정할 수 있어요.

      💡 팁: Jumbo Frames는 모든 환경에서 속도 향상을 보장하지 않으며, 오히려 문제를 일으킬 가능성도 높습니다. 섣불리 설정하기보다는 다른 방법들을 먼저 시도해보고, 그래도 속도 개선이 필요할 때 최후의 수단으로 고려하는 것이 좋습니다.

    4. 기타 고려 사항 및 트러블슈팅

    • 클라이언트 PC 측 문제: 클라이언트 PC의 네트워크 드라이버가 최신이 아니거나, 방화벽, 안티바이러스 프로그램이 SMB 통신을 방해할 수도 있어요. 잠시 비활성화하고 테스트해보는 것도 방법입니다.
    • 파일 시스템 최적화 (TrueNAS ZFS): TrueNAS의 ZFS는 ARC(Adaptive Replacement Cache)라는 강력한 캐싱 메커니즘을 가지고 있습니다. RAM이 충분하다면 ARC가 파일 I/O를 크게 가속할 수 있어요. 만약 TrueNAS의 RAM이 적다면 증설을 고려해볼 만합니다.
    • SSD 캐싱: 특히 TrueNAS 환경에서는 L2ARC(Level 2 Adaptive Replacement Cache)나 SLOG(Separate Log Device)용으로 SSD를 추가하여 디스크 I/O 성능을 극적으로 향상시킬 수 있어요. 특히 작은 파일이 많거나 동기 쓰기(Synchronous Write) 작업이 빈번할 때 효과적입니다.

    SMB 속도 개선 전후 파일 전송 속도 비교 그래프

    SMB 속도 개선 전후의 파일 전송 속도 비교 그래프입니다. 확연한 차이를 보입니다.

    ✅ 검증 및 결과 확인

    여러 가지 설정을 변경했다면, 반드시 속도 개선 여부를 확인해야 합니다. 제가 주로 사용하는 방법은 다음과 같아요.

    1. 대용량 파일 전송: 실제 수 GB 이상의 파일을 NAS와 클라이언트 PC 간에 복사해보면서 전송 속도를 측정합니다. Windows 탐색기나 macOS Finder에서 파일 복사 창을 통해 실시간 속도를 확인할 수 있거든요.
    2. 네트워크 모니터링 도구 활용:
      • Windows: 작업 관리자의 성능 탭(Performance Tab)에서 이더넷(Ethernet) 그래프를 보면 실시간 송수신 속도를 알 수 있어요.
      • macOS: 활동 모니터(Activity Monitor)의 네트워크 탭(Network Tab)에서 확인할 수 있습니다.
      • 리눅스/TrueNAS: nload, iftop 같은 툴을 사용하여 터미널에서 네트워크 트래픽을 실시간으로 모니터링할 수 있어요.
    3. iperf3 재측정: 설정 변경 후 iperf3를 다시 실행하여 네트워크 대역폭이 얼마나 향상되었는지 객관적인 수치로 확인합니다.

    이런 과정을 거쳐 드디어 만족스러운 속도를 얻었을 때의 쾌감이란… 정말 말로 표현할 수 없죠! 🎉 저도 여러 번의 시행착오 끝에 NAS 속도 개선에 성공했고, 그 경험이 지금의 블로그 글을 쓸 수 있게 해주었습니다.

    NAS SMB 속도 개선을 위한 핵심 체크리스트 요약 인포그래픽

    NAS SMB 속도 개선을 위해 점검해야 할 주요 항목들을 요약한 체크리스트 인포그래픽입니다.

    마무리하며: 삽질 경험이 결국 자산이 되죠

    오늘은 TrueNAS와 Synology NAS 환경에서 NAS SMB 속도 저하 문제를 진단하고 해결하는 과정을 상세히 살펴봤어요. 네트워크 장비부터 NAS 하드웨어, 그리고 SMB 서비스 설정까지, 여러 가지 요인이 복합적으로 작용할 수 있다는 것을 알 수 있었죠.

    결론적으로 NAS 속도 개선을 위해서는 체계적인 접근 방식이 중요합니다. 무턱대고 설정을 바꾸기보다는, 제가 알려드린 진단 방법을 통해 병목 지점을 정확히 파악하고 하나씩 해결해 나가는 것이 현명해요.

    저도 처음에는 “이게 왜 느리지?” 하면서 답답해하다가 여러 번의 파일 전송 문제 삽질 끝에 해결책을 찾았거든요. 여러분도 이 글을 통해 쾌적한 NAS 환경을 구축하는 데 도움이 되셨으면 좋겠습니다. 다음 글에서는 10기가비트 이더넷 환경 구축이나, 고급 ZFS 튜닝에 대해 다뤄볼 수도 있겠네요. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

  • [Nas] NAS RAID 구성 비교: Synology SHR vs TrueNAS ZFS RAID

    [Nas] NAS RAID 구성 비교: Synology SHR vs TrueNAS ZFS RAID

    목차

    데이터 보호의 시작: NAS RAID 구성, 왜 중요할까요?

    안녕하세요, 13년차 인프라 엔지니어입니다! 오랜만에 NAS 이야기를 좀 해보려고 해요. 저처럼 홈랩을 운영하거나 소중한 개인 데이터를 NAS(Network Attached Storage)에 저장해서 쓰시는 분들이라면, NAS RAID 구성 비교는 늘 뜨거운 감자일 겁니다. RAID(Redundant Array of Independent Disks)는 여러 개의 디스크를 묶어서 하나의 논리적인 저장 공간처럼 사용하고, 동시에 데이터의 안정성을 높이는 기술이거든요. 그런데 단순히 RAID 0, 1, 5, 6 같은 표준 RAID 레벨만 있는 게 아니라, NAS 벤더마다 자체적인 특수 RAID 구성이 있다는 사실, 알고 계셨나요? 오늘은 그중에서도 가장 인기 있는 두 가지, Synology의 SHR(Synology Hybrid RAID)과 TrueNAS의 ZFS RAID에 대해 제가 직접 써보고 겪었던 경험을 바탕으로 낱낱이 파헤쳐 보려고 합니다. 어떤 구성이 여러분의 소중한 데이터를 더 안전하고 효율적으로 지켜줄 수 있을지, 함께 고민해봅시다!

    NAS RAID 구성은 단순히 디스크를 묶는 것을 넘어, 데이터 안정성과 효율성을 동시에 잡는 핵심 기술입니다. 이 그림은 다양한 RAID 구성 방식이 데이터를 어떻게 보호하고 저장하는지 보여줍니다.

    Synology SHR vs TrueNAS ZFS RAID, 핵심 개념부터 알아볼까요?

    Synology SHR (Synology Hybrid RAID)

    Synology NAS를 써보신 분들이라면 아마 SHR(Synology Hybrid RAID)이라는 이름을 많이 보셨을 거예요. 처음엔 이게 뭔가 싶었는데, 쉽게 말해 Synology가 자체적으로 개발한 스마트한 RAID 관리 시스템입니다. 표준 RAID 레벨의 장점을 가져오면서도, 디스크 용량이 서로 다른 경우에도 공간 낭비를 최소화할 수 있도록 설계되었어요. 예를 들어, 4TB, 6TB, 8TB 디스크를 섞어 써도 효율적으로 사용할 수 있다는 거죠. 일반적인 RAID 5나 RAID 6처럼 동일 용량의 디스크가 강제되는 것에 비하면 정말 유연하더라고요.

    SHR은 기본적으로 하나의 디스크 장애를 허용하는 SHR-1과 두 개의 디스크 장애를 허용하는 SHR-2로 나뉩니다. 제가 홈랩에서 처음 Synology NAS를 구성할 때 이 유연성 덕분에 디스크 업그레이드가 정말 편했던 기억이 나네요. 💡 팁: SHR은 표준 RAID 1, 5, 6 등의 기술을 기반으로 작동하지만, Synology OS에서만 관리할 수 있는 독점 기술이라는 점을 꼭 기억해야 합니다.

    TrueNAS ZFS RAID (RAID-Z)

    다음은 TrueNAS에서 사용하는 ZFS RAID, 정확히는 ZFS 파일 시스템의 RAID-Z입니다. ZFS는 Sun Microsystems에서 개발한 고급 파일 시스템으로, 단순히 RAID 기능만 제공하는 게 아니라 볼륨 관리, 스냅샷, 데이터 무결성 검사 등 스토리지 관리에 필요한 모든 기능을 통합한 끝판왕이라고 할 수 있어요. TrueNAS는 이 ZFS를 기반으로 운영되는 오픈소스 NAS 솔루션입니다.

    RAID-Z는 ZFS의 핵심 기능 중 하나로, 표준 RAID 5, 6과 유사하지만 몇 가지 중요한 차이가 있습니다. Copy-on-Write 기술 덕분에 데이터 손실 위험이 적고, Checksum(체크섬)을 통해 데이터 무결성을 상시 검사해서 Bit Rot(비트 로트, 데이터 부패) 같은 현상으로부터 데이터를 강력하게 보호해줍니다. 제가 TrueNAS를 처음 접했을 때, 이 ZFS의 강력한 기능들에 정말 감탄했었죠. 특히 Self-Healing(자가 복구) 기능은 정말 든든하더라고요.

    RAID-Z1은 디스크 1개, RAID-Z2는 2개, RAID-Z3는 3개까지 디스크 장애를 허용합니다. vDev(Virtual Device)라는 개념으로 스토리지 풀을 구성하는데, 이 vDev 단위로 확장하거나 디스크를 교체하는 방식이 처음엔 좀 낯설었지만, 익숙해지니 정말 강력했습니다.

    실전 구성 선택: 나에게 맞는 RAID 레벨은?

    이제 두 시스템의 핵심 개념을 알았으니, 실제 환경에서 어떤 선택을 해야 할지 고민해볼 차례입니다. 제가 13년간 다양한 환경에서 NAS를 써보면서 느낀 점들을 바탕으로 몇 가지 가이드를 드려볼게요.

    Synology SHR 구성 시 고려사항

    Synology NAS는 처음 NAS를 접하는 분들이나, 저처럼 홈랩에서 편의성과 유연한 디스크 확장을 중요하게 생각하는 분들에게 정말 좋은 선택지입니다.

    • 장점:
      • 쉬운 관리: 직관적인 GUI(Graphical User Interface) 덕분에 몇 번의 클릭만으로 RAID 구성 및 볼륨 관리가 가능해요. 저도 처음엔 설명서 없이 그냥 눌러보다가 쉽게 구성했었으니까요.
      • 유연한 디스크 확장: 용량이 다른 디스크를 섞어 쓸 수 있어, 나중에 디스크를 추가하거나 업그레이드할 때 공간 낭비가 적습니다.
      • 높은 접근성: DSM(DiskStation Manager)이라는 운영체제가 워낙 잘 되어 있어서, 다양한 앱과 기능을 쉽게 활용할 수 있어요.
    • 단점:
      • 독점 기술: SHR은 Synology NAS에서만 작동합니다. 만약 Synology NAS가 고장 나서 다른 제조사 NAS로 옮겨야 한다면, 데이터 복구가 복잡해질 수 있어요. 이 부분이 사실 좀 아쉽죠.
      • 성능: ZFS에 비해 고급 데이터 무결성 기능은 부족합니다. 일반적인 사용에는 문제가 없지만, 미션 크리티컬한 환경에서는 고민이 될 수 있어요.

    TrueNAS ZFS RAID (RAID-Z) 구성 시 고려사항

    TrueNAS는 데이터 무결성과 강력한 스토리지 기능에 최우선을 두는 분들에게 적합한 솔루션입니다. 특히 서버 환경이나 엔터프라이즈급 데이터 보호가 필요한 경우에 빛을 발하죠.

    • 장점:
      • 최강의 데이터 무결성: Copy-on-Write, Checksum, Self-Healing 등 ZFS의 강력한 기능 덕분에 Bit Rot으로부터 데이터를 효과적으로 보호해요. 제가 직접 중요한 데이터를 백업할 때 이 부분이 정말 든든하더라고요.
      • 스냅샷/복제: 정교한 스냅샷 기능을 통해 특정 시점의 데이터를 보존하고, 원격으로 복제하여 재해 복구(DR) 솔루션으로도 활용할 수 있습니다.
      • 오픈소스: 커뮤니티 지원이 활발하고, 특정 벤더에 종속되지 않는다는 장점이 있어요.
    • 단점:
      • 높은 러닝 커브: ZFS의 개념(vDev, Pool, Dataset 등)이 처음엔 좀 어려울 수 있습니다. 저도 처음엔 삽질 좀 했습니다 ㅎㅎ.
      • 디스크 확장 제한: 일단 vDev를 구성하면, 해당 vDev에 디스크를 추가하여 용량을 늘리기가 어렵습니다. 기존 vDev의 모든 디스크를 더 큰 용량으로 교체해야 하거나, 새로운 vDev를 추가해야 해요. 이 부분이 SHR에 비해 유연성이 떨어지는 지점이죠.
      • 메모리 요구사항: ZFS는 안정적인 성능을 위해 충분한 RAM(메모리)을 요구합니다. 일반적으로 스토리지 1TB당 1GB의 RAM을 권장하거든요. 저렴하게 구성하려다 이 부분에서 막히는 경우가 꽤 있었어요.

    Synology SHR은 용량이 다른 디스크도 효율적으로 활용하며 유연하게 확장할 수 있는 반면, TrueNAS ZFS RAID는 강력한 데이터 무결성을 제공하지만 디스크 확장에는 제약이 따릅니다. 이 다이어그램은 각 시스템의 디스크 구성 방식을 시각적으로 보여줍니다.

    ⚠️ 제가 겪었던 삽질과 해결 과정: 이것만은 꼭 알아두세요!

    제가 직접 경험했던 몇 가지 삽질과 해결 팁을 공유해 드릴게요. 여러분은 저 같은 실수 하지 마시라고요! ㅎㅎ

    1. ZFS RAID-Z 구성 시 초기 디스크 선택의 중요성

    TrueNAS에서 RAID-Z를 구성할 때, 처음부터 계획을 잘 세우지 않으면 나중에 후회할 수 있습니다. 제가 처음에는 4TB 디스크 3개로 RAID-Z1을 만들었는데, 나중에 용량이 부족해서 8TB 디스크 2개를 추가하려고 했더니 기존 vDev에 바로 추가할 수가 없더라고요. 결국 8TB 디스크로만 새로운 vDev를 만들거나, 기존 4TB 디스크들을 8TB로 전부 교체해야 하는 상황에 직면했습니다.

    결론: ZFS는 vDev 구성 시 디스크 용량과 개수를 신중하게 결정해야 합니다. 나중에 확장성을 고려한다면, 처음부터 동일 용량의 디스크로 여러 개의 vDev를 만들거나, 통 크게 한 번에 큰 용량으로 시작하는 게 좋아요.

    2. Synology SHR에서 디스크 교체 시 주의점

    Synology SHR은 디스크 교체가 유연하다고 했잖아요? 그런데 여기서 한 가지 주의할 점이 있습니다. 예를 들어, 4TB 디스크 4개로 SHR-1을 구성했는데, 4TB 하나가 고장 나서 6TB 디스크로 교체했다고 가정해봅시다. 그럼 남은 3개의 4TB 디스크 때문에 실제 가용 용량은 여전히 4TB 기준으로 계산됩니다. 교체한 6TB 디스크의 추가 용량을 사용하려면, 다른 4TB 디스크들도 6TB 이상으로 교체해야만 해요.

    즉, 가장 작은 용량의 디스크가 전체 볼륨 용량에 영향을 미친다는 거죠. 저는 처음에 6TB 넣으면 바로 용량이 늘어날 줄 알고 신났다가, ‘어라? 왜 안 늘어나지?’ 하고 한참 헤맸던 기억이 있습니다. 결국 모든 디스크를 6TB 이상으로 교체하고 나서야 용량이 늘어나더라고요.

    3. RAM 부족이 ZFS 성능에 미치는 영향

    TrueNAS ZFS를 사용하면서 가장 많이 겪는 문제 중 하나가 바로 RAM 부족입니다. 제가 초기에 저렴한 하드웨어로 TrueNAS를 구성하면서 4GB RAM만 사용했었는데, 스냅샷이 많아지거나 대용량 파일 전송 시 시스템이 버벅거리는 현상을 겪었어요. ZFS는 디스크 캐싱(ARC, L2ARC)과 데이터 무결성 검사 등 다양한 작업을 위해 RAM을 적극적으로 활용하거든요.

    그래서 TrueNAS 공식 문서에서는 최소 8GB, 그리고 스토리지 1TB당 1GB RAM을 권장합니다. 저도 나중에 RAM을 16GB로 업그레이드하고 나서야 훨씬 쾌적하게 사용할 수 있었어요. ZFS는 RAM 넉넉하게! 이게 핵심입니다.

    그래서, 어떤 RAID 구성이 저에게 딱 맞을까요?

    결국, Synology SHR과 TrueNAS ZFS RAID 중 어떤 것을 선택할지는 여러분의 우선순위와 사용 환경에 따라 달라집니다. 제가 경험한 바를 바탕으로 간단히 정리해 드릴게요.

    특징 Synology SHR TrueNAS ZFS RAID
    운영체제 DSM TrueNAS CORE/SCALE (ZFS)
    주요 장점 쉬운 사용성, 유연한 디스크 확장 강력한 데이터 무결성, 스냅샷/복제
    주요 단점 독점 기술, 고급 기능 부족 높은 러닝 커브, 디스크 확장 제약, RAM 요구사항
    추천 사용자 NAS 초보자, 유연한 디스크 확장 원하는 홈랩 사용자 데이터 무결성 최우선 사용자, 고급 스토리지 기능 원하는 전문가/기업
    주요 RAID 레벨 SHR-1 (1개 장애 허용), SHR-2 (2개 장애 허용) RAID-Z1 (1개 장애 허용), RAID-Z2 (2개 장애 허용), RAID-Z3 (3개 장애 허용)

    Synology DSM과 TrueNAS GUI는 각기 다른 방식으로 스토리지 상태와 RAID 구성 정보를 시각적으로 보여줍니다. 이 이미지는 각 시스템의 대시보드를 통해 현재 볼륨 상태와 디스크 건강도를 확인하는 모습을 담고 있어요.

    마무리하며: 여러분의 데이터, 어떻게 지키실 건가요?

    오늘은 Synology SHR과 TrueNAS ZFS RAID라는 두 가지 강력한 NAS RAID 구성 방식에 대해 비교해봤습니다. 저의 13년차 인프라 엔지니어 경험을 바탕으로 솔직한 사용기와 삽질 경험을 공유해 드렸는데, 도움이 되셨으면 좋겠네요.

    • Synology SHR: 편의성과 유연한 확장성을 최우선으로 생각하고, 직관적인 GUI로 쉽게 NAS RAID 구성을 운영하고 싶은 분들에게 강력 추천합니다.
    • TrueNAS ZFS RAID: 최고 수준의 데이터 무결성과 고급 스토리지 기능이 필요하며, 어느 정도 학습 곡선을 감수하더라도 안정적인 데이터 보호를 원하는 분들에게 적합합니다.

    결국 정답은 없습니다. 여러분의 예산, 기술 수준, 그리고 무엇보다 데이터의 중요도에 따라 최적의 선택은 달라질 수 있어요. 어떤 선택을 하시든, 중요한 건 데이터 백업을 생활화하는 것입니다! RAID는 데이터 유실의 위험을 줄여주지만, 절대 백업을 대체할 수는 없다는 점, 잊지 마세요!

    다음번에는 각 시스템에서 스냅샷 기능을 활용하는 방법이나, 외부 클라우드로 백업하는 전략에 대해 더 깊이 다뤄볼까 합니다. 혹시 궁금한 점이나 여러분의 경험담이 있다면 댓글로 남겨주세요! 저도 많이 배우고 싶습니다. 감사합니다!

    이 인포그래픽은 Synology SHR과 TrueNAS ZFS RAID의 핵심적인 장점과 단점을 한눈에 비교하여, 사용자의 NAS RAID 구성 선택에 실질적인 도움을 줄 수 있도록 디자인되었습니다.

  • [Nas] TrueNAS CORE vs SCALE: 홈랩 및 소규모 비즈니스 NAS 선택 가이드

    [Nas] TrueNAS CORE vs SCALE: 홈랩 및 소규모 비즈니스 NAS 선택 가이드

    목차

    안녕하세요, 13년차 서버실입니다.

    홈랩 운영하시는 분들이나 소규모 비즈니스를 위한 NAS를 고민하시는 분들이라면 한 번쯤 TrueNAS라는 이름을 들어보셨을 거예요. 저도 처음엔 단순히 ‘FreeNAS’ 시절부터 쭉 써왔던 터라 익숙한 이름이었는데, 어느새 TrueNAS CORE와 TrueNAS SCALE이라는 두 가지 버전으로 나뉘어 있더라고요. ‘도대체 뭘 선택해야 하지?’ 저도 꽤 고민하고 삽질 좀 했거든요. 그래서 오늘은 제가 직접 경험한 것을 바탕으로 TrueNAS CORE vs SCALE의 차이점과 여러분의 환경에 맞는 선택 가이드를 알려드릴게요. 이 글이 여러분의 현명한 TrueNAS 선택에 도움이 되길 바라요.

    TrueNAS, CORE와 SCALE 개념 이해하기

    TrueNAS는 FreeBSD 기반의 TrueNAS CORE와 Linux 기반의 TrueNAS SCALE로 나뉩니다. 둘 다 ZFS 파일 시스템을 기반으로 안정적인 데이터 저장과 관리 기능을 제공하는 NAS 운영체제(OS)죠. 쉽게 말해, 여러분의 하드웨어를 강력한 네트워크 스토리지 서버로 만들어주는 소프트웨어라고 생각하면 돼요. TrueNAS CORE는 전통적인 NAS 기능에 충실하고, TrueNAS SCALE은 여기에 컨테이너(Container)와 가상 머신(Virtual Machine, VM) 기능을 더해 확장성을 높인 버전이라고 보면 돼요. 사실상 NAS OS 비교의 핵심이죠.

    TrueNAS CORE 깊이 보기: 전통의 강자

    TrueNAS CORE는 오랫동안 FreeNAS라는 이름으로 사랑받아온 전통적인 버전입니다. FreeBSD 운영체제를 기반으로 하고 있죠.

    장점:

    • 안정성(Stability): FreeBSD 기반이라 굉장히 안정적이에요. 오랜 기간 검증된 만큼 데이터 안정성을 최우선으로 생각한다면 이만한 게 없어요. 제가 홈랩에서 10년 넘게 굴려봤는데, 정말 든든하더라고요.
    • 성숙한 기능(Mature Features): ZFS 파일 시스템, 다양한 프로토콜(SMB, NFS, iSCSI, FTP 등), 플러그인(Plugins) 기반의 추가 기능 등 NAS에 필요한 모든 기능이 완벽하게 구현되어 있어요.
    • 낮은 리소스 요구량(Lower Resource Footprint): SCALE에 비해 상대적으로 낮은 하드웨어 사양에서도 좋은 성능을 보여줘요. 특히 오래된 하드웨어로 NAS를 구축하려는 분들께는 아주 매력적인 선택지죠.

    단점:

    • 확장성 제한(Limited Extensibility): 플러그인 외에는 추가 기능을 확장하기가 쉽지 않아요. Docker 컨테이너나 가상 머신을 직접 구동하기 어렵다는 점이 가장 큰 단점이에요.
    • 상대적으로 적은 커뮤니티 자료(Smaller Community for Advanced Features): 전통적인 NAS 기능에는 자료가 많지만, 최신 개발 환경을 위한 자료는 SCALE에 비해 적은 편이에요.

    간단히 말해, ‘나는 그냥 튼튼한 데이터 저장소가 필요하고, 부가 기능은 크게 중요하지 않다!’ 하시는 분들께 CORE는 최고의 선택이 될 거예요. 제가 처음에 홈랩을 구성할 때도 CORE를 썼는데, 정말 별 탈 없이 잘 썼거든요. 안정성 하나는 끝내줍니다. ✅

    TrueNAS SCALE 깊이 보기: 미래 지향적인 올인원

    자, 다음은 요즘 핫한 TrueNAS SCALE입니다. CORE와 달리 Linux 기반(Debian)으로 만들어졌어요. 여기서 큰 차이가 발생하죠.

    장점:

    • 컨테이너 및 가상화 지원(Container & Virtualization Support): Docker 컨테이너와 Kubernetes(쿠버네티스)를 통한 앱 배포, KVM 기반의 가상 머신을 직접 구동할 수 있다는 점이 가장 큰 장점이에요. 홈랩에서 다양한 서비스를 한 번에 돌리고 싶을 때 정말 강력해요. 제가 Nextcloud, Plex, Home Assistant 등을 전부 SCALE 위에서 컨테이너로 돌리고 있는데, 관리도 편하고 성능도 아주 만족스러워요. 🎉
    • 확장성(Scalability): 기존 CORE보다 훨씬 유연하게 기능을 확장할 수 있어요. 특히 TrueCharts 같은 커뮤니티 앱 스토어를 통해 수많은 앱을 쉽게 설치하고 관리할 수 있죠.
    • 클러스터링(Clustering) 가능: 여러 TrueNAS SCALE 서버를 묶어 스케일-아웃(Scale-out) 스토리지를 구축할 수 있어요. 소규모 비즈니스 환경에서 나중에 확장을 고려한다면 이 기능이 정말 중요할 수 있죠.

    단점:

    • 상대적으로 높은 리소스 요구량(Higher Resource Footprint): Linux 커널과 컨테이너 환경 때문에 CORE보다 더 많은 RAM과 CPU 리소스가 필요해요. 오래된 하드웨어에서는 버벅일 수 있죠.
    • 새로운 기능의 안정성(New Features Stability): CORE에 비해 역사가 짧기 때문에, 새로운 기능들이 아직 완벽하게 안정화되지 않았을 가능성도 있어요. 물론 지금은 많이 안정화되었지만, 초기에는 잔버그도 좀 있었거든요. 삽질 좀 했습니다 ㅎㅎ
    • 복잡성(Complexity): 컨테이너, VM, Kubernetes 등 다룰 수 있는 기능이 많아지면서 CORE에 비해 학습 곡선이 가파를 수 있어요. 초보자에게는 좀 어렵게 느껴질 수도 있죠.

    SCALE은 ‘나는 NAS 기능뿐만 아니라, 홈 서버나 개발 서버 역할까지 한 번에 다 하고 싶다!’ 하시는 분들을 위한 올인원(All-in-one) 솔루션이라고 보면 돼요. 저도 결국 SCALE로 넘어왔는데, 정말 만족하면서 쓰고 있어요. 💡

    TrueNAS CORE와 SCALE의 핵심 차이점을 한눈에 볼 수 있는 아키텍처 비교 다이어그램입니다.

    홈랩 사용자를 위한 TrueNAS 선택 가이드

    이제 여러분의 상황에 맞춰 어떤 TrueNAS를 선택해야 할지 고민해볼 시간이에요. 먼저 홈랩(Homelab) 환경부터 살펴볼까요?

    TrueNAS CORE를 추천하는 경우:

    • 안정적인 파일 서버가 최우선: 오직 데이터 저장과 공유 기능만 필요하고, 안정성이 가장 중요하다고 생각한다면 CORE가 좋아요.
    • 하드웨어 리소스가 제한적: 오래된 PC나 저사양 서버를 쓸 계획이라면 CORE가 리소스를 덜 먹어서 효율적이에요.
    • NAS 기능 외의 복잡한 설정은 피하고 싶다: Docker나 VM에 대한 지식이 없거나, 굳이 배우고 싶지 않다면 CORE가 훨씬 직관적이에요.

    TrueNAS SCALE을 추천하는 경우:

    • NAS 외에 다양한 서비스를 한 서버에서 운영하고 싶다: Plex 미디어 서버, Nextcloud 개인 클라우드, Home Assistant 스마트 홈 허브 등 다양한 애플리케이션을 컨테이너로 돌리고 싶다면 SCALE이 압도적으로 유리해요.
    • 가상 머신(VM)을 활용할 계획: 윈도우나 리눅스 VM을 TrueNAS 위에서 구동하고 싶다면 KVM을 지원하는 SCALE이 유일한 선택지에요.
    • 새로운 기술과 확장성에 관심이 많다: Docker, Kubernetes 같은 최신 기술을 홈랩에서 직접 경험해보고 싶다면 SCALE이 제격이에요. 저도 이 점 때문에 SCALE로 넘어왔죠!

    홈랩에서 TrueNAS CORE와 SCALE을 어떻게 활용할 수 있는지 보여주는 인포그래픽입니다.

    소규모 비즈니스 사용자를 위한 TrueNAS 선택 가이드

    그럼 소규모 비즈니스(Small Business) 환경에서는 어떨까요? 여기서는 안정성과 확장성, 그리고 관리의 용이성이 더욱 중요해져요.

    TrueNAS CORE를 추천하는 경우:

    • 주요 목적이 파일 서버 및 백업: 직원 간 파일 공유, 중요 데이터 백업 등 기본적인 NAS 기능이 핵심이라면 CORE의 검증된 안정성이 큰 장점이에요.
    • IT 인력이 제한적: 복잡한 컨테이너 환경 관리 부담 없이, 안정적인 스토리지만 운영하고 싶을 때 CORE가 더 적합할 수 있어요.
    • 비용 효율성: 초기 하드웨어 투자 비용을 절감하고 싶을 때, CORE는 낮은 사양에서도 충분한 성능을 제공해요.

    TrueNAS SCALE을 추천하는 경우:

    • 내부 서비스(Internal Services) 확장 계획: 사내 Git 서버, 프로젝트 관리 툴, CI/CD 파이프라인 등 다양한 내부 서비스를 NAS 위에서 통합 운영하고 싶다면 SCALE이 효율적이에요.
    • 미래 확장성을 고려: 향후 데이터 증가나 서비스 확장에 대비하여 스케일-아웃(Scale-out) 클러스터링을 염두에 둔다면 SCALE이 유리해요.
    • 가상화 환경 통합: 기존에 운영 중인 가상화 환경(VMware, Proxmox 등)에 TrueNAS를 통합하거나, TrueNAS 자체에서 VM을 구동해야 한다면 SCALE이 답이에요.

    사실 소규모 비즈니스에서도 ‘무조건 CORE가 좋다’ 또는 ‘무조건 SCALE이 좋다’고 말하기는 어려워요. 비즈니스의 특성과 미래 계획에 따라 신중하게 선택해야 하거든요. 저도 컨설팅을 진행할 때 항상 고객사의 상황을 먼저 파악해요. ⚠️

    주의사항 및 삽질 경험 공유

    제가 직접 TrueNAS를 사용하면서 겪었던 몇 가지 삽질 경험과 주의사항을 공유해 드릴게요.

    1. 하드웨어 요구사항:
      특히 TrueNAS SCALE은 CORE보다 RAM과 CPU를 더 많이 써요. 제가 처음엔 CORE 쓰던 서버에 그냥 SCALE을 올렸다가 버벅이는 경험을 했거든요. 특히 Docker 컨테이너나 VM을 많이 돌릴 계획이라면 최소 16GB RAM (개인적으로는 32GB 이상 권장)과 멀티코어 CPU는 필수라고 생각해요. 저도 결국 RAM 업그레이드를 했더니 훨씬 쾌적해졌어요.
    2. 마이그레이션(Migration) 고려:
      만약 기존에 TrueNAS CORE를 쓰고 계시다가 SCALE로 넘어가고 싶으시다면, 데이터 백업은 필수에요. CORE에서 SCALE로의 직접적인 인플레이스(In-place) 업그레이드는 가능하지만, 항상 예기치 않은 문제가 발생할 수 있거든요. 저도 괜히 한번 믿었다가 데이터 날릴 뻔했어요… 😱 꼭 백업하시고, 가능하다면 새로운 하드웨어에 SCALE을 새로 설치하고 데이터를 옮기는 걸 추천해요.
    3. ZFS 설정의 중요성:
      TrueNAS의 핵심은 ZFS에요. 풀(Pool) 구성, 데이터셋(Dataset) 설정, 스냅샷(Snapshot) 주기 등을 처음부터 잘 계획해야 나중에 후회하지 않아요. 특히 스냅샷은 랜섬웨어(Ransomware) 같은 위협으로부터 데이터를 보호하는 데 정말 중요하니까요. 저도 예전에 한번 실수로 중요한 데이터를 지운 적이 있었는데, 스냅샷 덕분에 살린 경험이 있어요. 💡

    TrueNAS CORE에서 SCALE로 안전하게 마이그레이션하는 과정을 보여주는 흐름도입니다.

    두 버전 한눈에 비교하기

    두 버전을 한눈에 비교할 수 있도록 표로 정리해 봤어요.

    구분 TrueNAS CORE TrueNAS SCALE
    기반 OS FreeBSD Debian Linux
    주요 기능 안정적인 NAS (ZFS, SMB, NFS, iSCSI, 플러그인) NAS + 컨테이너 (Docker, Kubernetes) + 가상 머신 (KVM)
    주요 용도 순수 파일 서버, 데이터 백업, 고신뢰성 스토리지 올인원 홈 서버, 개발 환경, 클러스터링 스토리지
    하드웨어 요구사항 상대적으로 낮음 (8GB RAM 권장) 상대적으로 높음 (16GB RAM 이상 권장)
    확장성 플러그인 위주, 제한적 컨테이너 앱, VM, 클러스터링으로 유연하게 확장
    학습 곡선 쉬운 편 상대적으로 가파름

    TrueNAS CORE와 SCALE의 주요 특징을 비교한 표를 시각적으로 보여주는 차트입니다.

    마무리: 당신의 TrueNAS는?

    오늘은 TrueNAS CORE와 SCALE 중에서 어떤 것을 선택해야 할지, 제 13년차 인프라 엔지니어 경험을 바탕으로 이야기해 봤어요.

    결론적으로 말씀드리면, ‘정답은 없다!’ 이에요.

    • 안정적인 파일 저장 기능만 필요하고, 하드웨어 사양이 낮다면 TrueNAS CORE.
    • 다양한 컨테이너 앱이나 가상 머신을 돌리고 싶고, 충분한 하드웨어 리소스가 있다면 TrueNAS SCALE.

    이렇게 정리할 수 있을 것 같아요.

    어떤 버전을 선택하시든, TrueNAS는 강력한 NAS 솔루션임에는 틀림없어요. 여러분의 환경과 목적에 맞는 최적의 선택을 하시길 바라면서, 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 다음번에는 TrueNAS SCALE에서 Docker 컨테이너를 활용하는 방법에 대해 더 자세히 다뤄볼까 합니다. 기대해주세요! 😄

  • [HomeLabs] 홈랩 NAS OS 비교: TrueNAS, Unraid, OpenMediaVault 선택 가이드

    목차

    NAS OS, 뭘 골라야 할지 모르겠다면 — 이 글이 딱입니다

    홈랩을 처음 시작하거나, 기존 홈서버를 업그레이드하려고 할 때 가장 먼저 맞닥뜨리는 고민이 있죠. 바로 “NAS OS를 뭘 써야 하지?”라는 질문입니다.

    저도 딱 그랬거든요. 13년 전에 처음 홈랩을 꾸릴 때, 지금처럼 선택지가 많지 않았는데도 뭘 써야 할지 한참 고민했었습니다. 지금은 오히려 선택지가 너무 많아서 더 헷갈리는 상황이 됐더라고요. 홈랩 NAS OS 비교를 제대로 해놓은 한국어 글이 정말 드물어서, 제가 직접 써봤던 경험을 토대로 정리해 드리려고 합니다.

    오늘 다룰 세 가지는 TrueNAS, Unraid, OpenMediaVault(OMV)입니다. 이 셋이 현재 홈서버 커뮤니티에서 가장 널리 쓰이는 NAS 전용 OS들이에요. 각각 철학도 다르고, 강점도 다르고, 적합한 사용자 유형도 다릅니다. 끝까지 읽으시면 본인 상황에 맞는 선택이 보일 거예요.

    TrueNAS, Unraid, OpenMediaVault — 홈랩 NAS OS 3대장의 구조와 특성을 한눈에 비교한 다이어그램

    먼저 알아야 할 개념들 — NAS OS가 뭐가 다른 거야?

    일반 OS(Ubuntu, Windows)에 Samba나 NFS 서버를 올려도 NAS는 됩니다. 근데 왜 굳이 NAS 전용 OS를 쓰냐고요? 쉽게 말해서, 파일 서버에 특화된 기능들이 처음부터 내장되어 있기 때문입니다.

    • 스토리지 풀(Storage Pool): 여러 개의 디스크를 하나의 논리적 공간으로 묶는 기능
    • RAID / 패리티(Parity): 디스크 장애 시 데이터를 보호하는 기술
    • 스냅샷(Snapshot): 특정 시점의 파일 시스템 상태를 저장해두는 기능
    • SMB / NFS / AFP 공유: Windows, Linux, macOS와 파일을 주고받는 프로토콜
    • WebUI: 터미널 없이 웹 브라우저로 관리하는 인터페이스

    이런 것들을 일반 OS에서 직접 구성하려면 시간이 꽤 걸리는데, NAS OS는 이걸 다 묶어서 제공해 줍니다. 물론 각 OS마다 접근 방식이 완전히 다르거든요. 그게 핵심 차이입니다.

    TrueNAS — 기업급 신뢰성을 홈랩에

    TrueNAS가 뭔지 간단히

    TrueNAS는 iXsystems라는 회사에서 만든 오픈소스 NAS OS입니다. 예전에 FreeNAS라는 이름으로 불렸는데, 2020년에 TrueNAS CORE(FreeBSD 기반)와 TrueNAS SCALE(Linux/Debian 기반)로 분리됐어요.

    • TrueNAS CORE: FreeBSD 기반, ZFS 파일시스템, 오랜 역사와 안정성
    • TrueNAS SCALE: Linux(Debian) 기반, ZFS + 쿠버네티스(Kubernetes) 앱 지원

    핵심은 ZFS(제트파일시스템)입니다. ZFS는 데이터 무결성 검증, 스냅샷, 압축, 중복 제거 등 엔터프라이즈급 기능을 모두 갖춘 파일시스템이에요. 실제로 기업 스토리지에서도 쓰이는 기술이거든요.

    직접 써본 느낌

    제가 처음 TrueNAS CORE를 설치했을 때, 솔직히 WebUI가 좀 무겁다는 느낌을 받았습니다. 근데 한 번 익숙해지니까 이게 진짜 탄탄하더라고요. ZFS 풀을 구성하고 스냅샷 자동화 설정해두면, 데이터 보호 측면에서는 진짜 안심이 됩니다. 실제로 디스크 하나가 죽었을 때 데이터 손실 없이 교체한 경험이 있어요. 그때 TrueNAS 믿음이 생겼습니다 ㅎㅎ.

    TrueNAS 장단점

    • ✅ ZFS의 강력한 데이터 무결성 보호
    • ✅ 스냅샷, 복제(Replication) 기능이 훌륭함
    • ✅ 기업급 안정성, 오랜 커뮤니티
    • ✅ SCALE 버전은 Docker/쿠버네티스 앱 지원
    • ⚠️ ZFS 특성상 ECC 메모리 권장 (없어도 쓸 수는 있지만…)
    • ⚠️ RAM을 꽤 먹음 — ZFS ARC 캐시가 메모리를 적극 활용함
    • ⚠️ 디스크를 나중에 개별로 추가하기가 까다로움 (풀 단위로 관리)
    • ⚠️ 초보자에게는 진입 장벽이 있음

    이런 분께 추천

    데이터 보호를 최우선으로 생각하시는 분, 스냅샷과 복제를 활용한 백업 체계를 구축하고 싶은 분, 그리고 서버 하드웨어에 투자할 여유가 있는 분께 딱 맞습니다.

    Unraid — 유연함의 끝판왕

    Unraid는 왜 독특한가

    Unraid는 Lime Technology라는 회사의 상용 소프트웨어입니다. 무료가 아니에요 — 라이선스 구매가 필요합니다. 근데 홈랩 커뮤니티에서 엄청난 인기를 끌고 있는 이유가 있습니다.

    Unraid의 핵심 철학은 “다른 크기의 디스크를 자유롭게 섞어 쓸 수 있다”는 겁니다. 일반 RAID는 같은 크기의 디스크로 묶어야 하는데, Unraid는 그냥 디스크를 하나씩 배열(Array)에 추가하면 돼요. 4TB 하나, 8TB 하나, 12TB 하나 — 이렇게 섞어도 됩니다. 패리티(Parity) 디스크가 보호해주는 구조거든요.

    그리고 Docker 컨테이너와 VM(가상머신) 지원이 정말 잘 되어 있어요. Community Applications(CA)라는 앱 스토어 개념이 있어서, 클릭 몇 번으로 Plex, Jellyfin, Home Assistant 같은 앱을 설치할 수 있습니다. 처음 써봤을 때 “이거 진짜 편하다”는 생각이 절로 들더라고요.

    Unraid의 WebUI — 디스크 배열(Array), Docker 컨테이너, VM을 하나의 인터페이스에서 관리할 수 있다

    Unraid 장단점

    • ✅ 다른 크기의 디스크를 자유롭게 혼합 가능
    • ✅ 디스크 개별 추가/제거가 매우 유연함
    • ✅ Docker + VM 지원이 홈랩에 최적화
    • ✅ Community Applications(커뮤니티 앱 스토어)로 앱 설치 간편
    • ✅ WebUI가 직관적이고 초보자도 접근하기 쉬움
    • ⚠️ 유료 라이선스 필요 (USB 기반 라이선스 구조)
    • ⚠️ 배열 디스크가 개별 파일시스템(XFS/BTRFS)으로 관리됨 — ZFS 같은 통합 무결성 검증 없음
    • ⚠️ 패리티 검사(Parity Check) 중에는 성능이 떨어짐
    • ⚠️ 오픈소스가 아님

    이런 분께 추천

    다양한 크기의 디스크를 점진적으로 추가하며 스토리지를 늘리고 싶은 분, NAS + 미디어 서버 + 홈 자동화를 한 박스에서 다 해결하고 싶은 분, 그리고 설정의 편의성을 중요하게 생각하는 분께 강력 추천합니다.

    OpenMediaVault — 가볍고 오픈소스, 입문자의 친구

    OMV는 어떤 OS인가

    OpenMediaVault(이하 OMV)는 Debian Linux 기반의 완전 오픈소스 NAS OS입니다. 무료예요. FreeNAS(현 TrueNAS)의 초기 개발자 중 한 명이 만든 프로젝트라는 배경이 있습니다.

    OMV의 가장 큰 특징은 가볍다는 겁니다. 라즈베리 파이(Raspberry Pi)에도 설치할 수 있어요. 실제로 홈랩 입문자들이 라즈베리 파이 4에 OMV를 올려서 간단한 파일 서버를 구축하는 사례가 많습니다. 저도 테스트용으로 Pi에 올려봤는데, 설치 자체는 정말 간단하더라고요.

    플러그인(Plugin) 시스템으로 기능을 확장하는 구조입니다. OMV-Extras라는 서드파티 플러그인 저장소를 추가하면 Docker(Portainer), ZFS, 다양한 기능들을 추가할 수 있어요.

    OMV 장단점

    • ✅ 완전 무료 오픈소스
    • ✅ 저사양 하드웨어에서도 동작 (라즈베리 파이 포함)
    • ✅ Debian 기반이라 Linux 친숙한 분들에게 편함
    • ✅ 플러그인으로 기능 확장 가능
    • ✅ 기본 NAS 기능(SMB, NFS, FTP, rsync)은 충실하게 지원
    • ⚠️ 고급 스토리지 기능(ZFS 등)은 플러그인으로 추가해야 함
    • ⚠️ Unraid나 TrueNAS에 비해 커뮤니티 규모가 작음
    • ⚠️ Docker 환경 구성이 다른 OS에 비해 번거로울 수 있음
    • ⚠️ 대규모 스토리지 환경에는 적합하지 않을 수 있음

    이런 분께 추천

    예산이 빠듯한 입문자, 라즈베리 파이나 구형 PC를 활용하고 싶은 분, 단순 파일 공유 서버로만 쓸 분께 딱입니다. Linux를 어느 정도 다뤄본 분이라면 더욱 편하게 쓸 수 있어요.

    세 OS 한눈에 비교 — 어디서 뭐가 다른지

    TrueNAS vs Unraid vs OpenMediaVault 주요 항목 비교 — 홈랩 NAS OS 선택의 핵심 기준을 정리했다

    항목 TrueNAS CORE/SCALE Unraid OpenMediaVault
    기반 OS FreeBSD / Debian Linux Slackware Linux Debian Linux
    가격 무료 (오픈소스) 유료 (라이선스 구매 필요) 무료 (오픈소스)
    파일시스템 ZFS (기본) XFS / BTRFS (배열), ZFS(캐시) EXT4, XFS, BTRFS, ZFS(플러그인)
    디스크 혼합 어려움 (풀 단위 관리) 매우 자유로움 ⭐ 가능 (개별 마운트)
    Docker 지원 SCALE 버전 지원 기본 내장, 매우 편리 ⭐ 플러그인으로 가능
    VM 지원 SCALE 버전 지원 기본 내장 제한적
    데이터 무결성 ZFS 기반, 매우 강력 ⭐ 패리티 보호, 보통 파일시스템 의존
    최소 RAM 8GB 이상 권장 4GB 이상 권장 1GB도 가능 (Pi 등)
    진입 장벽 중~상 중 (WebUI 직관적) 하~중
    적합한 사용자 데이터 보호 중시, 중급 이상 홈랩 올인원, 중급 입문자, 저사양 환경

    실제 설치 — 이것만 알면 삽질 줄어듭니다

    TrueNAS 설치 시 주의사항

    TrueNAS는 설치 디스크(OS용)와 데이터 디스크를 반드시 분리해야 합니다. OS용으로 SSD나 USB를 별도로 쓰세요. 저도 처음에 이걸 몰라서 데이터 디스크에 OS 깔려고 했다가 낭패를 봤습니다 ㅎㅎ.

    # TrueNAS 설치 후 ZFS 풀 상태 확인
zpool status

# 풀 생성 예시 (RAIDZ1, 3개 디스크)
zpool create tank raidz1 /dev/da1 /dev/da2 /dev/da3

    ⚠️ ZFS와 ECC 메모리 논쟁: 공식적으로 iXsystems는 ECC 메모리를 권장합니다. 단, 실제로 ECC 없이 쓰는 홈랩 유저도 많아요. 중요한 데이터라면 ECC를 갖추는 게 마음 편합니다.

    Unraid 설치 시 주의사항

    Unraid는 USB 드라이브에서 부팅하는 독특한 구조입니다. 라이선스가 USB 장치에 묶이거든요. 고품질 USB를 쓰세요 — 싸구려 USB 썼다가 부팅 안 되는 상황이 생길 수 있습니다.

    # Unraid에서 Docker 컨테이너 상태 확인 (터미널)
docker ps

# Unraid 배열 상태 확인
mdcmd status

# 디스크 목록 확인
lsblk

    💡 팁: Unraid에서 캐시 풀(Cache Pool)을 SSD로 구성하면, 빠른 쓰기 후 배열로 이동하는 방식으로 성능을 크게 높일 수 있어요. 이걸 Mover라고 부릅니다.

    OpenMediaVault 설치 시 주의사항

    OMV는 Debian 설치하듯 진행됩니다. 라즈베리 파이에 설치할 때는 공식 스크립트를 사용해요.

    # 라즈베리 파이에 OMV 설치 스크립트 (공식 지원)
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

# OMV-Extras 플러그인 추가 (Docker 등 확장 기능용)
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | sudo bash

# OMV 서비스 상태 확인
systemctl status openmediavault-engined

    ⚠️ OMV 메이저 버전 업그레이드 시 플러그인 호환성 문제가 간혹 발생합니다. 업그레이드 전에는 꼭 백업하세요.

    설치 후 기본 검증 — 이것만 확인하세요

    NAS OS 설치 완료 후 WebUI에서 스토리지 풀 상태, 공유 폴더, 서비스 상태를 확인하는 화면

    어떤 OS를 설치했든, 기본 동작 확인은 이렇게 해보세요.

    1. 스토리지 풀/배열 상태 확인: 모든 디스크가 정상적으로 인식되었는지, RAID/패리티 구성이 올바른지 확인
    2. SMB 공유(Samba) 테스트: Windows 파일 탐색기에서 \\NAS-IP\공유폴더로 접근되는지
    3. NFS 공유 테스트: Linux 클라이언트에서 마운트 확인
    4. 읽기/쓰기 속도 테스트: 대용량 파일 복사로 기본 성능 확인
    5. 스냅샷 또는 백업 설정: 데이터 보호 체계가 실제로 동작하는지
    # Linux에서 NFS 마운트 테스트
sudo mount -t nfs NAS-IP:/mnt/pool/share /mnt/test
df -h /mnt/test

# 간단한 쓰기 속도 테스트
dd if=/dev/zero of=/mnt/test/testfile bs=1G count=1 oflag=direct

# SMB 연결 테스트 (smbclient)
smbclient //NAS-IP/share -U username

    여기까지 다 됐다면 🎉 기본 설정은 완료입니다. 다음은 서비스별 세부 튜닝과 백업 자동화 설정이 남아 있어요. 이 부분은 다음 글에서 각 OS별로 자세히 다룰 예정입니다.

    자주 묻는 질문 (FAQ)

    Q. TrueNAS와 Unraid 중 뭐가 더 낫나요?

    데이터 보호와 스토리지 신뢰성이 최우선이면 TrueNAS, 다양한 앱을 돌리는 올인원 홈서버를 원하고 디스크를 유연하게 추가하고 싶다면 Unraid가 더 맞습니다. 둘 다 훌륭한 선택이에요.

    Q. OpenMediaVault는 홈랩에서 쓰기 부족하지 않나요?

    단순 파일 공유 목적이라면 전혀 부족하지 않습니다. 단, 고급 스토리지 기능이나 Docker 환경이 복잡해지면 다른 OS로 넘어가는 분들도 있어요. 입문용으로는 충분히 좋습니다.

    Q. 나중에 OS를 바꿀 수 있나요?

    기술적으로는 가능하지만, 데이터 마이그레이션이 필요합니다. 특히 ZFS 풀은 TrueNAS에서 Unraid로 바로 이전이 안 돼요. 처음 선택을 신중하게 하시는 게 좋습니다.

    Q. 하드웨어 최소 사양은 어떻게 되나요?

    OpenMediaVault는 라즈베리 파이 4(4GB RAM)에서도 잘 돌아갑니다. TrueNAS는 8GB RAM 이상, Unraid는 4GB 이상을 권장하는데, 실제로 Docker나 VM을 많이 돌리면 16GB 이상이 편합니다.

    마무리 — 결국 정답은 “내 상황에 맞는 것”

    13년 동안 다양한 NAS OS를 써온 결론을 한 줄로 정리하면 이렇습니다.

    “데이터 보호 최우선 → TrueNAS, 유연한 올인원 홈랩 → Unraid, 가볍게 시작 → OpenMediaVault”

    사실 어떤 OS를 선택하든, 제대로 백업 체계를 갖추는 게 가장 중요합니다. NAS OS가 아무리 좋아도 백업이 없으면 소용없거든요. 3-2-1 백업 규칙(원본 1개 + 로컬 사본 1개 + 오프사이트 사본 1개)은 어떤 OS에서든 지켜주세요.

    저는 현재 메인 NAS는 TrueNAS SCALE로, 미디어 서버 겸 실험용 박스는 Unraid로 운영하고 있습니다. 두 개를 같이 쓰는 것도 방법이에요 ㅎㅎ.

    다음 글에서는 TrueNAS SCALE에서 ZFS 스냅샷 자동화와 원격 복제 설정하는 방법을 자세히 다룰 예정입니다. 궁금한 점은 댓글로 남겨주세요. 제가 직접 경험한 범위 안에서는 최대한 답변 드리겠습니다! 😄

  • [NAS] TrueNAS ZFS 스냅샷과 복제: 데이터 보호 전략

    [NAS] TrueNAS ZFS 스냅샷과 복제: 데이터 보호 전략

    목차

    데이터 유실의 악몽, 여러분은 준비되셨나요?

    안녕하세요, 13년차 인프라 엔지니어입니다. 서버실 관리하며 수많은 데이터 유실 사고를 직간접적으로 경험했어요. 실수로 파일을 지우거나, 하드디스크가 갑자기 고장 나거나, 심지어 랜섬웨어 공격까지… 상상만 해도 끔찍하죠?

    그래서 홈랩에서 TrueNAS를 운영하면서 데이터 보호에 정말 신경을 많이 씁니다. RAID만 믿고 있으면 안 된다는 걸 너무 잘 알거든요. RAID는 디스크 고장으로부터는 지켜주지만, 실수나 논리적 오류(Logical Error), 랜섬웨어 같은 위협에는 무력합니다. 이럴 때 필요한 게 바로 ZFS의 스냅샷(Snapshot)과 복제(Replication) 기능입니다. 제가 직접 써보니 이거 진짜 물건이더라고요!

    오늘은 여러분의 소중한 데이터를 지켜줄 TrueNAS ZFS 스냅샷과 복제 전략을 제 경험을 바탕으로 자세히 이야기해보겠습니다. 삽질하며 배운 노하우도 아낌없이 공유해 드릴게요!

    이 다이어그램은 TrueNAS ZFS 스냅샷과 복제 아키텍처의 개요를 보여줍니다. 로컬 TrueNAS에서 생성된 ZFS 스냅샷이 원격 TrueNAS로 복제되는 과정을 시각화했습니다.

    ZFS 스냅샷과 복제, 이게 뭔가요?

    처음엔 ZFS라는 이름도 생소하고, 스냅샷이니 복제니 하는 용어들이 헷갈리더라고요. 제가 직접 경험한 것을 바탕으로 쉽게 설명해 드릴게요.

    1. ZFS 스냅샷(Snapshot): 시간 여행 기능

    ZFS 스냅샷은 특정 시점의 파일 시스템 상태를 읽기 전용(Read-only)으로 저장하는 기능입니다. 비유하자면, 게임을 하다가 중요한 순간에 ‘저장’ 버튼을 누르는 것과 같아요. 언제든지 그 저장 지점으로 돌아갈 수 있거든요. 근데 일반적인 백업과는 좀 다릅니다. 변경된 데이터만 저장하는 CoW(Copy-on-Write) 방식을 사용해서 용량 효율이 정말 좋고, 생성도 눈 깜짝할 사이에 이루어져요. 제가 써보니 수백 GB짜리 데이터셋도 TrueNAS ZFS 스냅샷 뜨는데 1초도 안 걸리더라고요. 신기했습니다!

    • 즉시 생성 & 낮은 오버헤드: 순식간에 만들어지고 시스템 성능에 거의 영향을 주지 않습니다.
    • 공간 효율성: 변경된 블록만 저장하므로 추가 용량이 최소화됩니다.
    • 데이터 복구 용이성: 특정 시점으로 쉽게 롤백(Rollback)하거나, 스냅샷에서 파일을 직접 복사할 수 있습니다.
    • 불변성(Immutability): 생성된 스냅샷은 변경할 수 없어서 랜섬웨어 공격으로부터 안전합니다.

    2. ZFS 복제(Replication): 원격지 백업의 완성

    ZFS 복제는 이렇게 만들어진 스냅샷을 다른 ZFS 시스템(다른 TrueNAS 서버나 원격 서버)으로 전송(Transfer)하는 기능입니다. 게임 저장 파일을 친구 집 컴퓨터에 똑같이 복사해두는 것과 비슷해요. 내 컴퓨터가 고장 나도 친구 컴퓨터의 저장 파일로 다시 시작할 수 있는 거죠.

    TrueNAS 복제 기능은 ZFS의 델타(Delta) 전송을 활용합니다. 첫 번째 복제 때는 전체 스냅샷을 보내지만, 그 이후부턴 이전 스냅샷과 현재 스냅샷 간의 변경된 부분(Incremental changes)만 전송합니다. 실제로 홈랩에서 써보니 처음 한 번만 오래 걸리고 그 다음부턴 정말 빠르더라고요. 네트워크 트래픽도 확 줄고요. 이게 바로 재해 복구(Disaster Recovery, DR) 전략의 핵심입니다.

    • 원격지 백업: 로컬 시스템에 문제가 생겨도 원격지에 안전한 사본이 있습니다.
    • 대역폭 효율성: 증분(Incremental) 복제를 통해 네트워크 사용량을 최소화합니다.
    • 자동화 가능: TrueNAS UI에서 스케줄링하여 자동으로 복제를 수행할 수 있습니다.
    • 완전한 복구: 원격지에서 전체 데이터셋을 복구하거나, 특정 스냅샷으로 롤백하여 복구할 수 있습니다.

    TrueNAS ZFS 스냅샷 & 복제, 제가 직접 해보니

    이제 직접 TrueNAS에서 스냅샷과 복제 설정을 해볼 시간입니다. 처음엔 메뉴가 좀 복잡해 보여서 삽질 좀 했지만, 한 번 해보면 어렵지 않아요. 저를 따라오시면 금방 하실 수 있을 겁니다. 제가 쓰는 TrueNAS SCALE 기준으로 설명해 드릴게요.

    1. 자동 스냅샷 태스크 설정하기

    가장 먼저 할 일은 원하는 데이터셋에 주기적으로 ZFS 스냅샷을 찍도록 설정하는 겁니다. 저는 매일 밤 12시에 스냅샷을 찍고, 최근 7일치 스냅샷을 보관하도록 설정했어요.

    1. TrueNAS 웹 UI에 접속합니다.
    2. 왼쪽 메뉴에서 ‘Data Protection’ > ‘Snapshots’로 이동합니다.
    3. 우측 상단의 ‘ADD’ 버튼을 클릭합니다.
    4. 설정 화면에서 다음 항목들을 채워줍니다.
      • Dataset: 스냅샷을 찍을 데이터셋을 선택합니다. (예: Pool명/데이터셋명)
      • Recursive: 하위 데이터셋까지 스냅샷을 찍을지 여부입니다. 저는 보통 체크합니다.
      • Naming Schema: 스냅샷 이름 규칙입니다. 기본값 auto-%Y-%m-%d_%H-%M을 사용해도 충분합니다.
      • Schedule: 스냅샷을 찍을 주기입니다. 저는 ‘Daily’로 설정하고 ‘Time’을 ’00:00’으로 지정했습니다.
      • Keep for: 스냅샷을 얼마나 보관할지 설정합니다. 저는 ‘7 Days’로 설정했습니다.
    5. ‘SAVE’ 버튼을 클릭하여 저장합니다.

    ✅ 이제 지정된 시간에 자동으로 ZFS 스냅샷이 생성되고 오래된 스냅샷은 자동으로 삭제될 겁니다. ‘Snapshots’ 메뉴에서 생성된 스냅샷 목록을 확인할 수 있습니다.

    TrueNAS 웹 UI에서 ZFS 자동 스냅샷 태스크를 설정하는 화면입니다. 데이터셋, 스케줄, 보관 기간 등을 지정하여 원하는 스냅샷 정책을 만들 수 있습니다.

    2. ZFS 복제 태스크 설정하기 (원격 백업)

    스냅샷만으로는 부족합니다. 메인 TrueNAS 서버 자체가 망가지면 스냅샷도 소용없거든요. 그래서 저는 집의 다른 미니 PC에 TrueNAS를 설치해서 원격 복제 타겟으로 사용하고 있습니다. 물론 클라우드 스토리지(S3 등)로 복제하는 방법도 있지만, 저는 로컬 네트워크에서 빠르고 안정적인 TrueNAS 복제를 선호해서 이렇게 구성했어요.

    복제를 위해서는 먼저 원격 TrueNAS 서버에 SSH 접속을 위한 SSH Key를 설정해야 합니다. 보안상 ID/PW 방식보다는 SSH Key 방식을 추천합니다. 이 부분은 한 번 설정해두면 정말 편합니다.

    1. SSH Key 생성:
      • 복제를 시작할 TrueNAS(소스)에서 왼쪽 메뉴 ‘System Settings’ > ‘SSH Keypairs’로 이동합니다.
      • ‘ADD’를 클릭하고 키 이름을 지정한 후 ‘GENERATE KEYPAIR’를 선택하여 새 키를 생성합니다.
      • 생성된 Public Key 내용을 복사해둡니다.
    2. 원격 TrueNAS에 Public Key 등록:
      • 원격 TrueNAS(타겟) 웹 UI에 접속합니다.
      • ‘System Settings’ > ‘Users’로 이동하여 복제에 사용할 유저(예: root)를 선택하고 ‘EDIT’합니다.
      • ‘SSH Public Keys’ 필드에 아까 복사해둔 Public Key 내용을 붙여넣고 저장합니다.
      • 💡 팁: SSH 서비스가 활성화되어 있는지 확인하세요. ‘System Settings’ > ‘Services’에서 SSH 서비스를 ‘Running’ 상태로 변경하고 ‘Start Automatically’를 체크합니다.
    3. 복제 태스크 설정:
      • 다시 소스 TrueNAS로 돌아와서 ‘Data Protection’ > ‘Replication Tasks’로 이동합니다.
      • 우측 상단의 ‘ADD’ 버튼을 클릭합니다.
      • 설정 화면에서 다음 항목들을 채워줍니다.
        • Source: 복제할 데이터셋을 선택합니다. (예: Pool명/데이터셋명)
        • Destination: 원격 TrueNAS의 IP 주소와 SSH 포트(기본값 22)를 입력합니다. (예: ssh://192.168.1.100)
        • SSH Key: 아까 생성한 SSH Keypair를 선택합니다.
        • Remote Hostname: 원격 TrueNAS의 호스트명이나 IP를 다시 확인합니다.
        • Remote ZFS Filesystem: 원격 TrueNAS에서 ZFS 스냅샷이 저장될 데이터셋 경로를 지정합니다. (예: remote_pool/replicated_data)
        • Naming Schema: 원격지에 생성될 스냅샷 이름 규칙입니다. 소스와 동일하게 설정하는 것이 좋습니다.
        • Schedule: 복제 주기를 설정합니다. 저는 스냅샷 주기와 비슷하게 ‘Daily’로 설정했습니다.
        • Liveness Check: 원격지가 살아있는지 확인할 주기입니다.
        • Enable Replication: 체크박스를 활성화합니다.
      • ‘SAVE’ 버튼을 클릭하여 저장합니다.

    🎉 드디어 복제 태스크 설정이 완료되었습니다! 첫 복제는 소스 데이터셋의 크기에 따라 시간이 좀 걸릴 수 있습니다. ‘Replication Tasks’ 목록에서 진행 상황을 확인할 수 있어요. 완료되면 원격 TrueNAS에서도 복제된 스냅샷과 데이터셋을 확인할 수 있을 겁니다.

    ⚠️ 삽질 경험 & 주의사항

    제가 TrueNAS ZFS 복제를 세팅하면서 겪었던 몇 가지 삽질과 주의사항을 공유해 드릴게요. 여러분은 저처럼 고생하지 마시라고요!

    • SSH Key 설정 오류: 가장 많이 겪는 문제입니다. Public Key를 잘못 복사하거나, 원격 TrueNAS의 유저에게 Key가 제대로 등록되지 않았을 때 복제가 실패합니다. ‘System Settings’ > ‘Users’에서 해당 유저의 SSH Public Keys 필드에 제대로 들어갔는지 꼭 확인하세요. 줄 바꿈이나 공백 하나에도 민감하니까요.
    • 네트워크 문제: 소스 TrueNAS와 타겟 TrueNAS 간의 네트워크 연결이 불안정하거나 방화벽(Firewall)이 SSH 포트(기본 22)를 막고 있는 경우가 있습니다. ping 명령어로 연결 확인하고, 방화벽 설정을 꼭 확인해 주세요. 예를 들어, 소스 TrueNAS에서 원격 TrueNAS로 Ping 테스트를 해볼 수 있습니다. 
      
ping 192.168.1.100

      혹은 SSH 서비스가 제대로 실행 중인지 원격 TrueNAS에서 확인하는 것도 중요합니다.

    • 데이터셋 경로 오류: 원격 TrueNAS의 ‘Remote ZFS Filesystem’ 경로를 잘못 지정하면 복제가 실패합니다. 반드시 원격 TrueNAS에 해당 풀(Pool)이 존재해야 하고, 원하는 데이터셋 경로가 유효한지 확인해야 합니다. 저는 실수로 존재하지 않는 데이터셋에 복제하려고 해서 한참 헤맸던 기억이 있거든요.
    • 스냅샷 보존 정책: ZFS 스냅샷과 복제 태스크의 보존 정책(Keep for)을 잘 설정해야 합니다. 너무 짧게 설정하면 중요한 스냅샷이 삭제될 수 있고, 너무 길게 설정하면 스토리지 공간을 너무 많이 차지하게 됩니다. 데이터의 중요도와 스토리지 용량을 고려해서 적절한 기간을 설정하는 것이 중요합니다.
    • 초기 복제 시간: 첫 복제는 전체 데이터를 전송하므로 시간이 오래 걸릴 수 있습니다. 데이터 양이 많다면 네트워크 대역폭과 시간을 충분히 확보하고 시작하는 것이 좋습니다. 저는 1TB 넘는 데이터를 첫 TrueNAS 복제할 때 거의 하루 종일 걸리더라고요.

    이런 문제들 때문에 저도 초기에는 꽤나 애를 먹었습니다. 에러 메시지를 꼼꼼히 읽어보고, TrueNAS 포럼이나 커뮤니티를 검색해보는 것이 큰 도움이 됩니다. 결국 해결하고 나면 그렇게 뿌듯할 수가 없어요! 🎉

    ✅ 복제 결과 확인 및 데이터 복구 테스트

    설정이 끝났다고 마냥 손 놓고 있으면 안 되겠죠? 실제로 잘 작동하는지, 그리고 만약의 사태가 발생했을 때 제대로 복구할 수 있는지 검증(Verification)하는 과정이 정말 중요합니다. 제가 직접 해본 검증 방법들을 알려드릴게요.

    1. 원격 TrueNAS에서 스냅샷 확인

    가장 기본적인 확인 절차입니다. 원격 TrueNAS 웹 UI에 접속해서 ‘Data Protection’ > ‘Snapshots’ 메뉴로 이동해 보세요. 소스 TrueNAS에서 복제된 스냅샷들이 보인다면 일단 복제는 성공적으로 진행되고 있다는 뜻입니다.

    또한, ‘Storage’ > ‘Pools’ 메뉴에서 해당 데이터셋을 클릭하고 ‘Snapshots’ 탭으로 이동하면 해당 데이터셋의 스냅샷 목록을 볼 수 있습니다. 제가 확인해보니 소스에서 찍힌 ZFS 스냅샷 이름과 동일하게 잘 복제되어 있더라고요.

    2. 파일 복구 시뮬레이션

    실제로 데이터를 잃어버렸을 때 어떻게 복구하는지 미리 경험해보는 것이 좋습니다. 저는 테스트용 파일을 만들고 삭제한 다음, 스냅샷으로 복구하는 시뮬레이션을 해봤어요.

    1. 원격 TrueNAS의 복제된 데이터셋에 접속합니다. (SMB/NFS 등으로 마운트)
    2. 테스트용 파일을 몇 개 생성합니다.
    3. 강제로 이 파일들을 삭제하거나 내용을 변경합니다.
    4. ‘Storage’ > ‘Pools’에서 해당 데이터셋을 선택하고 ‘Snapshots’ 탭으로 이동합니다.
    5. 복구하고 싶은 시점의 ZFS 스냅샷을 선택하고 ‘Rollback’ 버튼을 클릭합니다. ⚠️ 롤백은 현재 상태를 스냅샷 시점으로 되돌리는 것이므로, 신중하게 진행해야 합니다. 보통은 스냅샷을 Clone(클론)하여 새로운 데이터셋으로 만든 후, 필요한 파일만 복사하는 방식을 더 많이 사용합니다.
    6. 아니면 스냅샷 내부로 들어가 필요한 파일만 복사해 올 수도 있습니다. 스냅샷은 읽기 전용으로 마운트될 수 있거든요.

    제가 해보니 롤백은 너무 강력한 기능이라 신중해야 하고, 보통은 스냅샷을 마운트해서 특정 파일만 가져오는 게 훨씬 안전하고 편리했습니다. 💡

    TrueNAS 웹 UI에서 복제된 ZFS 데이터셋의 스냅샷 목록을 확인하고, 필요시 롤백 또는 클론 기능을 사용하는 화면입니다.

    마무리하며: 데이터 보호는 선택이 아닌 필수

    TrueNAS의 ZFS 스냅샷과 복제 기능은 정말 강력한 데이터 보호 및 재해 복구 전략을 구축할 수 있게 해줍니다. 저도 처음엔 설정이 좀 복잡하게 느껴졌지만, 한 번 제대로 구축해두니 마음이 정말 편안하더라고요. 홈랩의 소중한 사진, 영상, 문서 파일들이 안전하게 보호되고 있다는 생각에 뿌듯했습니다.

    데이터 유실은 언제든 일어날 수 있는 일입니다. 중요한 건 문제가 생겼을 때 얼마나 빨리, 그리고 얼마나 완벽하게 복구할 수 있느냐입니다. ZFS 스냅샷은 로컬에서의 빠른 복구를, ZFS 복제는 원격지 재해 발생 시의 데이터 복구를 보장해 줍니다.

    여러분도 오늘 제가 공유해드린 내용을 바탕으로 TrueNAS ZFS 스냅샷과 복제 기능을 꼭 활용해 보셨으면 좋겠습니다. 혹시 설정 중에 궁금한 점이나 막히는 부분이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다!

    다음 글에서는 이렇게 복제된 데이터를 활용하여 다른 용도로 쓰는 방법이나, 클라우드 스토리지로의 복제 등 좀 더 심화된 내용들을 다뤄볼까 합니다. 기대해 주세요!

    TrueNAS ZFS 스냅샷과 복제 기능이 제공하는 핵심 장점들을 요약한 인포그래픽입니다.

  • [NAS] TrueNAS SCALE 앱 배포: Docker 컨테이너부터 관리까지

    목차

    NAS가 단순 저장소였던 시대는 끝났습니다

    홈랩을 운영하다 보면 어느 순간 이런 생각이 드시지 않나요? “NAS에 데이터만 넣어두기엔 너무 아깝다.” 저도 처음엔 그냥 파일 서버로 쓰다가, 어느 날 Plex를 띄워보고 나서 생각이 완전히 바뀌었거든요. 그 이후로 TrueNAS SCALE 위에서 십수 개의 서비스를 돌리고 있습니다.

    근데 솔직히 말씀드리면, 처음에 TrueNAS SCALE 앱 시스템을 접했을 때 꽤 헷갈렸어요. 버전마다 배포 방식이 달라지고, 한글 자료도 많지 않아서 삽질을 꽤 했거든요. 이번 글에서는 제가 직접 겪어온 경험을 바탕으로, TrueNAS SCALE에서 앱을 배포하고 관리하는 방법을 처음부터 끝까지 정리해 드리겠습니다.

    TrueNAS SCALE 위에서 여러 컨테이너 앱이 동작하는 홈랩 전체 아키텍처. 스토리지, 네트워킹, 앱 레이어가 통합된 모습입니다.

    TrueNAS SCALE 앱 시스템이 바뀐 이유

    여기서 중요한 역사 이야기를 하나 해야 할 것 같아요. TrueNAS SCALE의 앱 시스템은 버전을 거치면서 꽤 큰 변화가 있었거든요.

    초기 버전(Angelfish, Bluefin, Cobia 등)에서는 K3s(경량 쿠버네티스)를 기반으로 앱을 운영했습니다. 쿠버네티스를 쓴다니까 좋아 보이긴 했는데, 일반 홈랩 사용자 입장에서는 진입 장벽이 꽤 높았어요. Helm 차트 구조도 이해해야 하고, 리소스 관리가 복잡하다는 불만도 많았고요.

    그래서 iXsystems는 Electric Eel(24.10) 버전부터 TrueNAS SCALE 앱 시스템을 Docker Compose 기반으로 전면 바꿨습니다. 쿠버네티스를 걷어내고 훨씬 직관적인 Docker Compose 방식을 채택한 거죠. 솔직히 처음엔 “아니 왜 바꾸는 거야”라고 생각했는데, 써보니 훨씬 낫더라고요.

    • 이전(~Dragonfish): K3s + Helm Chart 기반, TrueCharts 커뮤니티 카탈로그 의존도 높음
    • 이후(Electric Eel~): Docker Compose 기반, 공식 카탈로그 + 커스텀 컨테이너 지원

    이 글은 Electric Eel 이후의 Docker Compose 기반 앱 시스템을 중심으로 설명합니다. 혹시 구버전 사용 중이시라면 업그레이드를 먼저 하시길 권장합니다.

    시작 전 준비사항 체크

    본격적으로 TrueNAS SCALE 앱 배포에 들어가기 전에 확인해야 할 것들이 있어요. 저도 이걸 안 하고 바로 들어갔다가 중간에 막혀서 처음부터 다시 한 경험이 있거든요 😅

    1. 풀(Pool) 설정 확인: 앱 데이터를 저장할 ZFS 풀이 생성되어 있어야 합니다. 저는 SSD 별도 풀을 만들어서 앱 전용으로 씁니다.
    2. Apps 전용 풀 지정: TrueNAS SCALE에서 Apps 탭으로 이동하면, 앱 데이터를 저장할 풀을 처음 한 번 지정하게 돼 있어요. 나중에 바꾸기 귀찮으니 처음에 잘 골라두세요.
    3. 네트워크 설정: 외부에서 접근이 필요한 앱이라면, 공유기 포트 포워딩이나 Reverse Proxy(리버스 프록시) 설정도 미리 생각해두면 좋습니다.
    4. TrueNAS SCALE 버전: 앞서 말씀드린 것처럼, 가능하면 Electric Eel(24.10) 이상으로 업그레이드하고 시작하세요.

    TrueNAS SCALE 앱 카탈로그에서 첫 번째 앱 설치하기

    준비가 됐다면 이제 실전입니다! TrueNAS SCALE 웹 UI 왼쪽 메뉴에서 Apps를 클릭하세요. 처음 접속하면 앱 풀(pool)을 선택하라고 나옵니다. 앞서 준비한 풀을 선택하면 돼요.

    앱 화면으로 들어오면 Discover Apps 버튼이 보입니다. 여기서 공식 카탈로그에 등록된 앱들을 검색하고 설치할 수 있어요. Plex, Nextcloud, Jellyfin, Home Assistant 같은 인기 홈랩 앱들이 대부분 등록되어 있습니다.

    예시로 Jellyfin(미디어 서버)을 설치해볼게요.

    1. Discover Apps에서 “Jellyfin” 검색
    2. 앱 카드 클릭 → Install 버튼 클릭
    3. 설정 화면에서 주요 항목 입력:
      • Application Name: jellyfin (기본값 그대로)
      • Network Configuration: 포트 번호 설정 (기본 8096)
      • Storage Configuration: 미디어 파일이 있는 데이터셋 경로 지정
    4. Install 클릭 후 배포 완료 대기

    설치가 완료되면 앱 목록에 Jellyfin이 나타나고, http://NAS-IP:8096으로 접속할 수 있어요. 드디어 됐다! 라는 느낌이 이때 오더라고요 🎉

    TrueNAS SCALE Apps 탭의 카탈로그 화면. Discover Apps에서 원하는 앱을 검색하고 GUI로 간편하게 설치할 수 있습니다.

    Docker 컨테이너 직접 배포하기 (Custom App)

    카탈로그에 없는 앱을 써야 할 때가 있죠. 저도 특정 오픈소스 툴을 올리고 싶은데 카탈로그에 없을 때, 직접 Docker 이미지를 지정해서 배포하는 방법을 씁니다. Docker on TrueNAS를 활용하는 방식이에요.

    Discover Apps 화면 오른쪽 위를 보면 Custom App 버튼이 있습니다. 이걸 누르면 Docker Compose 방식으로 직접 컨테이너를 정의할 수 있는 화면이 나와요.

    예시로 Uptime Kuma(서비스 모니터링 앱)를 커스텀 앱으로 배포해볼게요.

    # Custom App 설정에서 사용하는 Docker Compose 예시
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    ports:
      - "3001:3001"
    volumes:
      - /mnt/pool/apps/uptime-kuma:/app/data
    restart: unless-stopped

    TrueNAS SCALE의 Custom App UI에서는 이걸 GUI 폼으로 입력할 수 있어요. 직접 YAML을 쓰는 방식도 지원되고, 폼 형태로도 입력 가능합니다.

    핵심 입력 항목들은 이렇습니다:

    항목 설명 예시
    Image Repository Docker Hub 이미지 이름 louislam/uptime-kuma
    Image Tag 버전 태그 latest 또는 1.23.x
    Container Port 컨테이너 내부 포트 3001
    Node Port 호스트에서 접근할 포트 3001
    Host Path TrueNAS 데이터셋 경로 /mnt/pool/apps/uptime-kuma
    Mount Path 컨테이너 내부 마운트 경로 /app/data

    💡 팁: 볼륨 경로는 반드시 미리 ZFS 데이터셋으로 만들어두고 마운트하는 게 좋습니다. 그냥 디렉토리 경로를 쓰면 나중에 스냅샷 관리가 안 되거든요. 이거 처음에 몰라서 나중에 다 옮긴 적이 있습니다 ㅎㅎ.

    환경 변수와 네트워크 설정 팁

    컨테이너를 배포할 때 환경 변수(Environment Variable) 설정이 필요한 경우가 많아요. 예를 들어 데이터베이스 비밀번호, API 키 같은 것들이요.

    Custom App 설정 화면에서 Environment Variables 섹션을 찾으면 Key-Value 형태로 추가할 수 있습니다.

    # 환경 변수 예시 (Nextcloud 같은 경우)
MYSQL_DATABASE=nextcloud
MYSQL_USER=ncuser
MYSQL_PASSWORD=your_secure_password
NEXTCLOUD_ADMIN_USER=admin
NEXTCLOUD_ADMIN_PASSWORD=admin_password

    네트워크 관련해서 한 가지 더 말씀드리면, TrueNAS SCALE에서 여러 앱이 서로 통신해야 할 때(예: 웹 앱 + DB 컨테이너) 같은 Docker 네트워크에 묶어야 해요. Custom App에서 Network Configuration 섹션에서 네트워크를 지정할 수 있습니다. 이 부분은 처음엔 좀 헷갈릴 수 있는데, 같은 앱 스택이라면 동일한 사용자 정의 네트워크를 사용하면 돼요.

    ⚠️ 트러블슈팅: 자주 겪는 문제들

    13년 동안 인프라 일을 하면서 깨달은 건, 문서대로 안 되는 게 정상이라는 거예요 ㅎㅎ. TrueNAS SCALE 앱 배포하면서 자주 만나는 문제들과 해결법을 공유합니다.

    문제 1: 앱이 Deploying 상태에서 멈춤

    가장 흔한 문제예요. 배포 눌렀는데 한참 동안 Deploying 상태에서 안 바뀌는 경우.

    원인 대부분은 이미지 풀(pull) 실패입니다. 이미지 이름이 틀렸거나, NAS가 인터넷에 제대로 연결 안 됐을 때 주로 발생해요.

    # TrueNAS Shell에서 컨테이너 로그 확인
docker logs [컨테이너_이름]

# 이미지가 제대로 받아졌는지 확인
docker images | grep [앱_이름]

    문제 2: 볼륨 마운트 권한 오류

    앱은 뜨는데 데이터를 못 쓰는 경우가 있어요. 특히 컨테이너가 특정 UID로 실행되는데, 마운트한 경로의 소유자가 다를 때 발생합니다.

    # TrueNAS Shell에서 권한 확인 및 수정
ls -la /mnt/pool/apps/uptime-kuma

# 필요하다면 소유자 변경 (999는 예시 UID, 앱마다 다름)
chown -R 999:999 /mnt/pool/apps/uptime-kuma

    💡 팁: Docker Hub의 해당 이미지 문서에 어떤 UID로 실행되는지 나와 있는 경우가 많아요. 미리 확인하고 데이터셋 권한을 맞춰두면 삽질을 줄일 수 있습니다.

    문제 3: 포트 충돌

    “이미 사용 중인 포트”라는 오류가 뜨는 경우요. 앱들이 기본 포트가 겹칠 때 발생합니다. 예를 들어 여러 웹 앱이 다 80번 포트를 쓰려 하면 충돌이 나죠.

    해결책은 단순합니다. 앱 설치 시 Node Port를 겹치지 않게 다른 번호로 바꿔주면 돼요. 저는 개인적으로 앱별로 포트 번호를 스프레드시트에 정리해두고 쓰고 있습니다. 처음엔 귀찮아 보여도, 앱이 10개 이상 넘어가면 이게 필수예요.

    TrueNAS SCALE 앱 관리 및 업데이트

    설치하고 끝이 아니죠. 앱 관리도 중요합니다. TrueNAS SCALE에서 설치된 앱의 업데이트는 Apps 탭 → Installed 화면에서 할 수 있어요.

    업데이트 가능한 앱이 있으면 배지(badge)가 표시되고, Update All 버튼으로 한 번에 업데이트도 가능합니다. 근데 저는 한 번에 다 올리기보다는, 중요한 앱은 하나씩 올리고 확인하는 편이에요. 한 번에 다 올렸다가 뭔가 깨지면 어디서 문제가 생긴 건지 찾기 어렵거든요.

    앱 데이터 백업은 ZFS 스냅샷을 활용하는 게 최고입니다. 앱 데이터를 담은 데이터셋에 정기 스냅샷을 걸어두면, 앱이 망가졌을 때 스냅샷으로 롤백이 가능해요. 이게 TrueNAS SCALE을 쓰는 가장 큰 이유 중 하나라고 생각합니다.

    TrueNAS SCALE Apps의 Installed 탭. 실행 중인 앱 상태, 업데이트 가능 여부, 리소스 사용량을 한눈에 확인할 수 있습니다.

    ✅ 실전 구성: 제 홈랩 앱 운영 사례

    참고로 현재 제가 TrueNAS SCALE 위에서 돌리고 있는 주요 앱들을 공유할게요. 비슷한 구성을 계획하시는 분들께 도움이 될 것 같아서요.

    앱 이름 용도 설치 방법
    Jellyfin 미디어 서버 (영화, 음악) 공식 카탈로그
    Nextcloud 개인 클라우드 스토리지 공식 카탈로그
    Home Assistant 스마트홈 허브 공식 카탈로그
    Uptime Kuma 서비스 모니터링 Custom App
    Vaultwarden 비밀번호 관리자 Custom App
    Nginx Proxy Manager 리버스 프록시 + SSL Custom App

    모두 ZFS 데이터셋에 데이터를 저장하고, 매일 새벽 3시에 스냅샷이 자동으로 찍히도록 설정해뒀습니다. 덕분에 앱 업데이트 실패나 설정 꼬임 같은 상황에서도 걱정 없이 복구할 수 있어요. 실제로 Home Assistant 업데이트 후 통합 설정이 날아갔을 때 스냅샷으로 5분 만에 복구한 적도 있습니다 😅

    현재 운영 중인 홈랩의 앱 구성 요약. TrueNAS SCALE 위에서 미디어, 클라우드, 모니터링, 보안 앱들이 유기적으로 연동되는 모습입니다.

    마무리: TrueNAS SCALE 앱 배포, 이렇게 시작하세요

    오늘 다룬 내용을 간단히 정리해볼게요.

    • ✅ TrueNAS SCALE은 Electric Eel(24.10)부터 Docker Compose 기반 앱 시스템으로 전환됨
    • ✅ 공식 카탈로그 앱은 GUI로 손쉽게 설치 가능
    • ✅ 카탈로그에 없는 앱은 Custom App 기능으로 Docker 이미지 직접 지정 배포
    • ✅ 볼륨은 반드시 ZFS 데이터셋으로 분리해서 관리할 것
    • ✅ 스냅샷 정책을 함께 설정해두면 백업/복구가 정말 편함

    처음 TrueNAS SCALE 앱 시스템을 접하면 설정 항목이 많아서 막막할 수 있어요. 근데 한 번 익숙해지면 정말 편합니다. 스토리지와 앱을 같은 플랫폼에서 관리한다는 게 이렇게 편할 줄 몰랐다는 생각이 드실 거예요.

    다음 글에서는 Nginx Proxy Manager와 Let’s Encrypt를 이용한 HTTPS 설정을 다룰 예정입니다. 외부에서 도메인으로 안전하게 접근하는 방법인데, 홈랩을 한 단계 업그레이드하고 싶은 분들께 유용할 거예요. 이전 글에서 다뤘던 ZFS 데이터셋 구성과 함께 보시면 더 도움이 됩니다.

    궁금한 점이 있으면 댓글로 남겨주세요. 같이 삽질하며 발전하는 홈랩 라이프, 응원합니다! 🎉