ZFSでNASを構築する 2026 — RAIDZ/スナップショット/スクラブの実践ガイド

RAIDZ構成の選択と適切なディスク数の計算

NASの信頼性を確保するためのRAID構成において、2026年の推奨は「RAIDZ2」または「ミラー（Mirror）」です。結論として、4台以上のドライブを使用する場合はRAIDZ2を選択し、2台のみの場合はミラーを構成するのがベストプラクティスです。

RAIDZ1は、1台の故障に耐えることができますが、ディスク数が増えるほど再構築（Resilver）時の負荷が高まり、その間に別のディスクが故障するリスクが増大します。例えば、8台のHDDを使用する場合、RAIDZ1では2枚の同時故障で全データが消失します。これに対しRAIDZ2は、2台までの同時故障を許容するため、現代の高容量（16TB〜24TB以上）なHDDを使用する環境では非常に安全性が高いです。

ミラー構成（Mirror）は、2台のディスクをペアにしてデータを複製する仕組みです。これは「vdev」として構築され、複数のミラーを並列に連結することで高いパフォーマンスと冗長性を両立します。例えば、8台のディスクを4つのミラーとして構成すれば、1つまたは2つの故障に対して耐えつつ、読み込み速度を向上させることができます。

RAIDZ構成比較表（実用的な選択肢）

実践的なプール作成とデータセットの構造化

ZFSの構築において、物理的なディスクをまとめる「プール（zpool）」と、論理的に分割する「データセット」を明確に分けることが重要です。結論として、まず適切なRAIDZ構成でプールを作成し、その上に用途ごとにデータセットを重ねる設計が推奨されます。

プール作成の例として、4台の8TB HDD（sda, sdb, sdc, sdd）を使用してRAIDZ2を構築する場合、コマンドは以下のようになります。 zpool create tank raidz2 sda sdb scd sdd この「tank」という名前は慣習的に使われるものですが、用途に合わせて変更可能です。ここで重要なのは、物理的なディスクのパス（/dev/sdaなど）ではなく、UUIDやデバイス名（/dev/disk/by-id/...）を使用することです。これにより、OS再起動時にドライブが入れ替わってもプールを正しく認識できます。

データセットは、用途ごとに作成します。例えば、メディア用、バックアップ用、システム用などで分けることで、それぞれに異なる圧縮率やレプリカ設定を適用できます。 zfs create tank/data/media zfs create tank/data/backup このように階層化することで、管理が容易になるだけでなく、特定のデータセットだけをスナップショットの頻度を変えて保存するといった高度な運用が可能になります。

スナップショットと自動バックアップの仕組み

ZFSにおけるスナップショットは、データのコピーを作成せずに瞬時に状態を固定する機能であり、NAS運用において最も強力な防御策となります。結論として、毎日または毎時単位の自動スナップショットを設定し、さらに「sanoid」などのツールを併用することで完全な履歴管理を実現できます。

スナップショットの基本コマンドは以下の通りです。 zfs snapshot tank/data@daily_2026_05_20 この「@」以降の部分が名前になります。手動でこれを行うのは現実的ではないため、TrueNASやUbuntuではcronやsystemdタイマーを組み合わせて自動化します。また、特定のデータセットに対して、数日前のものを自動的に削除するローテーション処理も重要です。

より高度な管理には「sanoid」というツールの活用があります。これはZFSの機能をラップし、スナップショットの作成、保持期間の管理、および不整合の検知を自動化します。特にProxmoxやUbuntu Serverで構築する場合、sanoidを導入することで「3日前のものを常に残す」「1週間前まで毎日残す」といったポリシーを容易に実装でき、ランサムウェア攻撃を受けた際の迅速な復旧を可能にします。

スクラブ（Scrub）とデータの自己修復プロセス

ZFSの信頼性を維持するための最も重要なメンテナンス作業が「スクラブ（Scrub）」です。結論として、全プールに対して少なくとも月1回は自動でスクラブを実行するスケジュールを設定することが強く推奨されます。

スクラブとは、ファイルシステム内のすべてのブロックをスキャンし、チェックサムと照合するプロセスです。もしデータの破損やビット反転（磁気媒体の劣化など）が見つかった場合、ZFSはミラーやRAIDZの冗長データを使用して自動的に修復を行います。この動作は「自己修復（Self-healing）」と呼ばれ、従来のRAIDでは検知すらできなかった静かなデータの腐敗を防ぎます。

スクラブ実行時のコマンド例： zpool scrub tank これにより、システムは全データを精査します。特に大容量HDDを採用している場合、バックグラウンドで定期的にこの処理を行うことで、ディスクの物理的な劣化を早期に発見し、致命的な故障に至る前に交換の判断を下すことができます。

高速化のためのキャッシュ戦略：ARC, L2ARC, SLOG

ZFSはメモリを非常に効率的に活用する設計となっており、NASのパフォーマンスを最大化するための3つの主要なキャッシュ機構があります。結論として、メインメモリには「ARC」、高速なSSDには「L2ARC」、同期書き込みの加速には「SLOG」を割り当てるのが理想的な構成です。

1. ARC (Adaptive Replacement Cache): ZFSは標準的なLinuxカーネルのページキャッシュではなく、独自のARCを使用します。これは単に最近使ったデータを残すだけでなく、頻度と新しさの両方を考慮してキャッシュを最適化します。一般的に、システムが利用可能なメモリの50%〜80%をARCに割り当てることが推奨されます。例えば、64GBのRAMを搭載している場合、約32GB〜50GBが自動的にZFSの高速読み込みに使用されます。

2. L2ARC (Level 2 ARC): ARCの容量を物理的なメモリで確保できない場合や、より広大なキャッシュ領域が必要な場合にNVMe SSDなどの高速ストレージを「第2のキャッシュ」として使用します。L2ARCは、頻繁にアクセスされるデータがRAMから溢れた際に、SSDから高速に提供するための層です。

3. SLOG (Separate Log): これは読み込み加速ではなく、「同期書き込み（Synchronous Writes）」を高速化するための専用デバイスです。データベースやNFS共有など、データの完全性が極めて重要な操作において、意図的な遅延を最小限にするために非常に高速なNVMe（Optane等）をSLOGに割り当てます。

容量計画と実効容量の計算（2026年最新モデル）

ZFSを導入する際、最も注意すべきは「実効容量」の計算です。結論として、RAIDZ構成ではパリティ（冗長データ）分が差し引かれるため、物理的な合計容量よりも少ない容量しか利用できないことを常に意識する必要があります。

例えば、8TBのHDDを4台使用してRAIDZ2を構築する場合、式は以下のようになります： （ディスク数 - 冗長性）× 容量 = 実効容量 (4 - 2) × 8TB = 16TB この場合、物理的な合計は32TBですが、実際にユーザーが使えるのは約16TBとなります。ZFSではさらに「予約領域」や「メタデータ」のために数パーセントの余裕を持つことが推奨されるため、実効容量の約90%程度を最大使用量と考えるのが安全です。

また、ZFSは「オーバープロビジョニング（過剰供給）」に対応していますが、プール内の使用率が80%を超えるとパフォーマンスが著しく低下する特性があります。これはCoWアルゴリズムにより、新しいデータを書き込む際に空きブロックを探すための処理が増大するためです。そのため、計画段階で常に20%程度のバッファを持たせるのが理想的です。

ストレージ構成例（容量計算）

高度な管理と運用：データセットの最適化

ZFSを単なるRAIDの代替としてだけでなく、高度なファイルシステムとして活用するには「データセット」の適切な設計が不可欠です。結論として、用途に合わせて圧縮アルゴリズムやアトマスク（A-type）を設定することで、ストレージ効率とパフォーマンスを最大化できます。

まず、現代のNASにおいてLZ4圧縮は必須の設定です。LZ4は非常に軽量なCPU負荷で動作し、テキストデータや多くのメディアファイルのメタデータを圧縮します。これにより、実質的な書き込み量を減らし、ディスク寿命を延ばす効果があります。 zfs set compression=lz4 tank/data

次に、**レコードサイズ（recordsize）**の調整です。これは1つの論理的なファイルが物理的に分割される単位です。例えば、多数の小さなファイル（写真やドキュメント）を保存するデータセットには16K〜32K、大きな動画ファイルを扱うデータセットには1Mなどの値を設定することで、ブロックの断片化を防ぎ、読み取り効率を高めることができます。

さらに、**レプリカ（Replication）**機能の活用も検討すべきです。これは別の物理サーバーやNASへ、特定のデータセットを定期的にコピーする機能です。スナップショットをベースにコピーを行うため、ネットワーク帯域を消費せずに「別拠点へのバックアップ」を実現できます。これができるのはZFSがファイルシステムレベルでオフセットを管理しているためであり、従来のrsyncなどよりも効率的です。

2026年におけるハードウェア選定のポイント

ZFSを動かすNASにおいて、ハードウェアの選択はソフトウェアの性能を左右します。結論として、メモリ容量の確保と、可能であればECC（Error Correction Code）メモリの採用が推奨されます。

まず「メモリ」についてです。ZFSはARCを利用するため、最低でも16GB、4K以上の解像度のメディアサーバーや複数の仮想マシンを動かす場合は32GBから64GBを推奨します。また、前述したようにECCメモリは、ビット反転によるデータ破損を防ぐための機能ですが、現代のx86_64プロセッサ（Intel Core/Xeon, AMD Ryzen/EPYC）では非ECCメモリでも高い安定性を誇むため、家庭用・小規模ビジネス用途であれば必須ではありません。しかし、企業レベルでの信頼性を求めるならECC対応のプラットフォームを選択するのが標準です。

次に「コントローラ」についてです。ZFSは**HBA（Host Bus Adapter）**を介して直接ディスクを制御することを前提としています。従来のRAIDカード（RAID 0,1,5,10など）を使用すると、ハードウェアレベルでの抽象化によりZFSが各ドライブの個別の状態を認識できず、スクラブや自己修復機能が正常に動作しません。そのため、LSI Logic製のITモード（Initiator Target）に書き換えられたHBAカード（例：LSI 9211-8i等）を使用するのが一般的です。

最後に「ドライブ」の選択です。NAS用途では、高回転（7200rpm）かつ大容量なヘリウム充填型HDDが主流です。特にWD Red PlusやSeagate IronWolf Proといった、NAS環境での連続稼働を想定した製品は、振動耐性やMTBF（平均故障間隔）の面で優れています。また、前述のSLOG用には、高耐久なNVMe SSDを採用することで、システム全体の応答性を劇的に向上させることができます。

ZFS構築における重要なコマンドと設定一覧

運用をスムーズにするために、頻繁に使用するコマンドや設定項目をまとめます。これらの操作は、TrueNASなどのGUIではメニューとして提供されますが、スクリプトによる自動化を行う際は重要になります。

基本管理コマンド

高度な最適化設定

• xattr:sas_space: ネットワークファイルシステム（NFS）経由でアクセスする際に、属性情報の扱いを最適化します。
• atime=off: ファイルへの「アクセス時刻」を更新しないようにし、メタデータの書き込み回数を減らします。
• compression=zstd: より高い圧縮率を求める場合に使用（LZ4よりもCPU負荷が高い）。

構築時の注意点とトラブルシューティング

ZFS構築において初心者が陥りやすい罠がいくつかあります。これらを事前に把握することで、スムーズな運用が可能になります。

まず、「既存のHDDに古いファイルシステムが残っている場合」です。中古のハードディスクや以前別のOSで使用していたドライブを接続する場合、パーティションテーブルや署名（Signature）が残っていると、ZFSが誤って認識することがあります。導入前にwipefs -a /dev/sdXを実行し、ディスクを完全にクリーンにする工程が必要です。

次に、「デバイス名の固定」です。/dev/sdaといった名前はOS起動時に変わる可能性があるため、必ず/dev/disk/by-id/配下の識別子を使用してください。これにより、ハードウェアの再接続や追加時にプールが消失するトラブルを防げます。

最後に、「リサイズに関する制限」です。ZFSのVDEV（ボリューム要素）は、一度作成すると横方向への拡張（ディスクの追加による容量増加）が困難な設計になっています。そのため、将来的に容量不足を予測する場合は、最初から十分なサイズのHDDを選択するか、複数のプールを作成して管理する戦略が必要です。

まとめ

ZFSを用いたNAS構築は、初期設定に高度な知識が必要ですが、一度構築すれば極めて高い信頼性と利便性を提供します。本記事の要点は以下の通りです。

• 堅牢なデータ保護: Copy-on-Writeとチェックサムによる自己修復機能により、ビット反転やハードウェア故障からデータを守ります。
• 推奨される構成: 4枚以上のHDDを使用する場合はRAIDZ2を選択し、冗長性と容量のバランスを取ることが推奨されます。
• スナップショットの活用: ZFSネイティブのスナップショットとsanoid等のツールを組み合わせ、バックアップ体制を強固にします。
• キャッシュ戦略: ARC（メモリ）、L2ARC（SSD）、SLOG（NVMe）を適切に使い分けることで、システム全体のレスポンスを最大化します。
• 適切なメンテナンス: 月1回のスクラブ実行により、ハードウェアの劣化を早期検知し、予期せぬデータ消失を防ぎます。
• メディア特化の設定: 録画や動画配信を行う場合は、レコードサイズを大きくし、LZ4圧縮を有効にすることで効率を高めます。

よくある質問（FAQ）

Q1: ZFSを使うメリットは何ですか？ A1. 最大のメリットは「データ整合性の保証」です。チェックサムによる自動修復とスナップショット機能により、ハードウェア故障や操作ミスからの復旧が非常に容易になります。

Q2: RAIDZ1とRAIDZ2のどちらを選ぶべきですか？ A2: 2026年現在の高容量HDD環境では、RAIDZ2を強く推奨します。RAIDZ1は1台の故障しか耐えられず、リビルド中のリスクが高いためです。

Q3: ZFSにはどれくらいのメモリが必要ですか？ A3: 最小で8GBですが、実用的なNASとしては16GB以上を推奨します。ZFSはARCという仕組みでメモリをキャッシュに使うため、多くあれば多いほど読み込みが高速化されます。

Q4: HDDの容量を増やしたい場合、後から追加できますか？ A4: ZFSではVDEV（ボリューム要素）へのディスク追加による容量拡張には制限があるため、最初から十分な容量のHDDを選ぶか、別のプールを作成してマウントする運用が一般的です。

Q5: スナップショットはストレージを消費しませんか？ A5: データの変更がない部分は共有されるため、変更分だけを消費します。しかし、頻繁に更新されるデータ（データベースなど）に対して大量のスナップショットを取ると容量を圧迫するため注意が必要です。

Q6: ZFSのスクラブは毎日やるべきですか？ A6: 毎日行う必要はありません。通常、週に1回または月に1回程度の自動スケジュールで実行すれば十分です。

Q7: NVMe SSDをL2ARCとして使うと本当に速くなりますか？ A7: はい、特に頻繁にアクセスするがメモリ(ARC)には収まりきらないデータがある場合、NVMeを使用したL2ARCは非常に効果的な高速化手段となります。

Q8: TrueNAS SCALEとProxmoxのどちらが良いですか？ A8: 構築の容易さと管理機能の充実を求めるならTrueNAS SCALE、仮想化技術を駆使した高度なインフラを構築したいならProxmoxが適しています。

Q9: HDDの寿命を延ばすためにZFSにできることはありますか？ A9: LZ4圧縮を有効にすることで、物理的な書き込み量を減らし、ディスクへの負荷を軽減することができます。

Q10: ZFSで構築したNASは外部からアクセスできますか？ A10: はい、可能です。TrueNASやU[bun](/glossary/bun-runtime)tu等のOS上でSamba（SMB）やNFSの設定を行うことで、通常のNASと同様にネットワーク越しに共有できます。

NASと分散ストレージで作るセルフホスト基盤を、セルフホストの実務目線で解説。ZFS/Btrfs、NVMe-oF、RAID、10GbE運用まで2026年の最新動向に沿って整理します。