RAIDも死ぬが再構築で生き返る

⚠︎ ページの作成日を確認のうえご覧ください。
内容が古くなっている場合があります。

ここから先はMacOSでRAIDを組んで運用する話題だ。RAID1を構成しているディスク1台が異常を呈し、これが再構築されて復帰した件とデータの安全な運用・保存・保管について一例を示そうと思う。

釈迦に説法だろうが念のため……RAIDは複数のドライブを単一のドライブのように扱う技術で、複数に同じデータを保存したり、分割したりすることで安全性を高めたり速度向上を狙ったりする。さまざまなRAID形式のうち、複数のドライブに同じデータを保存していずれかが故障しても他に保険をかられるRAID1を利用している人は多いのではないだろうか。

書庫や倉庫を喩えにすると、原本が二箇所以上の場所に保管されていれば、どこか一箇所が事故に見舞われても別の場所から原本を取り出せばよいという理屈だ。

RAID1を組んでいた私の環境で、RAID1を構成する1台のハードディスクのデータが壊れた。

いつどのように壊れたかわからないが、決定的なダメージを与えたのは私なのははっきりしている。

Macにマンウトして使用したRAID1ドライブをアンマウントした際に、ドライブを収めたケースのアクセスを示すLEDが点滅状態のままになった。このときデスクトップ上からRAID1ドライブのアイコンが消えていたので、Macから見てアンマウントされているのにケース側というかドライブ側が何か勘違いしているのだろうと思った。

なぜそう思ったのか、と問われてもあれこれ仕事を済ませたあとの感覚としか言えない。

ドライブ個々の電源を落とせるケースなのでRAID1ドライブを構成しているハードディスクの電源をそれぞれ落とした。そしてケースの電源も落とした。するとMacのディスプレイが暗転して異常終了を示すアラートが出るとともにフリーズした。

これでRAID1を組んでいたドライブ1台のデータが壊れた。というか、こうなる状態でドライブ1台のデータは既に壊れていた。

どういう現象が起きていたか後述するが、アンマウントした後もずっとケース側のアクセスランプが点滅していたことそのものがドライブのデータ破損を示している。作業中は同じデータが保存されているRAIDを構成する別のドライブを読み書きできていただけだ。ここに念押ししてしまったのである。

アンマウント後いつまでも続くアクセスランプの点滅は何だったのか。

デスクトップからドライブのアイコンが消えて、ドライブを収容しているケース側のLEDがアクセスを示す点滅をしている状態は、生き残っているドライブからデータが壊れたドライブへデータを書き写してRAIDを再構築している状態だった。

MacOSには、RAIDの構成が壊れた際に自動的に修復・再構築する仕組みがある。

それならそうと再構築する際に通知してくれればよいのに黙ったまま作業が始まっていた。これがアンマウント後もアクセスを示すLEDが点滅していた理由だ。

このように片肺になったRAID1でも、RAIDドライブとしてマウントできたりする。マウントできると片側だけで読み書きもできる。マウントできなかったり読み書き不能になる場合もある。

ただ、いずれにしてもRAIDを構成するディスクすべてが壊滅的被害を被っていないならMacOSが再構築をはじめる。

再構築の進行状況は[ディスクユーティリティ]で[RAIDメンバーディスク]を表示させるとどのドライブがオンラインなのか、再構築中なのか、再構築は何%進んでいるのか一覧できる。

ディスクユーティリティを終了させても、OSの機能として再構築が進められるので再構築が終了しない。ディスクユーティリティを起動させていないにも関わらず自動的再構築がはじまるのだからとうぜんだ。

この作業はデータが寸分違わないペアになるディスクをつくっているだけ。

つまり完全コピー(クローン)をつくっている訳で、データの総量次第で終了までの時間が変わる。もちろん接続方式、ディスクの速度も影響するが、RAIDを組んでいるのは重要なデータがまとまって存在しているケースだろうからそれなりの時間が必要になる。

私の場合は仕事用のスチル写真のRAWデータおよび重要な現像後の汎用画像形式に書き出したものと現像ソフトに関わるファイルがRAID1で保存されていた。過去からの資産は別のハードディスクに保存し、取り外したハードディスクを防湿庫保管しているので直近のデータだけとはいえ3TBくらいはあり、日々の作業でけっこう頻繁に読み書きされていた。

Thunderbolt接続ならもう少し早かっただろうけれど、USB3.0/UASP接続で14〜15時間くらいかかった。途中このRAIDが含まれるハードディスクケースに収容している別のハードディスクにあるRAWデータを現像したり、現像したデータをPhotoshopに持ち込んで修正・調整したりと作業しつづけていたことが再構築に要する時間にどれくらい影響したかは不明。

命の次に大切なデータに関して石橋を叩いて渡るように、RAIDとは別にRAID側に含まれる重要データを別ディスクにも保存していたので作業が滞らず助かった。

再構築は通常の読み書きをしつつも可能なのかもしれないが、私の環境の状況ではRAIDがアンマウントされ再構築が進められていたのでデータを取り扱えなかったのだ。

ずっと写真の仕事をしてきて、仕事先にまとめて預けたポジを紛失されたり、預け先の版元が倒産して大量の原版が行方不明になったりを経験した。デジタルになってからはハードディスクが飛んで消えたデータがあり、それでもTB単位でRAWデータ等を取り扱わなければならず安全性追求の試行錯誤が続いた。

オプチカルディスクに大量のデータを書き込んで保管するというのは、まとめてバックアップするにしても効率が悪く、ちゃんと書き込めたかの検証もデータを使う際の読み込みも低速すぎてどうしようもない。

信頼のおけるクラウドストレージならローカルな環境に事故があってもデータは安全だし、この国や地域が未曾有の災害に見舞われてもなんとかなる。ところが、使用開始とともに過去からのデータをアップロードするのも、日々仕事のたびに増える写真周りのデータをアップロードするのも高速な回線をつかっても難儀すぎるのだった。もちろんダウンロードにも時間を要する。

アップロードは暇なときやっておけで済むが、緊急時にデータを欲してダウンロードに延々と時間をかけられるとは限らないのだった。

ないとは思うけれど、クラウドストレージが検閲されて云々みたいな事態は気持ち悪いなと。信頼できるクラウドストレージとはいったい……という根本的な問題がある。

最終的に、ハードディスクケースにRAIDのほか複数のドライブを収容して、日々追加され変更されるデータはRAIDにまず保存し、恒久的に保存すべきデータを他のディスクにバックアップするようにした。このディスクは時期がきたら満杯でなくてもハードディスクケースから取り出し前述のように防湿庫で保管。日々作業の折にバックアップするので、数TBのデータをオプチカルディスクにコピーしたりクラウドストレージにアップロードする手間とは比べものにならないくらい速やかに保管用データになる。

しかもRAIDに何らかの問題が生じても、今回のように難なく作業が続けられる。

たしかにここまで冗長性を高めるのはほんとうに合理的か考えたこともあったし、実はRAIDからバックアップするディスクは現在2台だったりしてここまでやるかと馬鹿らしさを感じないわけでもなかった。

だけどRAIDが再構築されるまで作業が止まることを考えたら答えは明白だった。ハードディスクケースに何かあったら、ディスクを取り出してクレドールに立てて使う準備もあるのだった。

© Fumihiro Kato.
Unauthorized copying and replication of the contents of this site, text and images are strictly prohibited. All Rights Reserved.

・スタジオ助手、写真家として活動の後、広告代理店に入社。 ・2000年代初頭の休止期間を除き写真家として活動。(本名名義のほかHiro.K名義他) ・広告代理店、広告制作会社勤務を経てフリー。 ・不二家CI、サントリークォータリー企画、取材 ・Life and Beuty SUNTORY MUSEUM OF ART 【サントリー美術館の軌跡と未来】、日野自動車東京モーターショー企業広告 武田薬品工業広告 ・アウトレットモール広告、各種イベント、TV放送宣材 ・MIT Museum 収蔵品撮影 他。 ・歌劇 Takarazuka revue ・月刊IJ創刊、編集企画、取材、雑誌連載、コラム、他。 ・長編小説「厨師流浪」(日本経済新聞社)で作家デビュー。「花開富貴」「電光の男」(文藝春秋)その他。 ・小説のほか、エッセイ等を執筆・発表。 ・獅子文六研究。 ・インタビュー & ポートレイト誌「月刊 IJ」を企画し英知出版より創刊。同誌の企画、編集、取材、執筆、エッセイに携わる。 ・「静謐なる人生展」 ・写真集「HUMIDITY」他
投稿を作成しました 532

検索語を上に入力し、 Enter キーを押して検索します。キャンセルするには ESC を押してください。

トップに戻る