RAIDストレージのバックアップ実行前にソフトウェアRAID状態をチェック

公開 | 更新 
図1.タスクの設定にあるEメール通知機能

以前組んだ、遠隔地にある Raspberry Pi によるソフトウェア RAID 6ストレージをオフサイトバックアップする仕組みを永らく運用していますが、この RAID がコケていることに数日経ってようやく気付き、バックアップを確認すると見事に空っぽ( RAID ボリュームのマウントに失敗した空状態を健気にコピー)。幸い機器再起動で RAID は復活しましたが、かなり肝を冷やしたのでバックアップ実行前に RAID 状態をチェックする仕組みを織り込みます。

遠隔地にあるそのRaspberry Piは週に一度、システムディスクであるSDカードのイメージをRAIDストレージへ出力しています。このタスクの吐き出したエラーメッセージで気付きました。

実際にはこの2日前にRAID喪失が発生していたことが、毎晩実行されるオフサイトバックアップの当日のログから読み取れます。

バックアップからの復元は諦め、RAID復活の可能性を探るべく、まずはRaspberry Piのコンソールで状況を確認。

このRaspberry Piは24時間稼働ですが、毎週末再起動するようスケジューリングされており、uptimeはそこからの稼働時間値を示しています。この再起動後ほどなくその夜のオフサイトバックアップでストレージ空っぽ状態が記録されていることから、当日のSyslogをトレースしてみます。

何らかの理由で起動時にRAIDボリュームをマウント出来ずに、そのまま稼働していたようです。幸い、Raspberry Piを手動で再起動させると今度はRAIDも問題無く立ち上がり、ストレージの中身も復帰しました。ちなみに正常時のログは以下の通り。

特に物理的、論理的な欠損は見当たらないので原因究明はここまでとして、今後に備えて以下の2つの対策を講じます。

 

RAID状態のレポートを毎日発信する

遠隔地のRaspberryPiから定期的に受け取るレポートは、vnstatによる日刊のネットワーク使用量に関する事項のみで、このメールの有無が死活監視になっている程度です。RAIDの健康状態も毎日メールで受け取れるようにしてみます。RAID状態の確認に使うのは普段より使っているこのmdadmコマンドです。更に障害発見時の切り分け用にストレージやUSBデバイス情報も付属しておきます。

これを毎朝実行してメール本文に貼り付け送信するタスクをcronに登録します( mdadm 使うので実行者はrootにて)。

尚、このRaspberry Piには以前のRAID障害対策の一環でsSMTPを導入済なので、これだけでメールを送信することが出来ます。

 

スクリプトファイル化 【2022.04追記】

さすがにcronへ上記の長文ワンライナーを記述するのは何かと不便なので、バッチファイルに書き直します。

その際に mail コマンドには、 -r オプション追記して送信元メールアドレスを明示しています。こうしないとsSMTPの仕様なのか送信元アドレスが、「コマンド実行時のユーザ名@ホストのFQDN(例: pi@raspberrypi.local )」として、送出されてしまうからです。

sSMTPの設定でドメイン部分は変更可能ですが、やはりSPAM判定を避けるためには、実在するメールアドレスから発信されたメールにしておいた方が安心でしょう。

このスクリプトファイルを実行権限を付与した上で適当な場所へ配置したら、cronには次の要領で呼び出してもらいます( mdadm を扱うのでrootユーザで)。 mail コマンドにはデバッグ用の -v オプションを付けているので、SMTPサーバとのやり取りに問題はないかの判断材料にすることができます。

 

RAIDストレージのあるRaspberry Pi側の対策は以上です。次ページでは、このストレージのオフサイトバックアップを担うNAS、Synology DS212j側へ対策を施します。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA