Synology、QNAP、TrueNASなしで最小限のZFS NASを構築する方法（2024）

 (neil.computer)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 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系システムではsudo apt install 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データセットのレプリケーション機能は、今後別の記事で拡張する予定

関連記事

1件のコメント

 
GN⁺ 4 시간 전
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 を併用しつつ、1台故障しても起動不能にならないようにするのにかなり苦労した。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台が立て続けに死んだので助かった。だが、性能と安定性のために少なくともドライブ1台分はさらに空けておけという助言まで従うと、今の価格ではかなり痛い
    • 「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台が1台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コマンドを1つ実行するだけでよい
    • ZFSはドライブ故障を他の何よりもしっかり処理する。Synologyが組み込みのBTRFS RAID機能ではなくBTRFSの下にmdadmを使っているのには理由があり、mdadmはデバイスレベルで動作する
      そのためドライブ交換時にはmdadmはドライブ全体を再構築しなければならないが、ZFSは実際に使われているデータだけを再構築する
      zpool replace my_pool disk3 newdisk
    • ZFSでは「ビープ音とLED」の部分を除けば、この手順は完全に些細なものになる

  • 人々がZFSや一般に「NAS」と呼ばれる構成要素をそこまで推し進めるのには理由があるのだろうが、自分はLinuxマシンのext4の単一大容量HDDで厳格なNFSv3設定を動かすだけでもかなり快適だった
    どうせ起きている間は常に電源が入っているメインシステムだし、1台分の電力とオーバーヘッドだけで他の機器にファイルを提供できる
    ネットワーク設定は基本的に制限的に保つようにしているので、メインマシンで動かすことのセキュリティ上の論点もあまり気にしていない。もしかすると大きな罪を犯しているのかもしれないが、純粋なNFSv3と互換性のためのSambaだけでは本当に足りないのだろうか？

    • まず、その単一大容量HDDのバックアップがあるのか気になる。それが最大の懸念だ。いずれそのHDDは必ず壊れるので、そのときの計画が重要になる
      人々がZFSや「NAS」を選ぶ主な理由は、チェックサムとデータ整合性保護、そしてメインマシンを常時起こしておきたくないからでもある
      スナップショットのような機能も便利で、誤ってファイルを削除したり上書きしたりしてデータを失う心配を減らしてくれる
      24時間稼働しているメインマシンをNASに使うこと自体は問題ないと思う。何かのために無理に買う必要はないが、信頼性とビット腐敗保護は気になる。実際に起こることで、ZFSのおかげで自分でも見たことがある
    • その構成では、単一ドライブのストレージ構造の方がより大きな問題だ。ディスク1台が故障したら耐えられず、ハードウェアが静かにデータを破損し始めたら全データが危険にさらされる。バックアップもその単一ハードディスクのデータを基準にしている前提だ
      単純な構成を維持したいなら、ファイルハッシュの一覧を保管して定期的に検証する方法を検討する価値がある
      スナップショットをサポートするバックアッププログラムも使うべきで、Resticは悪くない選択だ
      現在のディスクと同じサイズのハードディスクをもう1台買って、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を作ることは本当に楽しい。テーマ全体を漏れなく扱う「完全な資料」がないことは小さな障害だが、同時に楽しさの一部でもある
    自分の文章の目的も、インターネットにもう1つの偏ったNAS構成「ガイド」を追加することに近い。ガイドと呼ぶには慎重になるが、同じことをもう一度やるなら、きっと自分の文章から読み始めると思う

  • 概念的には同じものを動かしていますが、Debian の代わりに FreeBSD を使っています。より良いとか悪いとかいうよりトレードオフが異なるだけで、結局は同じようにうまく動きます

  • NAS を再構築するにあたって、ZFS 上の NFS に決めました。ただし目標は筆者と少し異なります。低消費電力の CPU/マザーボードを使い、フェイルオーバー可能な 2 つの独立したシステムを作って、高可用性構成にしました
    実際にフェイルオーバーとデータ複製を処理するカスタムソフトウェアも書きました。テストでは、フェイルオーバー中もクライアントの書き込みは数秒止まる程度です。この内容について記事を書いたら興味がありますか