今回はNAS側から読めなくなったRAID0のデータを、Linuxを使って取り出せたお話をします。
先に言っておくぞ！
この方法なら壊れたRAID0のデータを必ず取り出せるという話ではありません。 僕的には今回の結果は奇跡だと思ってます。 あくまで「運の良かった一例」で、こういう風に取り出せる可能性が「ワンチャンある」程度の温度感で読んでくださいね。
いやねぇ…。
僕自身、RAID0はそれなりに触ってきたんですけども、今のご時世だとたぶんデメリットの方が大きくて。 復旧どうのこうのより、そもそもRAID0は非推奨だと思います。
個人のデータ保存NASでRAID0運用はレアケースだとは思いますが、RAID0のリスク、今回の経緯、試した内容をまとめておきたいと思います。
あと、そう。
RAID0の記憶を遡ってたら、自作始めた昔のことをいろいろ思い出したので、最後にそれも書いておきますね。 本当に僕の思い出話なので、読まなくていいです。
RAID0の特徴とリスク
昔は自作始めてある程度立つと、パフォーマンス向上のためにRAIDが視野に入ることがけっこうありました。 今はSSDのおかげで全然そんな感じじゃないと思います。
この辺は末尾で思い出に浸りますね。
RAIDというのは、複数のHDDを組み合わせて動作させる仕組みで、
- RAID0：ストライピング。複数のHDDに分散書き込みすることで、書き込み速度が上がる。
- RAID1：ミラーリング。複数のHDDに同じ内容を書き込むことで、片方がクラッシュしてもデータが取り出せる。
あとまぁRAID5とかもあるんですけど、今回は関係ないです。
要は、HDDの遅さがボトルネックになってた時代に流行ってたのがRAID0＝ストライピングです。 2台に並列書き込みする仕組みですが、実際のパフォーマンスは単純に2倍になるわけではありません。
対してHDDの故障リスクはきっちり2倍！
分散書き込みするせいで、ひとつのファイルが複数のHDDに分散して保存されるので、どっちかクラッシュするだけでデータが取り出せなくなる非常に危険なモードでもあります。
今ストライピングが現役の環境ってあるんですかねぇ。
僕はそういう仕事じゃないので現場のことは分からないですけども、末端のPCユーザーだと、速度が欲しいならSSD使えばいいし、ストライピングはリスクばっかりが目立つようになってる気がします。
対して、ミラーリングの方は現役です！
2台のHDDに同じ内容を書き込むから、片方が壊れてもデータを取り出せます。 個人的にいいなと思うのは、片方が壊れた時点で、HDDの劣化具合を知ることができて、
この機会に2台ともHDDを交換しておくか。
みたいな対応が取れること。 理想的には一家に一台ミラーリングNASがあってもいいんじゃないかと思ってます。 コストの壁はありますけども。
ただ、ミラーリングも無敵じゃなくて…。
2台同時にクラッシュする確率はゼロじゃないので、絶対無敵というわけでもないです。
理想的には、NASでミラーリング、NASの内容を外付けHDDにバックアップ、さらにそれのバックアップ…とか考え出すと切りがないです。 データ全ロスの可能性をガクンと減らすために、NASを導入するのはお手軽でコスパはいいのかなと。
今回の事件の経緯
事件は言い過ぎじゃないかって？
バカ野郎！本人は涙目だったぞ！
えー、今回の事件はですね。
NASのデータが読めなくなった！助けて！
って友人から相談があって、仕事でも使ってるデータが入ってるから、データが飛ぶとすげー困るとのこと。 まぁ、破損が片方ならデータ自体は取り出せるんじゃないかと思って、NASを持って来てもらったところ、
ちょっと！？RAID0になってるけど！？
NASなのに！？ええええぇぇぇ！？！？
となったところから事件はスタートします。
さっきも言ったように、RAID0＝ストライピングは分散書き込みのせいで、今だとリスクの方が大きいです。 特にNASの場合、LANの速度制限(1Gbpsとか)が入るから、ストライピングのメリットはほとんどないはず。
なんでRAID0にしてたのかは結局よく分からなかったんですが、とりあえず、データを読み出せなくなったRAID0のNASが目の前にあります。
どうすんの、これ…。
友人には、
- 基本的に破損したRAID0からデータは取り出せない
- 取り出すには復旧専門業者に依頼する必要があり、かなり高額になる可能性がある
- オレにはたぶん無理
ってのを説明した上で、できる限りのことをやってみることにしました。 他人事ながら冷汗が出てきます…。
ちなみに。
昔から似たような事件はありまして。
裏返して置いてたCD-Rのデータが読めなくなった！助けて！
ってことがあって、何やら中身は大事なデータだそうです。
今の人はもう存在すら知らないかもしれないCD-Rですが、USBメモリ登場より前は、書き込み可能なCDにデータを保存する時代があったんです。 ほんとなんです、信じてください。
「CD-Rを焼く」なんて表現してましたが、実際には記録層をレーザーで変質させて、反射率の違いで0と1を識別する仕組みだったらしいです。 イメージとしては、「生肉」なら0、「上手に焼けました」なら1、みたいな感じ。
記録面(裏面)は光や熱に弱いので、裏面を表に向けて置いていたりすると劣化しやすく、保存状態が悪いと読めなくなることがよくありました。
結局、彼のCD-Rは中身を取り出せませんでした。 ラベルには「青い空」と書かれてましたが、
一体、何のデータが入ってたんでしょうねぇ…。
実際にデータを取り出すまでの流れ
今回、データの取り出しに成功しましたが、僕はNAS復旧の仕事をしているわけでもないし、Linuxを触ったこともありません。 なので、
AIに頼る！
という暴挙に出ています。 大事なデータ復旧に当たって、AIの回答をそのまま信用して作業するというのは通常ありえないことだと思います。
今回は、なるべく可逆な作業(元に戻せる作業)に限定するということで、友人の同意を得られたので、この段取りになりました。 今回の結果はひとつの例にはなると思いますが、あくまでAIに聞いた結果だというのは判断の材料にしてください。
NASの状態の確認
今回の事件の被害者はBUFFALOのLS500というNASでした。 ちょっと古いモデルみたいで、現行機種はLS510だそうです。
BUFFALOの名誉のために先に言うぞ！
LS500がデフォルトでRAID0＝ストライピングになっているわけではありません。 PDFマニュアルでは「デフォルトはRAID1」と書いてありました。
RAID0に設定したのは友人です。 本人は否定してますがね。
BUFFALOのNASには「NAS Navigator2」というツールがあって、それを使うとネットワーク内のBUFFALOのNASを見つけてきて、現在のステータスを確認できます。 Navigator上では「ディスク2にエラーがあります」と出ていました。
SMARTを確認すると、以下の数値が高くなっていました。 ChatGPTにも確認しましたが、HDD故障でよく見られるパターンだそうです。
- Reallocated Sector Count
- Current Pending Sector
- Offline Uncorrectable
あまり良くない状態らしくて、無駄なアクセスは控えたい状況。
ChatGPTは、NASツールで「初期化やRAID再構築、チェックは絶対にするな」と言ってきました。
BUFFALOのトラブルシューティングには「チェックを実行する」という手順も書いてあったため、実際には「チェック」は数回実行しています。
ChatGPTによると「チェックの過程でRAIDのメタデータが壊れる可能性もある」とのことで、本来はあまり触らない方がよい操作らしいです。 結果的に今回は問題ありませんでしたが、この判断はケースによると思います。
BUFFALOのマニュアルを元に、NAS Navigatorでできることを試しても、結局この段階でNASの中身は読めませんでした。
ここからの方針
ここから先は何をどうすればいいか分からなかったので、友人の同意を得た上で、ChatGPTに方針を確認します。
ヘイ！チャッピー！
故障の程度によって、「何かできる場合もある」し、「復旧業者に頼るしかないケースもある」とのことでした。 今回は、ディスクがまだ読める可能性がある場合に試せる方法として、以下の手順を提案されました。
- NASからHDDを取り出す
- SATAケーブルと電源ケーブルで、PCにHDDを接続する
- USBからUbuntu(GUIのあるLinux)を起動
- Ubuntu上からHDDを確認
- Ubuntu上からRAIDを認識させる
- RAIDからローカルディスクにデータをコピー
PCへ接続するには、自分のPCのカバーを外してHDDを接続する知識が必要になります。 SATAケーブルの予備が必要な場合もあるし、メーカー製PCやBTOの場合だとSATA電源が足りない場合もあります。
PCの分解やパーツ接続に慣れていない場合は、無理をせず復旧業者にお願いした方が安全です。
Ubuntuは今回初めて触りました。 Linuxってコマンド操作のイメージでしたが、Windowsみたいに操作できたし、根気さえあればここは不慣れな人でもできそう。
僕は「たぶんできそう」と判断したので、この方針で先へ進みます。
ここからは僕の方がストレスフルでの作業になりました。
作業予定のPCの構造を確認
ここからは、HDD接続とLinux準備のどちらを先に進めてもいいんですが、 ケーブル不足で1日置くことになったので、先にPCの中身を確認した方がいいと思います。
HDDを2台接続する場合、
- マザーボードのSATAポート ×2
- 電源ユニットのSATA電源 ×2
が必要になります。
今回、復旧作業に使用したPCはDELL製で、SATAポートは3つありました。
ただし電源側のSATAコネクタが足りません。
内蔵SSDに刺さっていた電源は標準サイズで使えましたが、 光学ドライブに刺さっていたものは小型のコネクタで、HDDには使えませんでした。
結果的にはSSDに刺さっていた電源をYスプリッターなるもので分岐して、NASのHDD2台に接続しました。
近所の電気屋で手に入らないこともあると思うので、事前の確認はしておいた方がいいと思います。
USBメモリに起動用Ubuntuを用意
これも準備に1～2時間くらいかかりました。
NASの多くはEXT4というファイルシステムで、Windowsからは読めません。 EXT4を読むにはLinuxというOSが必要になります。
Windowsみたいな長いインストールは不要で、起動用のUSBメモリがあれば起動できます。
まず、UbuntuのISOファイルをダウンロードします。
僕が見た時は、この3種類があって、
- Ubuntu 24.04.4 LTS (Intel or AMD 64-bit architecture)
- Ubuntu 25.10 (Intel or AMD 64-bit architecture)
- Ubuntu 25.10 (ARM 64-bit architecture)
「LTS」というのが安定版らしいので、これをダウンロードしました。 6GBくらいあったので、USBメモリは8GB以上のものが必要です。 この後の操作でUSBメモリの中身はすべて消えるので、先にバックアップを取っておいてください。
次に、このISOファイルから起動可能なUSBメモリを作るRufusというソフトウェアをダウンロードしました。
両方のダウンロードが終わったら、Rufusを起動して、「デバイス」にUSBメモリを指定して、「ブートの種類」で先ほどのISOファイルを選択し、あとは「スタート」を押してしばらく待ちます。
USBメモリからUbuntuを起動
Ubuntuの起動USBメモリができたら、PCをUSBメモリから起動します。 NASのHDDはSATAと電源ケーブルを接続しておいてくださいね。
通常のPCは電源を入れると内蔵ディスク（Windows）から起動しますが、 起動デバイスをUSBメモリに変更するとUbuntuを起動できます。
方法はPCのメーカーやマザーボードによって違いますが、 起動直後に以下のキーを押すと「Boot Menu」が出ることが多いです。
- F12
- F11
- F8
- DEL
このメニューからUSBメモリを選択すると、Ubuntuの起動画面が表示されます。
もしBoot Menuが出ない場合は、「PCメーカー名 + USB起動」などで検索すると手順が見つかると思います。
Ubuntuの起動メニュー
ここからは僕も必死で、細かいログ残してません。
失敗すると思ってたからブログにまとめる予定なかったのよ。
USBメモリからの起動に成功すると、
- Try/Install Ubuntu
- セーフモードで起動
- 他の起動モード
みたいなシンプルな起動メニューが出ました。
ChatGPTは「Try Ubuntu」と言っていたので、一番上を選択。
その後、Windowsとは違う独特の色合いのOSが立ち上がり、この段階で「Tryする？Installする？」みたいな画面が出てきたので、「Try」を選択。
ニュアンスとして、「Try」はUSBメモリからそのままUbuntuを起動するモード、「Install」はPCのHDDにUbuntuをインストールするモードです。 「Try」で問題ありませんでした。
ターミナルの起動
次にターミナルを起動します。 Windowsでいうところのコマンドプロンプトみたいなものです。
左側のメニューに「Terminal」があるという話だったのですが、僕の環境では見つかりませんでした。 Ubuntuのバージョンによるのかもしれません。
僕がやったのは、画面左上をクリックして検索画面を開く方法です。
すると画面上部に、Windowsの「ファイル名を指定して実行」みたいな検索欄が出てくるので、ここに「Terminal」と入力すると候補に出てきました。
「lsblk」でディスクの状態を確認
ターミナルで「lsblk」と入力します。
このコマンドは、接続されているストレージ(HDDやUSBメモリ)を一覧表示するコマンドのようです。
ずらずらーっと表示され、今回関係あるのはこの部分。
sda
├sda1
│└md127
│ └md127p1
└sda2
sdb
├sdb1
│└md127
│ └md127p1
└sdb2
「sda」「sdb」はHDD、「sda1」「sdb1」などはパーティション、「md127」はRAID構成、「md127p1」はRAID内のパーティションだそうです。
この時点でここまで見えてなければ、今回の方法での復旧は難しいそうです。
これ以上何も触らずに、復旧業者へ持ち込んだ方がいいと思います。
どれが目的のHDDかは、環境によって多少変わることがあるみたいで、容量などから判断してください。 この先の作業で必要になるのは、RAIDパーティションの名前です。 今回の環境では「md127p1」という名前でした。 「raid0」以下にある「part」の部分ですね。
RAIDをマウントする
引き続きターミナルから以下のコマンドを実行します。
sudo mkdir /mnt/nas
sudo mount /dev/md127p1 /mnt/nas
1行目はマウント用のフォルダを作成、2行目はさっきのフォルダにRAIDをマウントするコマンドです。
この時点でも詰みポイントはあって、RAID構成やファイルシステムが破損している場合は、マウントに失敗することがあるようです。 これ以上何も触らずに、復旧業者へ持ち込んだ方がいいと思います。
逆に、ここまでいけるとデータを取り出せる可能性が高いみたい。
今回の実行結果は、こんなメッセージが出ていました。
一瞬ヒヤッとしましたが、Linuxの設定の話らしくて、データ復旧には関係ないみたいです。
ドキッとするからやめてよね…。
Filesで開く
ここからはGUIで操作可能でした。
左側のメニューにフォルダアイコンの「Files」があるので起動します。 Windowsで言うところの「エクスプローラ」です。
「Files」内の左メニューにさっきの「/mnt/nas」があるという話でしたが、下までスクロールしてもありませんでした。
しゃーないので、「Files」上部のパス入力欄のような部分に「/mnt/nas」と入力すると、NASの中身が見え…
見えたぁぁぁぁ！！！
友人とふたりで、リアルに「うおおおおおお！」って声が出てました。 見えてよかったです。 ほんとによかったです。
待ってくださいね。
嬉しいのは分かりますが、壊れかけてるHDDに対して、変に中身を確認しようとすると、その段階で読み取りエラーが増える可能性があります。 ここはぐっと我慢です。
なお、マウントはできたけど中身が見えない場合もあるようで、その場合は復旧業者へ持ち込んだ方がいいと思います。
内蔵HDDなどへ救出
最後に、実際にデータを救出します。 ここからは壊れかけのHDDにガッツリアクセスしていくので、リアルタイムで読み取りエラーが増えていく可能性があります。 不要なアクセスはなるべく避けて、とにかく救出を優先します。
まず、先ほどの左メニュー「Files」を右クリックして、新しい「Files」ウィンドウを起動します。 こっちにはバックアップ先を表示します。
基本的には内蔵HDDを指定すればいいです。 僕は電源ケーブルの都合で内蔵HDDを取り外していたので、自宅のNASへバックアップしました。 NASへのアクセスは、左メニュー下の方の「Other Locations」から「Network」を選択でできました。
あとは、マウントしたNAS内のフォルダをひとつずつ、バックアップ先へコピーしていきます。 ひとつずつにしたのは、エラーが出た場合にどのフォルダのファイルかを特定しやすくするためです。
Windows同様に「Ctrl+C」「Ctrl+V」は使えました。
大容量の「trashbox」というフォルダがありましたが、これはおそらくごみ箱＝「中のファイルは不要と判断されたもの」なので、復旧は最後に回しました。 最悪、そこまでの過程でHDDが壊れても、損失が少ないとの判断です。
途中、「Input/output error」が出たファイルがありました。
壊れているディスク領域にあるファイルで、この方法では取り出し不可能みたいです。 後で確認するために、画面の写メを残したり、ファイル名をメモしてる方がいいと思います。
この手のファイルも、専用業者では復旧できる場合があるとのことでした。 大事なファイルだった場合は、業者持ち込みを検討してください。
最終結果！
1万ファイルくらいで、取り出せなかったのは1ファイルだけでした。 HDDのSMARTから考えると、かなり運が良かったみたいです。 友人も、そのファイルは家のPCにも残ってるから困らないとのことでした。
他人事ながら、ほんとに冷や冷やする作業でした…。
二度とやりたくないんじゃヴォケぇ！！
今回の教訓とか感想とか
今回の教訓はこんな感じです。
- データ保存のNASにRAID0はやっぱり危険
- NASでもバックアップは必要
- Linuxでワンチャン取り出せる場合もある
- 基本は復旧業者案件
今回はどう考えてもかなり運が良かったケースで、RAID0でも壊れたら「Linuxで取り出せるかも」に賭ける運用には、とてもじゃないができません。 リスク大きすぎ。
99％以上のデータを救出できたのは、本当に運が良かったです。
NASのRAID設定は100万回見直しましょう。
あと、今回はChatGPT頼りでの復旧作業だったわけですが、皆さんご存じの通り、奴はけっこういい加減なことも言います。 ただ、NAS復旧も初めて、Linuxも初めてな身からすると、画面の写メを貼り付けて、
こんな画面になった！次はどうすればいい！？
で、ケースに応じた対応をしてくれるので、ネットで調べて得られない情報を得られる場合もあります。 まぁそこがウソの場合もあるわけですが。
ネットの情報と並べて使う分には、わりと悪くない選択肢だったのかもと思いました。 結果的にデータを取り出せたしね。
オマケ：山田メガネ少年とRAIDの出会い
僕の自作歴は2000年まで遡ります。
その前から親父のPCをちょこちょこ触らせてもらってました。 当時はメーカー製PCと自作PCの値段の差が最も大きかった時代で、それで親父が自作やってたんですね。 AMD派だったので、K6-Ⅱを触ってました。
大学に入るにあたって、自分用の自作PCを始めたわけです。
当時はCPU300MHz、メモリ64MBとかの時代ですからね。 今の性能から考えるとビックリでしょ？
毎月DOS/Vマガジンをワクワクしながら読んで、
L2キャッシュがCPU内蔵！？すげー！！
ってなって、爆熱K6-Ⅲをご機嫌で使ってました。 親父が使ってたK6-Ⅱの後継です。
もちろんお金はなかったから、CPUやメモリをオーバークロックで性能を上げようとしたり、2chでオーバークロック耐性を調べたり、けっこう楽しんでました。 確かK6-ⅢはOC耐性なかったんですけども。 今じゃ作業用PCでオーバークロックなんかありえない感覚ですね。
その中で、HDDも遅かったもんだからいろいろと調べてると、何やらRAIDなるシステムで並列書き込みできて速度アップできるとか。
RAID0最強かっ！？
今回のトラブルの原因になった子ですね…。
当時はRAIDするにはRAIDカードが必要で、なんだったかな、「RAIDカードならココ！」ってメーカーがあったんです。 Promiseだったかな。 バイトしてそこのエントリーモデルを買いました。 基本はサーバPC用とかで、エントリーモデルでも高かった記憶。
んで、ルンルンでストライピングしてみたものの、思ったほど速くなった気がしない…。 その上、早々にシステムドライブが壊れてしまって、僕の記憶に強く残ることになります。
ストライピングは危険だぁぁぁ！！
まぁ、当時はね、まだ一般用途でWindows2000があまり浸透してない時期で、毎月のようにWindows98を再インストールしてたので、被害は軽微でした。 この時の経験で、システムドライブとデータドライブを物理的に分ける、という方針は今も引き継がれています。
その後は、CPUとGPUが異常なレベルで進化していったので、HDDの遅さが特に気になる時代になりました。 その頃には高いマザーだとオンボードでRAIDチップが載ったりしてましたが、以降、僕がRAIDに手を出すことはありませんでした。
次に手を出したのはWDだったかな？が出してた1万RPMで高速なRaptorってHDDですね。 残念ながらこれもそんなに速度を体感できず、おまけに爆熱なもんだから、HDDクーラー付けたりして使ってました。
その後は、みなさんもご存じSSDの登場ですね。 自作歴25年くらいの中、体感の速度差を最も感じられたのがSSDでした。 革命でしたね、アレは。
今じゃSSDの速度で僕は十分だと感じてるので、二度とRAID0に触れることはないと思ってたところに、今回の事件だったので、いろいろと思い出してみました。
もっかい言いますが、
RAID設定には気をつけましょうね…。
活動支援として、Appleのギフトカード、作業中のおやつなどで応援お願いします。
🎁 Amazonから応援