SnapRAID + MergerFS構成：任意サイズHDDを組み合わせたエコNAS

「手元に4TBのWD Red、8TBのSeagate IronWolf、そして新調した22TBのToshiba MGシリーズが余っている。これらを一つの巨大なストレージプールとして統合したい」――自作NASユーザーなら一度は直面する課題です。従来のRAID 5やZFSといった階層化ファイルシステムでは、全ドライブの容量を最小構成に合わせる必要があり、大容量ドライブのポテンシャルを活かしきれないジレンマがつきまといます。さらに、20TBを超える超大容量HDDが主流となった現在、RAIDリビルド中の高負荷と長時間を考慮すると、従来の冗長化手法には二次故障のリスクも伴います。この課題に対する最適解の一つが、SnapRAIDとMergerFSを組み合わせた構成です。異なる容量のHDDを仮想的に一本化し、パリティによるデータ保護と、ドライブ追加の柔軟性を極限まで高めた「エコNAS」の構築手法を紐解きます。既存の余剰ドライブを無駄にせず、低コストかつ拡張性に優れたストレージ環境を実現するための具体的な設計指針を提示します。

SnapRAIDとMergerFSによる「非対称ストレージ」の構造的理解

SnapRAIDとMergerFSを組み合わせた構成は、従来のRAID（Redundant Array of Independent Disks）とは根本的に異なる設計思想に基づいています。一般的なRAID 5やZFSなどのストライピング技術は、全てのディスクにデータを分散して書き込むため、ディスクの容量が統一されていることが前提となります。一方、SnapRAIDは「スナップショットベースのパリティ計算」を行い、MergerFSは「複数のファイルシステムを単一の仮想ディレクトリとして統合する」役割を担います。この組み合わせにより、4TB、8TB、16TBといった、容量や世代が異なる（ヘテロジニアスな）HDDを、あたかも一つの巨大なストレージプールのように扱うことが可能になります。

SnapRAIDの最大の特徴は、リアルタイムの書き込み保護ではなく、定期的な「同期（sync）」プロセスによってパリティを生成する点にあります。データの変更が発生した際、即座にパリティを更新するのではなく、あらかじめスケジュールされたタイミングで計算を行うため、HDDへの書き込み負荷を抑えつつ、バックグラウンドでの計算処理を管理できます。これにより、大量のデータ転送が発生するメディアサーバーや、アーカイブ用途のNASにおいて、システム全体のIOPS（Input/Output Operations Per Second）低下を防ぐメリットがあります。

MergerFSは、物理的に異なるマウントポイント（例: /mnt/disk1, /mnt/disk2）を、一つの論理的なパス（例: /mnt/storage）に集約する「Union Filesystem」として機能します。ファイルが書き込まれる際、MerFSのポリシー（mfs：最も空き容量が多いディスクを選択、epm：最も空容量の多いディレクトリを選択など）に従って、最適な物理ディスクへと振り分けられます。この仕組みにより、ユーザーは個別のディスク容量を意識することなく、単一の巨大なボリュームに対してファイル操作を行うことができます。

故障時の影響 | ディスク故障時、全データの再構築が必要 | 故障したディスクのファイルのみが消失対象 |

| 拡張性 | 構成変更には複雑なリサイズ作業を伴う | 新しいHDDを追加してマウントするだけで完了 | | パリティ更新 | 書き込みのたびにリアルタイム実行 | 定期的な同期（sync）によるバッチ処理 |

構成パーツの選定基準とハードウェア・スペックの最適化

SnapRAID + MergerFS環境を構築する場合、最も重要な判断軸は「パリティ用ドライブの容量」と「CPU/RAMの計算能力」です。SnapRAHDの仕様上、パリティディスクの容量は、データ用ディスクの中で最大の容量を持つものと同等、あるいはそれ以上である必要があります。例えば、18TBのSeagate IronWolf Proをパリティとして使用する場合、データ用ドライブには20TBなどのより大きなドライブを含めることはできません。この制約を理解した上で、将来的な拡張を見据えたプランニングが求められますます。

CPUについては、パリティ計算時の負荷を考慮し、高クロックかつマルチスレッド性能に優れたプロセッサを選定すべきです。特に大量の小規模ファイルを同期する際、ハッシュ計算（SHA-256等）のプロセスでCPUリソースを消費します。AMD Ryzen 7 9700X（8コア/16スレッド、最大5.5GHz）のような最新アーキテクチャを採用すれば、数TB規模の同期処理時間を大幅に短縮可能です。また、メモリに関しては、ファイルシステムのキャッシュ効率を高めるため、最低でも32GB（DDR5-4800以上）を推奨します。ECC（Error Correction Code）メモリ、例えばKingston DDR5 ECC Unbuffered DIMMを使用することで、長期間稼働するNASにおけるビット反転エラーのリスクを最小化できます。

ストレージデバイスの選定においては、信頼性の高いエンタープライズ・またはNAS向けHDDを選択することが鉄則です。

• パリティ用ドライブ: 最も大容量かつ高耐久なモデル（例: Seagate IronWolf Pro 20TB, WD Red Pro 18TB）。
• データ用ドライブ: 余剰在庫や安価な中古、あるいは異なる世代のHDDを混在可能。
• OS/キャッシュ用SSD: システムの応答性を確保するため、NVMe Gen4/Gen5 SSD（例: Samsung 990 Pro 2TB）をOS起動およびMergerFSのメタデータ管理用に割り当てます。

[電源ユニット（PSU](/glossary/psu)）の選定も、HDDの多本数構成においては見落とせない要素です。HDDがスピンアップする際の突入電流（Inrush Current）を考慮し、Seasonic FOCUS GX-850（850W, 80PLUS Gold）のような、高い電力安定性と容量を持つ製品を選定してください。1台のHDDにつき、起動時に約20W〜30W程度のピーク電力を想定しておくことが、システム全体の安定稼働に直結します。

実装における技術的落とし穴とトラブルシューティング

SnapRAID + MergerFS構成は柔軟性が高い反面、運用ルールを誤るとデータの整合性や可用性を著しく損なう「落とし穴」が存在します。最も頻繁に発生する問題は、SnapRAIDの「同期（sync）忘れ」です。SnapRAIDはリアルタイム保護ではないため、ファイルが追加・変更された後にsnapraid syncコマンドを実行していない状態では、パリティデータと実際のデータに乖離が生じます。この状態でHDDが故障した場合、最新の変更分は復元不可能な状態となります。これを防ぐには、systemdタイマーやcronを用いて、毎日または数時間おきに自動同期を実行するワークフローの構築が不可欠です。

もう一つの致命的な落とし穴は、「パリティドライブの容量不足」と「二次故障」のリスクです。前述の通り、パリティドライブはデータ用ドライブの最大値を超えられません。運用中に、既存の最大容量（例: 14TB）を超える新しいHDD（例: 18TB）を導入する場合、既存のパリティドライブを一度取り外し、より大容量のドライブへリプレースする作業が発生します。この際、一時的に保護機能が失われるため、慎重な手順が求められますとなる。また、再構築（rebuild）中には、残りの全ディスクに対して非常に高い読み込み負荷がかかります。このタイミングで別のディスクが故障する「二次故障」は、SnapRAID構成における最大の脅威です。

MergerFSの運用面では、「書き込みポリシーの不一致」による混乱に注意が必要です。

• ディレクトリ構造の不整合: 特定のドライブだけマウント解除された際、MergerFS上の仮想パスからは消えてしまうため、スクリプト等の絶対パス指定が壊れるリスクがあります。
• ディスクのスピンダウン問題: 省電力のためにHDDをスリープ（spin-down）させている場合、MergerFS経由のアクセス時にディスクの起動待ち（数秒〜十数秒のレイテンシ）が発生し、アプリケーションのタイムアウトを引き起こすことがあります。

パフォーマンスとコスト効率を最大化する運用戦略

SnapRAID + MergerFS構成の真価は、その圧倒的な「コストあたりの容量（$/TB）」の低さにあります。従来のRAID 5では、ディスク容量の1/Nがパリティとして失われますが、本構成ではパリティ用ドライブ1台分のみの容量を犠ryptに充てるだけで済みます。例えば、4TB, 8TB, 12TB, 16TBのHDDを使用する場合、RAID 5であれば16TBのディスクもすべて「パリティ＋データ」として計算されるため、利用可能容量は極めて少なくなりますが、SnapRAIDなら実質的に30TB（4+8+12）以上の有効容量を確保できます。

パフォーマンス面においては、書き込み速度のボトルネックを解消するための最適化が重要です。MergerFSは単なるファイルシステムの統合であるため、物理的な書き込み速度は各HDDの性能に依存します。大量の小規模ファイルを扱う場合、mergerfsのオプションとして cache.posix や dropcache を適切に設定し、OS側のページキャッシュを有効活用することで、体感速度を向上させることができます。また、頻繁に更新される「ホットデータ」については、MergerFSのプールから切り離し、NVMe SSD（例: Samsung 990 Pro）上の独立したファイルシステムで管理する「階層型ストレージ戦略」を推奨します。

コスト最適化の観点では、以下の構成例が非常に効率的です。

• Tier 1 (Hot Data): NVMe SSD (2TB) - OS, [Dockerコンテナ, データベース, 現在進行中の編集データ
• Tier 2 (Warm/Cold Data): SnapRAID + MergerFS Pool (計40TB+) - メディアライブラリ, バックアップイメージ, アーカイブ

運用コストを抑えるためには、監視の自動化も欠かせません。Scrutiny のようなツールを使用し、各HDDの温度（目安として45℃以下を維持）、セクタエラー数、再割り当て済みセクタ数をダッシュボードで可視化してください。また、パリティ計算の負荷が高い時間帯に、他のネットワークサービスやバックアップジョブが重ならないよう、リソース配分を調整するスケジュール管理も重要です。

最後に、運用における投資対効果（ROI）を最大化するには、「中古HDDの活用」と「新世代HDDへの段階的移行」の組み合わせが最強の戦略となります。信頼性が確認された中古の10TBクラスをデータ用として使いつつ、パリティドライブだけは最新の20TB超えモデルへ投資することで、低コストでありながら極めて高い拡張性と安全性を両立した「エコNAS」を実現できるのです。

SnapRAID + MergerFS構成におけるハードウェア・戦略の徹底比較

SnapRAIDとMergerFSを用いた「エコNAS」構築において、最も重要な意思決定は「どのドライブをパリティ（Parity）に割り当て、どのドライブをデータ用とするか」という点です。ZFSやBtrfsのようなRAID構成とは異なり、容量の異なるHDDを混在させられる柔軟性がある反面、ドライブごとの特性（回転数、書き込み方式、電力消費）を理解していないと、リビルド（再構築）時間の肥良大化や、システム全体の不安定化を招く恐れがあります。

ここでは、2026年現在のHDD市場における主要な選択肢と、構成戦略の違いを多角的な視点から比較・検証します。

1. 主要HDDラインナップのスペック・技術特性比較

SnapRAID環境では、パリティドライブには「最も大容量かつ信頼性の高いもの」を選定し、データドライブには「コストパフォーマンスに優れたもの」を配置するのが鉄則です。

SMR（Shingled Magnetic Recording）方式のドライブは、SnapRAIDのパリティ更新時（書き込み負荷が高い局面）において、書き込み速度が極端に低下する「書き込みの壁」が発生するため、パリティドライブへの採用は避けるべきです。

2. 用途別・構築シナリオの最適選択

NASをどのような用途で使用するかによって、MergerFSのプール構成とSnapRAIDの計算頻度を変える必要があります。

3. 性能 vs 消費電力のトレードオフ分析

24時間稼働するNASにおいて、電力消費は運用コストに直結します。特に大量のHDDを搭載する場合、スピンアップ時の突入電流とアイドル時の消費電力の差を考慮する必要があります。

| ドライブ・タイプ | 読み書き性能 (MB/s) | アイドル時消費電力 (W) | スピンアップ負荷 | コスト効率 | | :---စွာ | :--- | :--- | :--- | :--- | | 7,200rpm Enterprise | 250 - 280 MB/s | 7.0W - 9.0W | 高（電源容量に注意） | 低（高価なため） | | 5,400rpm NAS用 | 160 - 200 MB/s | 4.0W - 5.5W | 中 | 高（バランス重視） | | Helium充填型 HDD | 240 - 270 MB/s | 5.0W - 6.5W | 低 | 中（容量単価は安価） | | 2.5インチ HDD | 100 - 130 MB/s | 2.0W - 3.0W | 極めて低 | 低（容量不足） | | SATA SSD (キャッシュ用) | 500+ MB/s | 1.0W - 2.0W | 極めて低 | 低（コスト高） |

4. OS・ファイルシステム互換性マトリクス

SnapRAIDとMergerFSはLinux環境での運用が前提となります。使用するカーネルバージョンやファイルシステムとの相性を確認しておくことは、長期運用の安定性に不可欠です。

5. 国内流通価格帯と調達戦略の比較

2026年現在の、1TBあたりの取得コスト（Cost per TB）に基づいた調達手法の比較です。予算に応じて「新品の安心感」を取るか、「容量単価の安さ」を取るかの判断材料となります。

SnapRAID + MergerFS構成におけるハードウェア選定は、単なる「安さ」の追求ではなく、「パリティドライブへの投資」と「データドライブのコスト最適化」のバランスをどこに置くかが鍵となります。特に、容量の異なるHDDを組み合わせる際は、後述するリビルド時間の計算（再構築にかかる時間）を念頭に置き、パリティドライブには必ず最も信頼性の高いCMR方式の大型ドライブを選択するようにしてください。

よくある質問

Q1. 自作NASとSynology DS923+などの既製品、どちらが安上がりですか？

HDDを再利用できる点が最大のメリットです。例えば、手元にある4TBや8TBの古いHDDを流用すれば、初期費用を数万円単位で抑えられます。一方、Synologyのような完成品は導入が容易ですが、2ベイモデルでも5〜6万円、4ベイ以上になると10万円を超えることも珍しくありません。容量あたりのコスト（円/TB）を最小化したいなら、SnapRAID構成の方が圧倒的に有利です。

Q2. 大容量HDDを追加していく際の予算感は？

構成の柔軟性が高いため、一度に全て揃える必要はありません。まずは16TBのSeagate Exosなどの大容量ドライブを1本購入し、予算が許すたびにWD Red Proなどのドライブを継承していく運用が可能です。2TBや4TBといった小容量の余剰ドライブも混ぜられるため、数年かけてテラバイト単位で少しずつストレージを拡張していく、低コストな成長戦略を描けます。

Q3. ZFS（RAID-Z）構成と比較して、SnapRAIDを選ぶ決定的な理由は？

ZFSは全てのドライブを同じ容量で揃えるのが基本であり、異なるサイズの混在には不向きです。対してSnapRAIDとMergerFSの構成なら、4TB、8TB、14TBといったバラバラなサイズのHDDを柔軟に組み合わせられます。メディアサーバー用途など、書き込み速度よりも「とにかく安価に、テラバイト級の巨大な容量を確保したい」という目的には、ZFSよりもSnapRAIDの方が圧倒的に最適解となります。

Q4. RAID 5や6と比べて、運用上のデメリットはありますか？

最大のデメリットは「リアルタイム性」の欠如です。RAID 5などは書き込みと同時にパリティが更新されますが、SnapRAIDはsnapraid syncを実行したタイミングでしかパリティが更新されません。そのため、最新のデータ変更分は保護対象外となる時間が発生します。週に1回程度の同期スケジュールを組む必要がありますが、動画保存などのアーカイブ用途であれば、このデメリットは許容範囲内でしょう。

Q5. NVMe SSDとSATA HDDを同じプールに混在させることは可能ですか？

MergerFSを使用しているため、技術的には可能です。ただし、SSDの高速なレスポンスがHDDのシークタイム（約10ms程度）に引きずられる「ボトルネック」が発生します。例えば、Samsung 990 Proのような爆速NVMeをデータドライブに含めると、読み込み時にHDD側のスローダウンが発生し、期待したパフォーマンスが出ません。SSDはキャッシュ用やOS実行用の独立したプールとして運用するのが推奨されます。

Q6. 外付けUSB HDD（WD Elements等）を構成に組み込めますか？

可能です。MergerFSはディレクトリレベルでマウントするため、USB接続のドライブも認識できます。しかし、USBコントローラーの瞬断や電力不足による切断リスクがあるため、常用は避けるべきです。もし運用する場合は、セルフパワー式のUSBハブを使用するか、安定した電源供給が可能な製品を選んでください。エンタープライズ向けのSeagate Exosなどの内蔵SATA接続をメインに据えるのが最も安全な設計です。

Q7. パリティドライブ（Parity）が1台故障した場合、データはどうなりますか？

SnapRAIDのパリティ構成によりますが、パリティ用として指定したドライブが故障しても、残りのデータドライブ内のファイルは無事です。ただし、パリティ情報の再構築には多大な計算リソースと時間を要します。例えば18TBのHDDを復元する場合、CPU（Intel Core i5等）の性能によっては数日かかることもあります。この期間中に別のデータドライブが故障すると、全データを失うリスクがあるため、迅速な交換が必要です。

Q8. snapraid syncの実行頻度はどのくらいが適切ですか？

データ更新頻度によりますが、一般的には「毎日」または「週に数回」を推奨します。例えば、大量のRAW画像や4K動画を頻繁に保存する環境なら、24時間に一度の自動実行（cron利用）が理想的です。同期の間隔が空きすぎると、万が一の故障時に失われるデータ量（未保護分）が増大するためです。バックアップ作業と合わせて、深夜などのシステム負荷が低い時間帯にスケジュール設定するのが運用の定石です。

Q9. PCIe 5.0やDDR5メモリを採用した最新プラットフォームでの運用はどう変わりますか？

ストレージの物理的なボトルネックはHDD（SATA接続）にあるため、SnapRAID自体の処理速度に劇的な変化は起きにくいです。しかし、将来的に2.5GbEや10GbEといった高速ネットワークが普及する中で、HDDの限界を補うためにNVMe SSDをWrite-backキャッシュとしてMergerFS配下に配置する構成が主流になると予想されます。最新のDDR5メモリ環境であれば、大規模なファイルメタデータの処理もよりスムーズになります。

Q10. SMR方式（Shingled Magnetic Recording）のHDDは使用できますか？

パリティドライブ（Parity）として使用するのは避けるべきです。SMRはデータの書き換え時に隣接トラックも上書きする特性があるため、SnapRAIDのパリティ更新時に極端な書き込み遅延が発生し、同期が完了しないリスクがあります。データドライブとしての利用は可能ですが、システムの安定性を重視するなら、WD Red PlusやSeagate IronWolfなどのCMR方式を採用した製品を強く推奨します。

まとめ

• 異なる容量のHDDを組み合わせられるため、余剰ドライブを活用した極めて低コストなNAS構築が可能
• MergerFSにより、複数の物理ディスクを一つの大きなマウントポイントとして統合管理できる
• SnapRAIDのパリティ機能により、設定した数までのドライブ故障からデータを保護可能
• [RAID](/glossary/raid) 5/6のようなストライピングが発生しないため、ドライブ単体の読み書き性能が維持される
• 新しいHDDを追加する際も、既存データの再配置（リビルド）なしで容量拡張が行える
• パリティ更新はリアルタイムではないため、cronなどを用いた定期的な「sync」実行の自動化が運用の鍵となる

まずは手持ちの余剰HDDを整理し、小型の[SATAポートを備えた低消費電力なPCや、構築済みのLinuxサーバーでの実験的な導入から検討してみてください。