容量の異なるハードドライブが混在する悩み
ホームラボ愛好家の多くは、同じような状況からスタートします。引き出しの中に古いハードドライブが山積みになっているのです。古いデスクトップから取り出した2TB、セールで購入した4TB、そして最近奮発して買った10TBなど、容量はバラバラかもしれません。
中央ストレージサーバーを構築しようとすると、大きな壁にぶつかります。RAID 5やRAID 6といった従来のRAIDレベルでは、すべてのドライブを同じサイズにする必要があるからです。もし2TB、4TB、10TBのドライブを標準的なRAID 5アレイに組み込むと、すべてのドライブが最小の2TBとして扱われ、膨大なスペースが無駄になってしまいます。
私が最初のメディアサーバーを構築したときも、まさにこの状況に直面しました。手元には、年数も容量もバラバラなドライブのコレクションがありました。データの冗長性は欲しかったのですが、使い始めるためだけに10TBのドライブを5台も揃える余裕はありませんでした。私が求めていたのは、新しいディスクを追加するたびにデータを消去することなく、安価なハードウェアを見つけたときに随時拡張できるシステムでした。
根本的な原因：なぜ従来のRAIDはホームラボに向かないのか
核心的な問題は「ブロックレベルのストライピング」にあります。ZFSやハードウェアRAIDコントローラーのようなシステムは、データを細切れ（チャンク）にしてすべてのディスクに分散させます。これは、速度が最優先されるエンタープライズ環境では非常に優れています。しかし、家庭環境では主に3つの大きな問題を引き起こします。
- 柔軟性の欠如： ZFSのvdevやRAID 5アレイに、後からディスクを1台だけ追加するのは非常に複雑でリスクが伴います。
- ディスクのスピンアップ： RAIDアレイでは、たとえ小さなテキストファイルを1つ読み取るだけでも、すべてのディスクをスピンアップさせる必要があります。これは消費電力、熱、そしてドライブの摩耗を増加させます。
- 全か無かの故障： パリティが許容する以上のドライブ（RAID 5なら2台など）を失うと、アレイ全体が失われます。残された正常なドライブにあるデータも、ファイルの断片しか含まれていないため、復旧不可能なゴミとなってしまいます。
ソリューションの比較
現在のセットアップに落ち着く前に、いくつかの選択肢を検討しました。UnRAIDは混在ドライブをうまく扱えるため人気がありますが、プロプライエタリなソフトウェアであり、有料ライセンスが必要です。TrueNAS (ZFS)は非常に安定しており多機能ですが、ハードウェア要件が厳しく、拡張ルールが固定的なため、バラバラのディスクを持つ予算重視のホビーユーザーには不向きです。
そこで行き着いたのが、MergerFSと**SnapRAID**の組み合わせです。MergerFSが「プーリング」（複数のドライブを1つの大きなドライブに見せること）を担い、SnapRAIDが「パリティ」（ドライブ故障からデータを保護すること）を担います。私はこのアプローチを本番環境で運用してきましたが、結果は一貫して安定しており、柔軟性と安全性の完璧なバランスを実現しています。
最適なアプローチ：2層構造のストレージスタック
これから構築するのは、データが標準的なLinuxファイルシステム（Ext4やXFSなど）上に保存されるシステムです。つまり、万が一OSが故障しても、ドライブを別のコンピュータに接続すれば直接データを読み取ることができます。MergerFSを使用して統合されたマウントポイントを作成し、SnapRAIDを使用してスケジュールに基づいてパリティを計算します。
ステップ1：ドライブの準備
このチュートリアルでは、3台のデータドライブと1台のパリティドライブがあることを想定します。重要： パリティドライブは、最大のデータドライブと同じか、それ以上の容量である必要があります。
lsblkを使用してドライブを特定します。ここでは、以下の場所にフォーマット・マウントされていると仮定します。
- /mnt/disk1 (4TB データ用)
- /mnt/disk2 (4TB データ用)
- /mnt/disk3 (8TB データ用)
- /mnt/parity1 (8TB パリティ用)
ステップ2：MergerFSのインストールと設定
MergerFSはFUSEベースのユニオンファイルシステムです。データを変更するのではなく、データの仮想的なビューを作成するだけです。Ubuntuにインストールします。
sudo apt update
sudo apt install mergerfs次に、/etc/fstabを編集してプールを作成します。「disk」で始まるすべてのディスクを、/mnt/storageという1つのフォルダにまとめます。
# MergerFS用の/etc/fstabエントリ
/mnt/disk* /mnt/storage fuse.mergerfs defaults,nonempty,allow_other,use_ino,cache.files=off,moveonenospc=true,dropcacheonclose=true,category.create=mfs 0 0category.create=mfsオプション（Most Free Space：空き容量が最大のディスク）は、MergerFSに対して、最も空き容量の多いディスクに新しいファイルを書き込むよう指示します。これにより、ドライブの使用率が自動的にバランスよく保たれます。
プールをマウントします：
sudo mkdir /mnt/storage
sudo mount -aステップ3：SnapRAIDのインストールと設定
SnapRAIDはリアルタイムRAIDではありません。ファイルに基づいてパリティ情報を計算し、それをパリティドライブに保存します。これは、ファイルが頻繁に変更されないメディアライブラリに最適です。
SnapRAIDをインストールします：
sudo apt install snapraid次に、/etc/snapraid.confを編集してSnapRAIDを設定します。パリティファイルの場所、コンテンツファイル（データベース）の場所、およびデータディスクの場所を定義する必要があります。
# パリティの場所
parity /mnt/parity1/snapraid.parity
# コンテンツファイルの場所（異なるドライブに複数のコピーを保持してください！）
content /var/snapraid/snapraid.content
content /mnt/disk1/.snapraid.content
content /mnt/disk2/.snapraid.content
# データドライブ
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/
# 一時ファイルとゴミ箱を除外
exclude /lost+found/
exclude /tmp/
exclude .AppleDB
exclude .Thumbs.dbステップ4：初期同期の実行
設定が完了したら、パリティを生成する必要があります。ディスクにすでにあるデータの量によって、これには時間がかかります。
snapraid sync将来ドライブが故障した場合は、単純に交換して snapraid fix を実行するだけです。SnapRAIDはファイルレベルで動作するため、パリティ以上のドライブを失ったとしても、失われるのは故障したドライブにあるファイルだけです。それ以外は完全に無傷のまま残ります。
メンテナンスの自動化
SnapRAIDの唯一の欠点は、自動ではないことです。/mnt/storageにファイルを追加しても、再び snapraid sync を実行するまでは保護されません。同期を毎日実行するために、cronジョブまたはsystemdタイマーを設定することをお勧めします。
/usr/local/bin/snapraid-maintenance.sh に簡単なスクリプトを作成します：
#!/bin/bash
# アレイを同期
snapraid sync
# データのサイレントビットロットをチェック（アレイの8%をチェック）
snapraid scrub -p 8 -o 10実行可能にして、crontabに追加します：
sudo chmod +x /usr/local/bin/snapraid-maintenance.sh
(crontab -l ; echo "0 3 * * * /usr/local/bin/snapraid-maintenance.sh") | crontab -この設定により、毎晩午前3時に実行され、データが保護されていることを確認し、「ビットロット」（物理プラッタ上で時間の経過とともにデータが劣化する現象）をチェックします。
ワークフローのまとめ
この構成での運用経験は、非常に快適なものでした。昨年容量が足りなくなったとき、私は単に新しい12TBドライブを購入してフォーマットし、/mnt/disk4としてマウントして、snapraid.confを更新しただけでした。fstabでワイルドカード（/mnt/disk*）を使用していたため、MergerFSは自動的にそれを認識しました。アレイの再構築もストレスもなく、ダウンタイムもありませんでした。これは、生のエンタープライズパフォーマンスよりも柔軟性を重視するホームラボにとって、究極のストレージソリューションだと私は考えています。
