ZFS自作NAS構築｜TrueNAS Scale実践ガイド2026

20TBを超える大容量HDDがストレージの標準となった現在、自作NASにおけるデータ保護設計の難易度は飛躍的に上昇しています。Intel N100搭載ベアボーンにLSI 9300-8i（IT mode）を組み合わせた省電力構成であっても、RAIDZ1の選択ミスや不適切なrecordsize設定は、ドライブ故障時の致命的なデータ消失や、IOPSの大幅な低下を招くリスクを孕んでいます。LZ4とzstdの圧縮効率の差、Special VDEVによるメタデータ高速化、L2ARCの導入限界といったZFS特有の最適化項目は多岐にわたり、単なる「ディスクの束」としての構築では、真のパフォーマンスを引き出すことは不可能です。TrueNAS Scaleを用いた実践的なプール設計から、RAIDZレベルの選定、さらにはSnapRAIDとの運用比較までを網羅し、電力効率と容量密度、そして強固な可用性を両立させるためのエンジニア視点での最適解を提示します。

ZFSアーキテクチャの再定義：RAIDZ構成と圧縮アルゴリズムの選択

ZFS（Zettabyte File System）の本質は、単なるRAID構成ではなく、チェックサムによるデータ整合性保護と、Copy-on-Write (CoW) 構造に基づいたスナップショット機能の統合にあります。TrueNAS Scaleを用いた構築において、最初に決定すべきはVDEV（Virtual Device）の設計、すなわち「どの冗長性レベルを選択するか」です。202/20TBを超える大容量HDDが主流となった現在、リビルド（Resilvering）にかかる時間は数日単位に達することもあり、RAIDZ1の選択には極めて慎重な判断が求められます。

RAIDZ1は、1台のディスク故障までを許容しますが、リビルド中に第2のディスクにエラーが発生した際、プール全体が消失するリスクがあります。一方、RAIDZ2は2台の同時故障まで耐えうるため、現在の高密度ストレージ構成におけるスタンダードです。さらに、IOPS（Input/Output Operations Per Second）を最優先し、データベースや仮想マシン（VM）のイメージを格納する場合は、Mirror構成を選択すべきです。Mirrorは容量効率こそ低いものの、読み取り性能と書き込み遅延の低減において圧倒的な優位性を持ちます。

また、ZFSのパフォーマンスを左右するもう一つの要素が圧縮アルゴリズムの設定です。デフォルトのlz4はCPU負荷が極めて低く、ほとんどのワークロードで恩恵を受けられますが、より高い圧縮率を求める場合はzstd（Zstandard）の検討が必要です。ただし、zstdは圧縮レベルの設定（1〜22）によって計算コストが劇的に変化するため、ネットワーク帯域やCPUクロック数とのバランスを考慮しなければなりません。

ハードウェア選定の決定軸：低消費電力N100からHBA拡張まで

自作NASのハードウェア設計において、202（20）TBクラスのHDDを運用する場合、CPUの計算能力よりも「I/Oパスの安定性」と「電力効率」が重要になります。近年、エントリークラスの構築ではIntel Core i3-N100搭載のベアボーンキットが主流です。N100はTDP 6Wという驚異的な低消費電力を実現しつつ、SATAポートを4基備えた構成が多く、24時間稼働させるNASにおいて年間電気代を抑える強力な選択肢となります。

しかし、ドライブ数を8台以上に拡張する場合、マザーボード上のSATAポートだけでは不足します。ここで必要となるのが、HBA（Host Bus Adapter）です。LSI SAS 9300-8iなどのSASコントローラを「IT mode（Initiator Target mode）」で導入することで、ZFSが各ドライブの物理的なSATA/SAS信号を直接制御可能になり、ZFS本来の高度な管理機能を損なうことなくドライブ数を拡張できます。この際、HBA自体が消費する電力（約10W〜15W）や発熱量にも注意が必要です。

メモリについても妥協は許されません。ZFSのキャッシュ機構であるARC（Adaptive Replacement Cache）は、物理RAMを最大限に活用します。DDR5-4ert 4800MHzクラスのECC UDIMMを使用することで、ビット反転によるデータ破損を防ぎつつ、高速なメタデータ処理を実現できます。

推奨ハードウェア構成例：

• CPU: Intel Core i3-N100 (4C/4T, 6W) または AMD Ryzen 7 9700X (65W, 高い圧縮性能を求める場合)
• HBA: LSI SAS 9300-8i (IT Mode Flashed) - 8ポートSAS/SATA拡張用
• RAM: 32GB〜64GB DDR5 ECC UDIMM (ARCの容量確保のため重要)
• Boot Drive: Samsung 990 Pro 500GB NVMe (OSおよびシステムログ用)
• Storage HDD: Seagate IronWolf Pro 20TB (CMR方式必須)
• Cache/Special VDEV: Crucial T705 1TB Gen5 NVMe (メタデータ高速化用)

実装の落とし穴：Recordsize、L2ARC、およびSpecial VDEVの誤用

ZFS構築における最大の「ハマりどころ」は、recordsize（レコードサイズ）の設定ミスです。デフォルトの128KBは一般的なファイル共有には適していますが、例えば4KB単位で書き込みが発生するデータベースや仮想マシンイメージを格納する場合、この設定では「Write Amplification（書き込み増幅）」が発生し、HDDの寿命とパフォーマンスを著しく低下させます。逆に、動画配信などのシーケンシャルな読み書きが主体の場合は、1MB程度まで引き上げることでスループットを向上させることが可能です。

次に注意すべきはL2ARC（Level 2 Adaptive Replacement Cache）の導入です。SSDをキャッシュとして追加することで、HDDの低速なランダムアクセスを補完できますが、RAM容量に対して過大なL2ARCを設定すると、逆に「キャッシュ内のメタデータ管理」にメモリが消費され、メインのARC領域を圧力的圧迫し、システム全体のパフォーマンスが低下する現象が発生します。L2ARCはあくまで「RAMの補助」であり、RAM不足を補う魔法の手段ではありません。

さらに、最新の最適化手法として注目されているのが「Special VDEV」です。これは、メタデータや小さなファイル（Small Blocks）のみを高速なNVMe SSDに書き込む仕組みです。これにより、HDDへのシーク回数を劇的に減らすことができますが、このVDEVが故障するとプール全体が破壊されるため、必ずMirror構成のSSDで行う必要があります。

設定ミスと対策一覧：

• Recordsize不一致:
  • 症状: 書き込み遅延の増大、ディスク寿命の低下。
  • 対策: アプリケーションのI/Oサイズに合わせ、16K〜1Mの間で調整。
• L2ARC過剰投入:
  • 症状: ARCヒット率の低下、システムレスポンスの悪化。
  • 対策: RAM容量の5%〜10%程度のNVMe SSDを上限とする。
• Special VDEVの単一構成:
  • 症状: SSD故障による全データ喪失。
  • 対策: 必ず2枚以上のSSDを用いたMirror構成で構築。

パフォーマンスとコストの最適化：SnapRAIDとの比較と運用戦略

TrueNAS Scale（ZFS）を運用するにあたって、Unraidなどの「SnapRAID」を利用したシステムとの比較検討は避けて通れません。SnapRAIDは、ディスクごとに独立してパリティ計算を行うため、ドライブの増設が容易で、異なる容量のHDDを混在させやすいというメリットがあります。しかし、SnapRAIDは「書き込み時に即時パリティ計算を行わない（同期プロセスが必要）」という特性があり、リアルタイムなデータ保護には向きません。

一方、ZFSはCoWによるスナップショットと、スクラブ（Scrub）による継続的な整合性チェックが可能です。運用面では、週に一度のzfs scrubをスケジュールし、データの静かな腐敗（Silent Data Corruption）を検知する体制を整える必要があります。この際、スクラブ実行中はI/O負荷が高まるため、業務時間外の設定が鉄則です。

コスト効率を最大化するには、容量単価の低いHDD（例：WD Red Pro 20TB）をRAIDZ2で構成しつつ、メタデータのみを高速なNVMe SSDへ逃がす「ハイブリッド設計」が最も費用対効果に優れています。電力コストについても、N100のような低TDPプロセッサを採用することで、年間での電気代差額は数千円から一万円以上に達することもあります。

ZFS vs SnapRAID 比較表