Synology, QNAP, TrueNAS 없이 최소 ZFS NAS 구축하기 (2024)

 (neil.computer)
1P by GN⁺ | ★ favorite | 댓글 1개
  • GUI가 필요 없는 기본 NAS라면 ZFS 데이터셋을 만들고 Samba로 공유하는 조합만으로 충분히 단순한 네트워크 스토리지를 구성할 수 있음
  • 예시 환경은 Debian 12 Bookworm, OpenZFS zfs-2.1.1, RAIDZ1, ECC RDIMM 16GB RAM, 4×4TB NVMe SSD이며 암호화와 백업 전략은 범위에서 제외됨
  • ZFS는 풀과 파일시스템 구성을 디스크에 저장하므로 OS가 망가져도 다른 머신에서 zfs import로 데이터를 다시 가져올 수 있음
  • 디스크는 /dev/nvme1 같은 순서 의존 이름보다 /dev/disk/by-id 또는 /etc/zfs/vdev_id.conf의 별칭으로 지정하는 편이 안전함
  • 실제 네트워크 공유는 Samba가 담당하며, 일반 문서 공유와 macOS Time Machine 공유를 docs, backups 데이터셋으로 나눠 구성함

직접 만드는 최소 NAS의 범위

  • 목표는 Synology, QNAP, TrueNAS 같은 풀 기능 NAS 제품 없이 기본 NAS를 직접 구성하는 것임
  • 예시 구성은 다음 범위로 제한됨
    • RAID 레벨: RAIDZ1, 1개 드라이브 장애 허용
    • 운영체제: Debian 12 Bookworm
    • 암호화: 없음
    • ZFS 구현: OpenZFS, zfs-2.1.1
    • CPU: 4코어, 저렴한 Xeon 서버 CPU 사용 가능
    • RAM: ECC RDIMM RAM 16GB
    • 스토리지: 4×4TB NVMe SSD
    • 백업: 다루지 않으며 별도 구성이 필요함
  • TrueNAS는 풀 기능의 엔터프라이즈급 소프트웨어 스위트에 가까워, 필요한 기능이 단순할수록 제공 기능과 요구사항 사이의 불일치가 커짐
  • 직접 구성하면 시스템의 각 요소를 이해할 수 있고, 또 다른 소프트웨어 스위트에 의존하지 않아도 됨

ZFS가 디스크에 보관하는 구성 정보

  • ZFS 파일시스템은 자기완결적이라 호스트 OS가 손상돼도 디스크가 멀쩡하면 데이터를 되찾을 수 있음
  • 새 머신이나 새 OS에 디스크를 연결하고 zfs 도구를 설치한 뒤 zfs import를 실행하면 기존 풀을 가져올 수 있음
  • ZFS의 구성과 세부 정보는 디스크 자체에 저장됨
    • 예를 들어 6개 디스크로 RAIDZ2를 구성했다면, 디스크들을 ZFS 도구가 설치된 새 머신으로 옮긴 뒤 zfs import만 실행해도 RAIDZ2로 표시됨
  • 호스트 OS나 머신에 문제가 생겨도 디스크가 손상되지 않았다면 데이터는 유지됨

디스크 식별과 별칭 구성

  • Linux 머신에서 디스크 목록은 lsblk -d -o TRAN,NAME,TYPE,MODEL,SERIAL,SIZE로 확인함
  • 예시에서는 Samsung SSD 990 PRO 4TB NVMe 드라이브 4개를 사용함
  • 각 디스크는 /dev/disk/by-id 아래에서 ID와 /dev/nvme... 장치명으로 연결된 심볼릭 링크를 가짐
  • /etc/zfs/vdev_id.conf에 별칭을 정의하면 긴 디스크 ID를 짧은 이름으로 매핑할 수 있음
alias nvme0 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
alias nvme1 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
alias nvme2 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
alias nvme3 /dev/disk/by-id/nvme-Samsung_SSD_990_PRO_4TB_XXXXXXXXXXXXXXX
  • udevadm trigger를 실행하거나 재부팅하면 별칭이 적용됨
  • 적용 여부는 ls -lh /dev/disk/by-vdev로 확인할 수 있음
  • Alias mapping은 선택 사항이며, zpool 생성 시 전체 /dev/disk/by-id/... 경로를 직접 써도 됨
  • /dev/nvme1, /dev/nvme2 같은 장치명은 새 드라이브를 장착할 때 순서가 보장되지 않으므로 피해야 함
  • /etc/zfs/vdev_id.conf는 zpool 생성 편의를 위한 설정이며, OS가 손상돼 이 파일을 잃어도 ZFS 풀 자체에는 문제가 없음

zpool 생성과 데이터셋 구성

  • 예시는 4개 NVMe로 RAIDZ1 zpool을 만들며, RAID 5처럼 1개 드라이브 장애를 허용함
  • 더 높은 내결함성이 필요하면 RAIDZ2, 즉 RAID 6 구성이 더 회복력이 있음
  • ZFS 설치는 OpenZFS 설치 문서를 참고하며, 예시로 RHEL 9에서는 dnf install zfs처럼 설치함
  • zpool 생성 시 ashift=12 옵션을 권장함
    • 많은 디스크는 호환성 때문에 OS에 512KB 섹터 크기로 보고함
    • Samsung 990 Pro 같은 대용량 디스크는 4KB 또는 8KB 섹터 크기를 가질 수 있음
    • ashift=12는 4KB 섹터 크기를 나타내며 성능을 크게 개선할 수 있음
    • zpool 생성 시점이 이 값을 설정할 마지막 기회임
zpool create -o ashift=12 s16z1 raidz1 nvme0 nvme1 nvme2 nvme3
zpool status s16z1
  • zpool은 디스크 추상화이고, zfs는 파일시스템임
  • zpool create를 실행하면 ZFS 파일시스템도 함께 생성됨
  • zdb | grep ashift로 ashift: 12 설정 여부를 확인할 수 있음
  • 공유 전에 마운트 지점과 압축을 설정함
zfs set mountpoint=/mnt/s16z1 s16z1
zfs set compression=lz4 s16z1
  • 루트 데이터셋 아래에 docs와 backups 데이터셋을 생성함
zfs create s16z1/docs
zfs create s16z1/backups
  • docs는 문서용, backups는 Time Machine 백업용으로 사용함
  • ZFS 데이터셋은 단순 폴더보다 많은 기능을 제공함
    • 데이터셋별 속성 관리
    • 암호화
    • 전송과 복제
    • 스냅샷
  • 큰 파일 범주별로 별도 데이터셋을 만드는 편이 좋음
  • 예를 들어 docs만 원격 서버로 백업하고 싶을 때 전체 s16z1 루트 데이터셋을 보내지 않아도 됨

Samba로 공유 계정 만들기

  • 네트워크 파일 공유 방식은 ZFS와 독립적이며, ZFS는 호스트 시스템에 마운트되어 있기만 하면 됨
  • Samba를 설치함
apt install samba
  • Samba 전용 UNIX 사용자 john을 만들고 비밀번호를 설정함
useradd -m john
passwd john
  • smbpasswd -a john으로 UNIX 사용자 john을 Samba 사용자와 연결함
  • 접속하는 호스트는 SYS\john으로 공유에 접근할 수 있음
  • pdbedit -L -v john으로 Samba 사용자 등록을 확인할 수 있음
  • Samba 사용자 삭제는 pdbedit -x -u john으로 처리함

일반 공유와 Time Machine 공유

  • /etc/samba/smb.conf를 편집해 docs와 backups 공유를 설정함
[docs]
path = /mnt/s16z1/docs
browseable = yes
read only = no
guest ok = no
valid users = john
create mask = 0755

[backups]
path = /mnt/s16z1/backups
read only = no
guest ok = no
inherit acls = yes
spotlight = yes
fruit:aapl = yes
fruit:time machine = yes
vfs objects = catia fruit streams_xattr
valid users = john
  • docs는 일반 목적의 SMB 공유로 구성됨
  • backups는 macOS Time Machine용 속성을 포함함
    • fruit:aapl = yes
    • fruit:time machine = yes
    • vfs objects = catia fruit streams_xattr
  • macOS에서는 Finder에서 cmd+K를 눌러 smb://10.0.0.6/docs 또는 smb://10.0.0.6/backups 형식으로 마운트함
  • Debian 계열 시스템에서는 smbclient를 설치한 뒤 다음처럼 테스트함
apt install smbclient
smbclient -U john //10.0.0.6/docs -c 'ls'
  • smb://10.0.0.6/backups를 마운트하면 macOS에서 Time Machine 공유로 표시됨
  • 마운트 후 macOS의 Settings > General > Time Machine에서 해당 공유를 추가해 Time Machine 백업을 시작할 수 있음

제외된 항목

  • 암호화 구성은 이 절차에 포함되지 않음
  • 백업 전략도 포함되지 않음
  • ZFS 데이터셋 복제 기능은 이후 별도 글에서 확장할 계획임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 가격 면에서 지금은 NAS 구축하기 좋은 시기가 아니지만, 지난 2주 동안 만들고 있음. Jonsbo N6 케이스를 쓰는데, 8개 SATA 백플레인과 드라이브 베이가 있어서 이전 Jonsbo 모델들과 달리 꽤 괜찮음
    결국 14TB WD Elements Desktop 4개를 적출해서 쓰기로 했고, 안에는 헬륨 충전 드라이브인 WD140EDGZ가 들어 있었음. 12TB WD Red Plus 4개보다 약 3분의 1 저렴하고 성능도 비슷해 보임. 보증은 확실한 단점이지만, 2년 보증 기간 중 고장 나면 다시 외장 케이스에 넣을 수도 있을 것 같음
    부팅 드라이브로 중고 256GB M.2 SSD를 넣었고, LUKS, TPM 키, 루트 ZFS를 함께 쓰면서 한 드라이브가 고장 나도 부팅이 막히지 않게 만드는 데 꽤 고생함. systemd-boot를 많이 배웠고 grub보다 훨씬 정상적으로 느껴짐
    ZFS에는 신화와 카고 컬트가 많다는 것도 느낌. 예를 들어 글에서는 ECC RAM을 언급하지만, ZFS가 스크럽 중 풀을 망가뜨리기 때문에 필수라는 건 신화에 가깝고, 올해는 특히 비쌈. ZFS에 RAM이 많이 필요한 것도 아니고 L2ARC도 RAM을 많이 쓰지 않음
    아직 dnodesize=auto를 둘지 고민 중인데, 관련 공포담이 있음: https://github.com/openzfs/zfs/issues/11353. 그리고 합리적인 가격에 zfs send를 지원하는 클라우드 스토리지 제공자를 찾기 어렵고, Rsync.net은 최근 최소 주문을 10TiB로 올려서 내 용도에는 너무 큼: https://www.rsync.net/products/zfsintro.html

    • “가격 면에서 좋은 시기가 아니다”는 말로는 부족함. 지금은 NAS를 만들기에 끔찍한 가격대임
      마법 같은 선택지가 있다면, AI가 전혀 없는 대신 스토리지가 AI 이전 가격의 10분의 1인 쪽을 거의 고르고 싶을 정도임
    • 8개 드라이브짜리 ZFS RAIDZ2 풀을 돌리고 있는데, ZFS의 여유 공간 권장 사항이 카고 컬트인지 실제인지 궁금함
      이미 중복성을 위해 드라이브 2개를 포기하고 있고, 실제로 최근 같은 배치로 보이는 SSD 2개가 연달아 죽어서 도움이 됐음. 그런데 성능과 안정성을 위해 최소 드라이브 하나 분량은 더 비워두라는 조언까지 따르면, 지금 가격에서는 꽤 아픔
    • “Debian 기반 NAS를 debootstrap하는 큰 스크립트”의 일부라도 공개되어 있는지 궁금함
      https://words.filippo.io/frood/와 https://0pointer.net/blog/fitting-everything-together.html를 보고 나서, 홈 서버/NAS를 mkosi/systemd로 구성하는 쪽을 살펴보고 있음. 서로 다른 구성들이 이 문제를 어떻게 푸는지 보는 게 흥미로움
    • LUKS와 TPM 키 조합이 실제로 잘 동작하는지 궁금함. 서버가 재부팅되면 TPM으로 루트 파일시스템을 잠금 해제할 수 있는지, /boot는 암호화되고 변조 방지도 되는지, evil maid 공격에도 버티는지 궁금함
      토끼굴인 건 알지만, 전부 해결했다면 정말 흥미로움
    • Samsung SSD 990 PRO 4TB NVMe SSD 4개가 개당 1100달러임. 아찔함
      https://www.samsung.com/us/memory-storage/nvme-ssd/990-pro-p...

  • NAS에서 유용했던 것들: avahi-daemon을 설치하면 Samba가 자동으로 SMB/CIFS를 DNS-SD로 macOS와 Linux 클라이언트에 광고함
    Windows 10 이상에서 SMB 1.0을 꺼둔 클라이언트의 Explorer 자동 발견을 위해서는 wsdd2를 설치하면 됨
    Linux 호스트명은 보통 소문자지만, Samba는 기본적으로 NetBIOS와 Avahi에 대문자로 시작하는 이름을 게시함. 신경 쓰이면 /etc/avahi/avahi-daemon.conf의 [server]에 host-name=something을 설정하고, /etc/samba/smb.conf의 [global]에 mdns name = mdns를 두면 됨
    macOS 클라이언트가 있다면 Samba 설정에서 vfs_fruit를 켜는 게 좋음: https://www.samba.org/samba/docs/current/man-html/vfs_fruit..... 호환성 이유도 있지만, 주로 fruit:model을 설정해서 Finder 사이드바에 재미있는 아이콘을 띄울 수 있음
    .DS_Store 생성을 막으려면 금지할 수 있음: https://ryanoberto.github.io/blog/2015/04/01/disabling-the-c.... fruit:resource = xattr로 Finder 설정을 확장 속성에 저장할 수도 있을 것 같지만 직접 해보진 않음
    macOS는 오래전에 AFP를 SMB로 대체한다고 했고 macOS 27에서 AFP 클라이언트 지원도 제거될 예정이지만, macOS의 SMB 클라이언트 지원은 여전히 꽤 형편없음. 그때까지는 Samba와 함께 Netatalk도 계속 돌릴 예정이고, Netatalk도 Avahi에 등록되며 macOS는 의미심장하게도 SMB보다 AFP를 우선 사용하므로 클라이언트가 자동으로 맞는 데몬에 붙음

    • Samba에서는 사용자 홈 디렉터리를 별도 항목으로 추가하는 게 좋음. 기본 homes 디렉터리 설정은 뭔가 강박을 자극함

  • 이런 NAS를 만들되 dm-integrity, mdadm, XFS라는 꽤 다른 기술로 구성한 내 블로그 글을 링크해도 적절할 것 같음. C/C++ 개발자로서 OpenZFS 개발을 가까이 따라보니, 거대한 기능에 집중하는 흐름과 SPL/별도 페이지 캐시 때문에 생기는 지속적인 문제가 안정성 측면에서 걱정스러웠음
    ZFS라는 만능 도구의 편리함 대신 초기 고생을 감수했지만, 지금은 선택에 매우 만족함
    https://world-playground-deceit.net/blog/2025/06/nas-setup-l...

  • NAS를 만들 때 같은 결론에 도달했음. 시스템은 Nix, RAID는 zfs, 실행하고 싶은 서비스는 docker compose면 충분했음
    https://www.splitbrain.org/blog/2025-08/03-diy_nas_on_nixos

    • 나도 NAS에 NixOS를 쓰고 있음. 컨테이너 관리는 Nix와 함께 quadlets, 즉 systemd가 관리하는 Docker 컨테이너를 살펴보는 게 좋음
    • 비슷하게 NixOS를 NAS로 쓰고 있는데, 점점 커져서 이제 다른 사람들과도 공유하려고 하는 중임. 다만 나는 MDADM 위에 BTRFS를 씀
      옷장 안의 시끄럽고 전기 많이 먹는 랙에 질려서, 결국 올인원 홈 서버이자 라우터가 됐음
      https://HomeFree.host

  • 여전히 Synology 비용을 내는 이유는, 디스크가 고장 나면 트레이를 빼고 디스크를 교체한 뒤 다시 넣고 위젯 몇 개만 클릭하면 끝나기 때문임. 제대로 재빌드될 거라는 걸 알고 있음
    디스크가 고장 나면 비프음이 나고 문제 디스크 근처 LED가 켜지기 때문에 해야 할 일도 알 수 있음
    글에서 설명한 것 같은 NAS를 만드는 건 쉽지만, 장기적으로는 데이터 손실 가능성이 훨씬 커짐
    그리고 “3번 디스크가 고장 났을 때 안전하게 교체하는 방법”을 다루지 않는 이런 가이드는 불완전하다고 봄. 디스크 고장을 어떻게 아는지까지 설명하지 않더라도 그 절차는 있어야 함

    • snooty가 Synology의 자동완성 오타인지, 아니면 다른 제품인지 궁금함
    • 그건 사실 ZFS가 정확히 그렇게 동작하는 방식임. 가이드가 완전하지 않은 건 맞지만, 배열 재빌드는 디스크를 교체하고 ZFS 명령 하나를 실행하면 됨
    • ZFS는 드라이브 고장을 다른 어떤 것보다 탄탄하게 처리함. Synology가 BTRFS 내장 RAID 기능 대신 BTRFS 아래 mdadm을 쓰는 데는 이유가 있고, mdadm은 장치 수준에서 동작함
      그래서 드라이브를 교체할 때 mdadm은 전체 드라이브를 다시 만들어야 하지만, ZFS는 실제 사용 중인 데이터만 다시 만듦
      zpool replace my_pool disk3 newdisk
    • ZFS에서는 “비프음과 LED” 부분만 빼면 이 절차가 완전히 사소해짐

  • 사람들이 ZFS와 보통 “NAS”라고 부르는 구성 요소들을 어디까지 밀고 가는 데는 이유가 있겠지만, 나는 Linux 머신의 ext4 단일 대용량 HDD에서 엄격한 NFSv3 설정을 돌리는 것만으로도 꽤 편했음
    어차피 깨어 있는 동안 항상 켜져 있는 주 시스템이고, 한 대의 전력과 오버헤드만으로 다른 기기들에 파일을 제공할 수 있음
    네트워크 설정은 기본적으로 제한적으로 유지하려고 해서, 주 머신에서 돌리는 보안 논점도 크게 걱정하지 않음. 아마 대단한 죄를 짓고 있는 걸 수도 있지만, 순수 NFSv3와 호환성을 위한 Samba만으로는 정말 부족한 걸까?

    • 먼저 단일 대용량 HDD의 백업이 있는지 궁금함. 그게 가장 큰 걱정임. 언젠가 그 HDD가 반드시 고장 날 텐데, 그때 계획이 무엇인지가 중요함
      사람들이 ZFS와 “NAS”를 택하는 주된 이유는 체크섬과 데이터 무결성 보호이고, 주 머신을 항상 깨워두고 싶지 않아서이기도 함
      스냅샷 같은 기능도 유용해서, 실수로 파일을 지우거나 덮어써서 데이터를 잃을 걱정을 줄여줌
      24시간 켜져 있는 주 머신을 NAS로 쓰는 것 자체는 문제 없다고 봄. 뭔가를 위해 억지로 살 필요는 없지만, 신뢰성과 비트 부패 보호가 걱정됨. 실제로 일어나며, ZFS 덕분에 직접 본 적도 있음
    • 그 구성에서는 단일 드라이브 저장 구조가 더 큰 문제임. 디스크 하나가 고장 나면 버틸 수 없고, 하드웨어가 조용히 데이터를 손상시키기 시작하면 모든 데이터가 위험해짐. 백업도 그 단일 하드디스크의 데이터를 기준으로 하고 있다는 전제임
      단순한 구성을 유지하고 싶다면 파일 해시 목록을 보관하고 주기적으로 검증하는 방법을 고려할 만함
      스냅샷을 지원하는 백업 프로그램도 쓰는 게 좋고, Restic이 괜찮은 선택임
      현재 디스크와 같은 크기의 하드디스크를 하나 더 사서 SnapRAID로 파일 무결성을 관리하거나, btrfs로 2디스크 미러를 구성하는 방법도 있음
    • 여러 머신이 동시에 읽고 쓰기 시작하면 한계에 부딪힘. 그래도 지금 필요한 걸 만들면 되고, 과하게 최적화할 필요는 없음

  • Cockpit은 NAS와 VPS 관리에 매우 유용했음. LLM 덕분에 설정 자체는 큰 문제가 아니더라도, 토글이 있는 대시보드와 정리된 로그가 있으면 편하고, SSH 없이도 휴대폰에서 셸 명령을 실행할 수 있음
    NAS에서는 백업/유지보수 cron 작업 결과를 쉽게 보고, Samba를 관리하고, 디스크 사용량을 모니터링할 수 있음. 특히 iPhone에서 Samba를 제대로 동작하게 만드는 건 정말 골치 아픔

    • SSH 없이 휴대폰에서 셸 명령을 실행한다면 Cockpit 인증은 어떻게 하는지 궁금함. 앞단에 기본 HTTP 인증을 두는 식인지?
      나는 서버 인증에서는 공개키/개인키 외의 방식으로 내려가는 대신, 결국 휴대폰에서 SSH가 가능하게 만들곤 했음. 이 부분은 약간 음모론적으로 조심하는 편임

  • 예전에 직접 NAS를 만들 때 이 글도 학습 자료로 썼음: https://xyny.art/blog/2026-building-nas/
    처음부터 NAS 만들기는 정말 재미있음. 주제 전체를 빠짐없이 다루는 “완전한 자료”가 없다는 게 작은 장애물이지만, 동시에 재미의 일부이기도 함
    내 글의 목적도 인터넷에 또 하나의 편향된 NAS 구성 “가이드”를 추가하는 데 가까움. 가이드라고 부르기엔 조심스럽지만, 같은 일을 다시 해야 한다면 분명 내 글부터 읽을 것 같음

  • 개념적으로 같은 걸 돌리지만 Debian 대신 FreeBSD를 씀. 더 낫거나 나쁘다기보다는 트레이드오프가 다르고, 결국 똑같이 잘 동작함

  • NAS를 다시 만들면서 ZFS 위의 NFS로 결정했음. 다만 목표는 글쓴이와 조금 다름. 저전력 CPU/메인보드를 쓰고, 장애 조치가 가능한 두 개의 별도 시스템을 만들어 고가용성 형태로 구성했음
    실제로 장애 조치와 데이터 복제를 처리하는 커스텀 소프트웨어도 작성했음. 테스트에서는 장애 조치 중 클라이언트의 쓰기가 몇 초 정도만 멈춤. 이 내용에 대한 글을 쓰면 관심 있을지 궁금함

답변달기