【OMV】SnapRAIDとMergerFSでなんちゃってRAID5のバックアップ専用NAS構築【検証】

我が家では結構古いSynologyのNASを運用し、そのバックアップをUSB外付けディスクへとっています。

NASを使う容量が増えてきたことで、バックアップ先のUSB外付けディスクの容量不足となっているため、どうせなら余っている容量バラバラのハードディスクを使ってバックアップ専用のNASを構築します。

本記事では手持ちの余った(容量バラバラの)ハードディスクを有効活用してバックアップ専用NASを構築する仕組みとして、仮想マシン(Proxmox)を使って「MergerFS」と「SnapRAID」の機能を検証していいます。

やりたいこと

自宅で運用しているSynologyのNASをUSB外付けハードディスクへバックアップしていますが、容量不足となっています。

どうせならバックアップ専用NASを構築してそこへバックアップしたいと思います。

この記事でやりたいことは「大容量のバックアップ専用NASを構築」です。

さらに「できるだけ安く」という点も含めます。

「手持ちのパーツや安い中古PCで構築」「手持ちの(余っている)ハードディスクで大容量化」というのがテーマになります。

あまりお金をかけたくない

バックアップ用の仕組みなのでお金をかけたくありません。

そのため、今まではUSB外付けハードディスクを使ってきましたが、バックアップ容量が大きくなってきて入れ替えるハードディスクも結構高額となってきました。

そこで、本記事のメインテーマは「余っている手持ちのハードディスク(容量バラバラ)を活用する」ということになります。

作戦はこうだ！

これらを実現するために以下の構成としてバックアップ専用NASの構築を検討していきます。

• MergerFSで余っているハードディスクを束ねる(大容量化)
• SnapRAIDでパリティ管理(データディスクの冗長化)
• 軽量なOpenMediaVaultを採用

本記事の内容と前提条件

本記事は「手持ちパーツを流用して大容量のバックアップ専用NASを構築」を目的として、SnapRAIDおよびMergerFSの機能を検証していきます。

※つまり、「構築記事」ではなく「仮想マシンによる機能検証記事」です。

SnapRAIDとMergerFSでなんちゃってRAID5環境を構築

実際にOpenMediaVaultへSnapRAIDとMergerFSを組み込んでバックアップ用NASを構築してみました。

とは言ってもまだハードウェアをそろえる前の予行練習と検証として、仮想環境(Proxmox)上で確認してみます。

軽量ストレージサービス「OpenMediaVault」

NASを自作する、という場合のソリューションとしては「TrueNAS」が有名です。

我が家でも古い(10年ほど前)パソコンにTrueNAS Scaleを導入しています。

ただしTrueNASはZFSファイルシステムをフル活用した高性能(?)ストレージサービスであり、非常に多くのメモリを要求します。

今回は「バックアップ専用NAS」構築を目指しているので、TrueNASよりも小型・軽量でサクサク動作するOpenMediaVaultを使用します。

SnapRAIDとは？

SnapRAIDはRAID5/6のようにディスクのパリティ管理ができる仕組みです。

パリティ管理により、SnapRAIDを構成するディスクが壊れてもディスク単位に復旧することができます。

SnapRAIDの特徴

「良い・悪い(メリット？デメリット？)」は置いておいて、SnapRAIDの特徴を主にRAID5/6機能と比較してみます。

ディスク容量はバラバラで良い

SnapRAIDはディスク単位にパリティを管理します。

このため、管理対象となるディスクの容量は同じである必要はありません。

パリティ計算はバッチ処理

まずSnapRAIDはパリティをリアルタイム(ファイル更新のタイミング)で更新しません。

「snapraid sync」コマンドによる任意のタイミングのバッチ処理にてパリティ計算を行います。

ディスク構成が自由自在

SnapRAIDは全体で6台までのディスクでRAIDプールを構成します。

そしてこのプール内で自由にディスク構成を変更することができます。

ディスクの追加や変更・削除(取り外し)も自由自在です。

MergerFSとは？

MergerFSとは複数のディスクを同一のマウントポイントにマウントできるファイルシステムです。

要するに複数のディスクを1本のディスクに見せることができる、という仕組みであり、JBODと同じ効果を提供してくれます。

JBODと同じなので容量バラバラの複数のディスクもOSから見ると大容量の1本のディスクに見える、ということです。

JBODじゃダメなの？

MergerFSの効果はJBODと同じであり、「複数のディスクを1本に束ねる」という効果です。

本記事の要件は「余っている容量バラバラのディスクを活用したい」なので、「それじゃJBODでいいんじゃない？」となるわけです。

ディスクを束ねるだけならJBODで良いですし、OpenMediaVaultでも標準のRAID機能内に「リニア」という機能名称でJBOD機能が提供されています。

MergerFSはSnapRAIDとセットで使う

ただし、JBODにより束ねてしまうとSnapRAIDから見えるディスクは束ねた後のディスク(つまり1本)になり、これではパリティ管理ができません。

MergerFSを利用することで、ディスクを束ねる前の個別の状態のディスクに対してSnapRAIDによるパリティ管理ができるようになります。

つまり、MergerFSはSnapRAIDとセットで使う機能、と考えるとよいでしょう。

OpenMediaVaultのプラグインを利用する

OpenMediaVaultはさまざまな便利機能がプラグインとして提供されており、プラグインにより簡単に機能拡張することができます。

そして、今回導入するMergerFSもSnapRAIDも、OpenMediaVaultではプラグインとして簡単導入することができます。

構築手順の検証

では、仮想サーバーを使って仮想マシン上にOpenMediaVaultをインストールし、SnapRAIDおよびMergerFSの構築手順および機能検証を行っていきます。

構築・検証手順としては仮想サーバーとしてはProxmoxを使っていますが、VMWare ESXiなどでも同じです。

OpenMediaVaultインストール

まず最初にOpenMediaVaultをインストールします。

OpenMediaVault | OpenMediaVaultプロジェクト

本記事ではOpenMediaVaultはすでにインストール済状態を前提とし、インストール手順説明は割愛します。

プラグインの導入

OpenMediaVaultには初期状態でいくつかの便利な機能がプラグインとして提供されていますが、あまり多くありません。

本格的にプラグインを使って機能拡張するなら、有志が開発・提供している「OMV Extras」というプラグイン集をインストール必要があります。

OMV-Extras | OMV Plugin-Developersプロジェクト

本記事で使うSnapRAIDやMergerFSのプラグインもこのOMV Extrasに含まれています。

OMV-Extrasのインストール

OMV-ExtrasはWebUIからのインストールではなくコンソールからインストールします。

OpenMediaVaultへSSHログインし、以下の手順にてOMV Extrasをインストールします。

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

OMV Extrasがインストールされると、WebUIには「omv-extras」のメニューが追加表示されます。

MergerFSプラグインのインストール

OMV ExtrasインストールしたらMergerFSプラグインをインストールします。

メニュー「システム > プラグイン」から検索欄に「mergerfs」と入力しMergerFSプラグインを絞り込み表示させます。

mergerfsプラグインを選択(黄色表示)し、インストールボタンを押下するとプラグインのインストールは完了です。

SnapRAIDプラグインのインストール

同様にSnapRAIDのプラグインもインストールしておきます。

検索欄に「snapraid」と入力し絞り込まれたプラグインを選択(黄色表示)します。

ダウンロードボタンでインストールします。

ディスクの初期化とディスク設計

メニュー「ストレージ > ディスク」で現在認識されているディスクを確認してみます。

つまり、#1～#4のディスクをSnapRAIDのデータ/コンテンツディスクとし、MergerFSで束ねます。

そのうえで、SnapRAIDにより#1～#4のディスクをデータ/コンテンツディスク、#5をパリティディスクとして構成する、という構成内容になります。

ファイルシステムの構築

とりあえず追加したディスク(#1～#5)をOpenMediaVaultで使えるようにするためディスク初期化します。

メニュー「ストレージ > ファイルシステム」を開きます。

本記事の環境では上記のように「/dev/sda」のみがファイルシステムとしてマウントされています。

この「/dev/sda」はOpenMediaVaultのシステムディスクです。

これに、MergerFS & SnapRAID用のディスクを追加(ファイルシステム構築 & ディスクマウント)していきます。

ファイルシステムの追加作成ボタン(+)からファイルシステムを選びます。

本記事では「Ext4」を選びました。

次にファイルシステムを作成するディスクを選択します。

追加するディスクを追加し「保存」ボタンでファイルシステム構築します。

次画面で今作成したファイルシステムをマウントします。

ファイルシステムを作成し、そのディスクをマウントすることでファイルシステムが「Online」となります。

これを追加するディスク分(本記事では#1～#5の5本分)行う(繰り返す)ことで、追加ディスク(5本)をEXT4にてファイルシステム構築します。

本記事では5本のディスクを追加したので、最終的に以下のように5本のファイルシステムがマウントされました。

以上でファイルシステムの構築とマウントは完了です。

MergerFSの設定

MergerFSを設定していきます。

MergerFSはディスクを束ねる仕組みなので、束ねる対象となるディスクを選択する、という定義内容となります。

メニュー「ストレージ > mergerfs」を開きます。

ボタン(+)押下してMergerFSの作成を行います。

以下の項目を設定します。

上記設定したら「保存」ボタン押下でシステム反映させます。

以上でMergerFSの設定は完了です。

メニュー「ストレージ > ファイルシステム」をみると新しいファイルシステムが作成・マウントされています。

この「/srv/mergerfs/mfs0」が今設定したMergerFSの(束ねられた)ファイルシステムですね。

SnapRAIDの設定

次にSnapRAIDを設定していきます。

メニュー「サービス > SnapRAID > ドライブ」画面を開きます。

作成ボタン(+)でSnapRAIDを設定していきます。

本記事ではディスク設計として上記を前提としています。

まず、「#5 /dev/sdf」のパリティディスクをSnapRAIDへ登録します。

※パリティディスクはSnapRAID管理配下で最大容量のディスクを割り当てる必要があります。

パリティディスク(#5ディスク)には以下の設定を行います。

以上設定したら「保存」します。

次にデータ/コンテンツドライブを設定します。

以上設定したら「保存」します。

本記事ではデータ用ドライブは4本あるので、これを4本分繰り返します。

最終的に「1本のパリティディスク、4本のデータディスク」を登録すると、SnapRAID管理画面は以下のようになります。

SnapRAIDの初期同期(パリティ計算)

SnapRAIDの設定は完了しましたがまだ動作していません。

SnapRAIDは「最初の同期(パリティ計算)以降動作する」という仕組みなので、最初の同期処理を行っておきます。

メニュー「サービス > SnapRAID > ドライブ」画面のツールアイコンから「同期」をクリックして同期(パリティ計算)を行います。

現時点ではデータドライブは空っぽなのであっという間に同期は完了します。

共有フォルダの設定

ここまでの作業でMergerFSおよびSnapRAIDの設定は完了しています。

MergerFSにより束ねられた複数のディスク(本記事では4本)がSnapRAIDによりパリティ管理されている状態です。

では、作成したディスク領域を使って共有フォルダの設定を行っていきます。

この作業はMergerFS/SnapRAIDは関係なく通常の共有フォルダ作成手順となります。

ユーザーの作成

最初に共有フォルダを利用するユーザーを登録しておきましょう。

メニュー「ユーザー > ユーザー」画面を開きます。

ユーザー作成ボタン(+)よりユーザーを登録(新規作成)します。

最低限の設定項目として「ユーザー名」と「パスワード」を設定すれば良いです。

設定後、「保存」ボタンでユーザー登録完了です。

共有フォルダの作成

次に共有フォルダを作成します。

メニュー「ストレージ > 共有フォルダ」画面を開きます。

共有フォルダ作成ボタン(+)を押下して共有フォルダを作成します。

共有フォルダ名と共有フォルダを作成するファイルシステムを選択・入力します。

以上を設定したら「保存ボタン」で共有フォルダ作成完了です。

共有サービスの設定

共有フォルダの作成が完了しているので、最後に共有フォルダを利用するプロトコルを設定します。

本記事ではWindowsクライアントからの利用を前提とし、プロトコル(共有サービス)として「SMB/CIFS」を設定します。

メニュー「ストレージ > サービス > SMB/CIFS > 設定」画面を開きます。

設定画面から「有効」をチェックし、「保存」ボタンを押下します。

これで「SMB/CIFS」サービスが有効になります。

次にメニュー「ストレージ > サービス > SMB/CIFS > 共有」画面を開きます。

共有サービス作成ボタン(*)より共有フォルダサービスを選択します。

先ほど作成した共有フォルダ「share」を選択して「保存」ボタン押下で共有サービス設定が完了です。

Windowsクライアントからネットワークを見ると、上図のように「share」フォルダが共有フォルダとして見えるようになっています。

以上で「共有フォルダ」の作成は完了です。

Windowsクライアントから共有フォルダの利用が可能となりました。

動作検証

ここまでの作業で仮想環境(Proxmox)上に仮想マシンとしてOpenMediaVaultをインストールし、その中でMergerFS/SnapRAIDによる共有フォルダを作成してきました。

構築は完了したので、ここからは動作を検証していきます。

ディスク構成はどうなってる？

作成した共有フォルダの容量はWindowsから見ると100GBとなっています。

これは4本のディスクを束ねた合計の容量です。

ファイルコピー速度は遅くない！

ファイルのコピー速度は遅くありません！

5.5GBほどあるWindows11のインストールディスクをWindowsクライアントから共有フォルダへコピーしてみます。

ネットワーク環境(1GbE環境です)のほぼ上限である95MB/s～110MB/sでコピーできています。

まぁ、MergerFSなので単一ディスクコピーだし、SnapRAIDのパリティ計算はバッチ処理なので、ただの単一ディスクコピーと同じです。

ディスクは束ねられていない

今回MergerFSはJBODと同じように「複数のディスクを束ねる」機能を提供してくれますが、実際に束ねられるわけではありません。

「束ねているように見える」だけなので、一つのファイルがディスクをまたがってコピーされることはありません。

巨大ファイルをコピーしてみる

さきほどの5.5GBほどのWindows11インストールディスクを複数結合して60GBの巨大ファイルを作成しコピーしてみます。

Z:\>dir
 ドライブ Z のボリューム ラベルは share です
 ボリューム シリアル番号は 77C2-3C3D です

 Z:\ のディレクトリ

2024/01/05  20:33              .
2024/01/05  04:45              ..
               0 個のファイル                   0 バイト
               2 個のディレクトリ  104,833,208,320 バイトの空き領域

Z:\>dir d:\temp\100.iso
 ドライブ D のボリューム ラベルは Work です
 ボリューム シリアル番号は CC17-6166 です

 d:\temp のディレクトリ

2024/01/05  20:20    56,264,622,080 100.iso
               1 個のファイル      56,264,622,080 バイト
               0 個のディレクトリ  443,177,193,472 バイトの空き領域

Z:\>

見た目上は100GBの空き容量があります。

ここへ56GBの巨大ファイル「100.iso」をコピーしてみます。

Z:\>copy d:\temp\100.iso z:\
ディスクに十分な空き領域がありません。
        0 個のファイルをコピーしました。

Z:\>

Windowsクライアントからは(見た目上)100GBの空き容量がありますが、ここへ60GBのファイルをコピーすると「空き容量がありません」でエラーとなります。

本記事では4本のディスクをMergerFSで束ねていますが最大容量のディスクは40GBであり、これを超える60GBのテスト用巨大ファイルはコピーできない、という結果になるわけです。

SnapRAIDのパリティ計算

本記事ではSnapRAIDによるパリティ管理の仕組みを構築しているのでディスク障害時にはパリティ情報に基づいて復旧が可能です。

ただし、先述したようにSnapRAIDのパリティ計算はリアルタイムではありません。

SnapRAIDは任意のタイミングで「snapraid sync」コマンドによるパリティ計算(同期)が必要です。

SnapRAIDの同期(パリティ計算)

SnapRAIDの同期はOpenMediaVaultのメニューから実行できます。

メニュー「サービス > SnapRAID > ドライブ」画面のツールアイコンを開きます。

「同期」を選択することで、最新のデータドライブからパリティを再計算します。

また、コマンドライン「snapraid sync」でも同期処理を行うことができます。

root@sbomv01:~# snapraid sync
Self test...
Loading state from /srv/dev-disk-by-uuid-dd6810e9-5dc1-48da-aa47-1c6317644df9/snapraid.content...
Scanning...
Scanned srd1 in 0 seconds
Scanned srd2 in 0 seconds
Scanned srd4 in 0 seconds
Scanned srd3 in 0 seconds
Using 0 MiB of memory for the file-system.
Initializing...
Resizing...
Saving state to /srv/dev-disk-by-uuid-dd6810e9-5dc1-48da-aa47-1c6317644df9/snapraid.content...
Saving state to /srv/dev-disk-by-uuid-d10a65dc-4a18-46fc-8408-2e09800b8201/snapraid.content...
Saving state to /srv/dev-disk-by-uuid-20e58b78-bba6-4a42-a0b4-65ffa24b8266/snapraid.content...
Saving state to /srv/dev-disk-by-uuid-62005e6f-29ad-4b0a-ba43-eef416bb3f8f/snapraid.content...
Verifying...
Verified /srv/dev-disk-by-uuid-dd6810e9-5dc1-48da-aa47-1c6317644df9/snapraid.content in 0 seconds
Verified /srv/dev-disk-by-uuid-d10a65dc-4a18-46fc-8408-2e09800b8201/snapraid.content in 0 seconds
Verified /srv/dev-disk-by-uuid-62005e6f-29ad-4b0a-ba43-eef416bb3f8f/snapraid.content in 0 seconds
Verified /srv/dev-disk-by-uuid-20e58b78-bba6-4a42-a0b4-65ffa24b8266/snapraid.content in 0 seconds
Nothing to do
root@sbomv01:~#

omv-snapraid-diffコマンド

OpenMediaVaultのSnapRAIDプラグインには「omv-snapraid-diff」というシェルコマンドが提供されています。

これはSnapRAIDのパリティをチェックし、差異(diff)があればパリティを再計算(sync)する、という一連の処理をやってくれます。

つまり、通常の運用設定としては、この「omv-snapraid-diff」コマンドを任意のタイミングで実行することでパリティ構築を行うという運用になります。

メニュー「サービス > SnapRAID > 設定」画面を開きます。

画面下の「差分のスケジュール」を選びます。

「有効」をチェックし、差分チェック(omv-snapraid-diffの実行)をcronへ登録することができます。

本記事では(暫定的に)「再起動時」としました。

この設定により、OpenMediaVaultが起動時(電源投入時)または再起動時に自動的にパリティの再チェックおよび再計算が行われることになります。

なお、本当は「システム終了時」に実行したいんです。

バックアップ専用NASなので、バックアップしてNASを終了するタイミングでパリティ再計算したいのですが、この設定についてはまた後で・・・

ディスクの構成変更

SnapRAIDはRAIDと謳っていますがRAID5/6やRAID0みたいに構成的にディスクを束ねているわけではないため、SnapRAIDの解除や再設定は自由自在です。

また、MergerFSもディスクを束ねているように見せているだけであり実際には束ねていないのでディスク単位でディスクの追加や削除(取り外し)が可能です。

つまり、SnapRAIDとMergerFSの組み合わせでは運用開始後でも構成ディスクの変更がいつでもできる仕組みになっています。

ディスクを1本追加してみる

ディスク不足を想定して、データ用ドライブを1本(50GB)追加してみます。

以下のように仮想マシンに50GBのディスクを追加します。

追加したディスクをWebUI上で「ファイルシステム作成とマウント」します。

マウントされた追加ディスクをMergerFSへ組み込みます。

以上で追加ディスクをMergerFSへ組み込みました。

さらに、追加ディスクをSnapRAIDの「データ/コンテンツ」ディスクとしてSnapRAID定義へ追加します。

メニュー「サービス > SnapRAID > ドライブ」を確認すると追加ディスクがSnapRAID管理下へ組み込まれていることがわかります。

ディスクを1本取り外してみる

ディスクを取り外す場合も簡単で、ディスク追加とは逆の手順となります。

つまり「SnapRAID管理下から削除する」から「MergerFS配下から削除する」という手順です。

これで取り外すディスクはSnapRAID対象外かつMergerFS対象外のディスクとなるので、あとはご自由に。

ディスクのバランシング

MergerFSは複数のディスクを「束ねているように見せる」だけのファイルシステムであり、実際に(RAID5/6のように)束ねられているわけではありません。

では、共有ディスクへファイルコピーする場合に実際にはどのドライブへコピーされるのでしょうか？

これはMergerFS設定の「Policy」で決まります。

MergerFSの「Policy」

MergerFSでは設定に「Policy」があり、これによりどのディスクへコピーするか？が決まります。

本記事ではMergerFS作成時に「Policy = Most free space」を設定しています。

この設定は「もっとも空き容量の大きいディスクへコピーする」という動作になります。

Policyは非常に多種で正直よくわかりませんが、「Most free space」でよいのかな？と思っています。

実際、5台で束ねているMergerFSへ(先ほど使った)Windows11インストールISOを10個ほどコピーしてみました。

コピー後のストレージ容量は以下のようになりました。

良い感じで空き容量の大きなディスクへコピーされているようです。

ディスクのバランスをとる

上記のようにPolicy「Most free space」でよい感じに空き容量の大きなディスクから使用されていますが、もし容量の偏りが発生した場合にはMergerFSの機能で「Balancing」を行うことができます。

メニュー「ストレージ > MergerSF」からMergerFSのファイルシステムを選択し、ボタンより「同期」を選択します。

ディスクの偏りを修正するバッチ処理が実行されます。

ディスク容量によりますが、当然ながら相当な時間がかかります。

私の場合はバックアップ専用としての利用だし、半年とか一年に一回程度でいいかな？と思っています。

ディスク障害時の運用

ディスク障害のパターンは数多くあり、その状況によりNASの運用状態もリカバリー手順もことなります。

本記事では簡単に「構成ディスク(データディスク)を1本取り外してみる」という手段により、ディスク障害(欠損)の状況としてみました。

ディスクを1本外してしてみる

まずMergerFSを構成している4本のディスクのうち1本を取り外してみます。

本記事は検証のため仮想環境(Proxmox)にて構築・作業を行っており、現在以下のハードディスク構成となっています。

上図のディスク構成から1本(50GB/赤枠)を取り外してみます。

Proxmoxでは「ハードディスクを取り外す」とは「デタッチする」ということになり、対象ディスクをデタッチすると上図のように「未使用のディスク」となります。

以上で物理的なNASからディスクを1本取り外した状態となります。

デグレード状態の確認

SnapRAIDおよびMergerFSが管理するデータディスクから1本を取り外したのでシステム的にはデグレードしている状態となります。

メニュー「ファイルシステム」を見ると取り外したディスクが「Missing」と赤色表示されています。

共有ディスクは使えない(運用はできない)

この状態では共有ディスクの利用はできませんでした。

C:¥>net use z: \\192.168.11.22\share password /user:Administrator
システムエラー 67 が発生しました。

ネットワーク名がみつかりません。

上記のようにWindowsクライアントから共有ディスクへ接続しようとしてもエラーとなります。

つまり、SnapRAID & MergerFSによる構成では「RAID」と言いながら運用上の可用性は保てない(運用継続はできない)、ということになります。

新しいディスクで再構築してみる

では、取り外したディスクの代わりに新しいディスクを装着してRAID再構築を行ってみましょう。

取り外したディスクはそのままに、同じ容量(50GB)のディスクを追加してみます。

SnapRAIDではデータディスクはパリティディスクの容量よりも小さくなければならないため、新しく追加するディスクの容量は基本的に「パリティディスクの容量≧追加するディスク容量≧外した(壊れた)ディスク容量」となります。

本記事では新しく50GBのディスクを追加してみました。

SMB/CIFSの一時停止

障害ディスクをアンマウントするために、一時的に障害ディスクをつかんでいるサービスを停止します。

本記事では共有ディスクとして「SMB/CIFS」を有効化しているので、これを「無効(有効チェックをはずす)」にします。

ファイルシステムの作成とマウント

新しく追加したディスクに対してファイルシステムを作成しマウントします。

MergerFSの構成変更

新しくマウントしたディスクをMergerFSの構成ディスクとして組み込みます。

SnapRAIDの構成変更

同様に、新しくマウントしたディスクをSnapRAIDの構成ディスクとして組み込みます。

取り外した障害ディスクのアンマウント

この時点で障害ディスクをファイルシステムからアンマウントします。

SnapRAIDからの「修復(Fix)」

ではSnapRAIDのパリティ情報からディスク復旧を行ってみます。

現在MergerFS上にあるファイルは以下のようになっています。

先述の検証により、本ディレクトリには「001.iso～010.iso」までの10個のファイルがあるはずなのですが、ディスク障害により上記のようにファイルが欠落しています。

これをSnapRAIDのパリティ情報から復旧してみます。

メニュー「サービス > SnapRAID > ドライブ」から復旧対象とするデータドライブを選択します。

・

本記事ではデータドライブ「srd5」を復旧したいのでsrd5を選択しツールから「修正」を選び実行します。

修正(復旧)には当然ながらしばらく時間がかかります。

復旧後の共有ディスクには上記のように10個のファイルが戻り、障害ディスクが復旧されました。

SnapRAIDとMergerFS、使えるのか？

パリティ計算はバッチ処理

SnapRAIDのパリティ計算はRAID5/6のようにリアルタイムでは行われません。

任意のタイミングで「snapraid sync」コマンドを発行することで、最新のデータディスクに対するパリティ計算が行われます。

そしてディスク障害時にパリティ情報を使って復旧できるのは(当然ながら)その時点のパリティに従い復旧されます。

ディスク障害時の運用継続はできない

MergerFSにより束ねられているディスク群に障害が発生した状態ではMergerFSはアクセスを禁止します。

つまりSnapRAIDによりパリティ管理を行っていても、ディスク障害が発生すればMergerFS上で対処完了となるまではディスクアクセスができません。

つまり、RAID5/6のように障害発生時でも運用を止めない、という使い方はできません。

SnapRAIDとMergerFSの使い方

「SnapRAID & MergerFSでなんちゃってRAID5」とタイトル付けましたが、このように「SnapRAID & MergerFS」では以下の点で大きくRAID5/6と異なります。

• パリティ計算はバッチ処理
• ディスク障害時は運用が止まる

このようにRAID5/6の大きなメリットに対して「SnapRAID & MergerFS」では実現することができません。

このことから「SnapRAID & MergerFS」による大容量ストレージシステムは「バックアップ専用機」の構築としては有効かと思いますが、日常的に運用するメインのNASとしてはちょっと制限があるでしょう。

バックアップ専用なら「リニア」で良い？

本記事では余っている容量バラバラのハードディスクをMergerFSで束ね、さらにSnapRAIDでパリティ管理を行ってみました。

まず、「余っている容量バラバラのハードディスクを束ねる」だけならRAID機能のひとつである「JBOD」機能で実現できます(冗長性はありません)。

この機能はOpenMediaVaultにも搭載されており、「RAIDメニュー」から「リニア」を選ぶことで容量の異なる複数のディスクを束ねることができます。

さて、ここからさらに「束ねたディスクに対してパリティ管理が必要か？」ということで、必要であればSnapRAIDとMergerFSを組み合わせることになります。

なお、「JBOD/リニア」で束ねたディスクに対してSnapRAIDでパリティ管理するのは(できなくはないけど)一般的ではありません。

※SnapRAIDのパリティ用ディスクは管理対象データディスクより大きな容量でなければならない。

ハードウェアはどうする？

本記事では手持ちの余ったハードディスクを有効活用して、運用として使っているNAS(Synology)のバックアップ専用NASを構築することを目的としています。

ソフトウェア的には軽量NASシステム「OpenMediaVault」へSnapRAIDとMergerFSをプラグインとして導入し、「余っている容量ばらばらのハードディスクをMergerFSで束ねる(JBOD)」「SnapRAIDでパリティ管理」という構成を検討してきました。

では、これらの仕組みを導入するハードウェアについて検討してみたいと思います。

人気のNASケース「JONSBO N3」

もともと、自作PCとしてNASを構築したいと思っていました。

NAS向けのケースとして人気なのが「JONSBO N2/N3」です。

どちらも小型のNAS向けケースであり、N2は最大5台の3.5HDD搭載可能、N3は最大8台もの3.5HDD搭載可能というスペックです。

PCケース JONSBO N3 ブラック

ノーブランド品

Amazonの商品レビュー・口コミを見る

Amazon

楽天

Yahoo!ショッピング

このケースを使った自作NASについては構成も含めて別途記事化したいと思います。

古い中古NAS「HDL-Z6」シリーズ

バッファローが販売しているWindows ServerベースのNASに「HDL-Z」シリーズがあります。

この中の古い機種に「HDL-Z6」シリーズとして6ベイ対応のものがあり、企業のリース切れ品などが市場に出回っています。

HDL-Z6WLC2シリーズ | Windows Storage Server 2012 R2 Standard Edition搭載　6ドライブモデル NAS | アイ・オー・データ機器 I-O DATA

NAS用WindowsサーバーOS搭載した高信頼HDD採用した3年保証のビジネスNAS「HDL-Z6WLC2シリーズ」の概要ページです。

www.iodata.jp

現在の「HDL-Z」シリーズには6ベイ版はないため、6ベイ版だとちょっと古くなりCPUは「Intel Atom D2700」「メモリー最大4GB」となりますが、軽量なOpenMediaVaultを動かすには十分でしょう。

HDL-z6シリーズ市場価格動向

ヤフオクにもたまに出品されているようです。

落札履歴は以下のような感じです。

Yahoo!オークション -「hdl-z6」の落札相場・落札価格

「hdl-z6」関連の新品・未使用品・中古品の過去120日分の落札相場をYahoo!オークションで確認できます。約10件の落札価格は平均6,242円です。Yahoo!オークションは、誰でもかんたんに売り買いが楽しめるサービスです。

auctions.yahoo.co.jp

中古品なので製品の状態レベルはさまざまであり、そのため価格・価値もバラバラであるのは当然ですが、「本体がちゃんと動いて1万円程度」であれば入手してみたいと思っています。

まとめ、SnapRAIDとMergerFSは有効か？

SnapRAIDとMergerFSによるストレージシステムの特徴は以下の点になります。

• 余っている容量バラバラのハードディスクを束ねることができる
• さらにパリティ管理による冗長性を持たせることができる

つまり、冗長性を確保できるNASシステムが欲しい場合には同容量のハードディスクを揃えておとなしくRAID5/6を構築すれば良いわけです。

SnapRAID & MergerFSのメリットは「余っている容量バラバラのハードディスクを活用できる」という点になります。

SnapRAIDはバックアップ

SnapRAIDはRAIDというからRAID5/6のイメージを持っていましたが、どうやら違うようです。

SnapRAIDにはRAID5/6のような「冗長性」「可用性」はありません。

SnapRAIDは複数の単一ディスクをパリティとしてバックアップし、いつでもパリティから単一ディスクを復元できる機能を持っています。

SnapRAIDに冗長性・可用性はない

データを「リアルタイムで二重化(=冗長性)」する機能はないし、ディスク障害時でも「運用を止めない(=可用性)」機能もありません。

パリティの計算は任意のタイミングでのバッチ処理(snapraid sync)です。

単一ディスクへの自由度が高い

SnapRAIDは複数の単一ディスクのデータをパリティ情報として管理することで、対象単一ディスクのバックアップという機能になります。

このため、運用中でもディスク構成の変更は自由自在であり、いつでもバックアップ対象の変更(追加・取り外し)ができます。

また、ディスク障害時でも対象ディスク交換後に簡単に修正(snapraid fix)しディスク復旧することができます。

バックアップ専用NASに冗長性はいらない！？

今回私はバックアップ専用NASの構築手段として「SnapRAID & MergerFS」を検討してみました。

面白いシステムだとは思いますが、そもそもバックアップ専用なので本データは別(運用NAS)にあるわけで、バックアップ専用NASに冗長化は不要かな？という考えに落ち着きそうです。

もしバックアップ専用NASのハードディスク障害が起こっても、復旧後に再度本データ(運用NAS)からバックアップするだけなので。

こんな人・こんな使い方へおすすめ

SnapRAIDとMergerFSを組み合わせるメリットとしては「容量バラバラのHDDがたくさん余っている」という場合において「冗長性を確保できる」という点になります。

「容量バラバラのHDDがたくさん余っている」だけであれば、RAID機能のJBODを使えば容量バラバラでも1本にまとめることができます。

OpenMediaVaultでも標準のRAID機能「リニア」を使えばJBODで束ねることができます。

これに加えて「パリティ管理による冗長性」が欲しい場合に「SnapRAID & MergerFS」となります。

バックアップ専用NASの構築

私のように「通常運用は専用のNASで行っている」「余っているHDDを束ねて運用NASのバックアップ専用NASを作りたい」という場合に「SnapRAID & MergerFS」は有効です。

ただし、先に述べたように「バックアップ専用ならJBODでいいや」という考えもあり、私もそちらに傾いています。

写真・動画などのファイル置き場

写真や動画など比較的大きなファイルを大量に保管する目的で「SnapRAID & MergerFS」によるNASを構築するのも良いでしょう。

余っているハードディスクをMergerFSで束ねることで大容量のストレージを組むことができ、さらにSnapRAIDのパリティ管理により冗長性を持たせることもできます。

「みんなで動画などのデータ編集をする」という更新が多い使い方でなければSnapRAIDとMergerFSで安くNASを構築できます。