RAIDの再構築(リビルド)を始めた後、進捗が止まったり、I/Oエラーやドライブ脱落が表示されたりすると、もう一度実行すれば完了するのではないかと考えやすいものです。
しかし、途中停止した時点では、開始前と比べて交換先ディスクや構成情報が変化し、残存ドライブへ長時間の読み取り負荷がかかっている可能性があります。
重要なデータがRAIDにしかない場合、最初に行うのは再実行ではありません。
自動再構築や通常の書き込みを止め、進捗率、エラー全文、ドライブ順、開始前後の状態を保存し、元の構成を変えない救出方法を選びます。
この記事では、NASや小規模サーバーのRAID再構築がエラーで止まった時に、初心者が何を、なぜ、どの順番で確認すべきかを解説します。
メーカーや機種で停止方法や表示名が異なるため、画面を推測で操作せず、現在の状態と公式情報を照合しながら判断してください。
目次
RAID再構築が止まったら同じ処理をすぐ再実行しない
結論からいうと、再構築がエラー停止した直後は、同じリビルドを繰り返さず、RAIDへの書き込みと自動処理を止めることが優先です。
一度目の停止原因が残ったまま再実行すると、弱っているドライブを再び全域読み取りし、残っているデータの状態をさらに変えるおそれがあります。
リビルドは、故障と判断されたドライブの内容を単純にコピーする作業ではありません。
残存ドライブからミラーやパリティの情報を読み、交換先へ大量のデータを書き直すため、読み取り元、書き込み先、筐体、電源、コントローラーのどこかに問題があると停止します。
「再開」や「再試行」のボタンが表示されても、それはデータが安全という判定ではありません。
必要なデータの別コピーがなく、原因が特定できていないなら、ボタンを押す前に現状を記録し、救出と機器修復を分けて考えます。
再構築を始める前の基本判断は、RAID崩壊時にリビルドを急がない理由でも確認できます。
本記事では、すでに開始して停止した後の行動に絞って整理します。
エラー停止は「交換ディスクの不良」だけを意味しない
RAID再構築の停止原因は一つではなく、エラー文だけで故障ドライブを断定できません。
交換した新品ディスクが認識しない場合もあれば、読み取り元として残ったドライブの不良セクタ、電源不足、ベイの接触、コントローラーの不調で止まる場合もあります。
特に注意したいのは、管理画面で「正常」と表示されていた残存ドライブです。
通常利用では読まれなかった領域がリビルド中に初めて読まれ、そこでエラーが表面化することがあります。停止したからといって、交換先だけをさらに別のディスクへ替えれば解決するとは限りません。
停電、瞬断、強制終了、ファームウェア更新、筐体の過熱でも処理は止まります。
原因が電源系に見えても、停止前までにどこまで書き換えられたかは別問題です。再起動後に表示が変わることもあるため、現在画面を保存してから電源操作を判断します。
- 残存ドライブから読み取れず停止した
- 交換先ドライブへ書き込めず停止した
- ドライブベイ、ケーブル、電源、コントローラーの経路で切断した
- 停電や強制終了で処理が中断された
- 構成情報やドライブ順が開始時の前提と一致していない
- ファイルシステムやボリューム側にも別の障害がある
このように可能性を分けると、やみくもな交換と再試行を避けられます。
原因を断定するためではなく、次の操作で原本を変えないための分類として使ってください。
最初の10分で行う安全な初動

最初の10分は、直す操作よりも停止、観察、記録に使います。
異音や焦げ臭さなど緊急性の高い症状がなければ、画面を閉じたり再起動したりする前に、表示中の情報を写真またはスクリーンショットで残します。
- 利用者へ共有フォルダへの保存と編集を止めるよう伝える
- 同期、録画、バックアップなどRAIDへ書き込む処理を接続元で止める
- 進捗率、停止時刻、エラー全文、対象ドライブを記録する
- NASやサーバー本体、ベイ、ランプ状態を全体写真で残す
- RAIDレベル、ドライブ本数、容量、スロット順、交換履歴を控える
- 異音、強い発熱、焦げ臭さ、認識と切断の反復を確認する
- 問題のRAIDを動かさず、別のバックアップや端末コピーを探す
カチカチ、ガリガリといった異音、焦げ臭さ、煙、触れにくいほどの発熱がある場合は、画面情報より安全確保を優先します。
一方、動作中にいきなり電源ケーブルを抜くと別の書き込みを中断する可能性があるため、異常の種類、機種の停止方法、現在の処理状態を踏まえて判断します。
正常なバックアップがあるかは、問題の機器を操作せずに確認できます。
データ復旧前に確認したいバックアップと保存場所を参考に、USB媒体、別NAS、クラウド、利用端末、メール添付などを確認してください。
初動の目的は、すぐに原因を当てることではありません。
停止後にしか残らない情報を保存し、データが唯一の原本か、どこまで自力確認できるかを決めることが目的です。
電源操作の前に進捗・構成・ログを保存する
再構築が止まった後は、電源操作によって管理画面の表示、イベントログ、ドライブ認識順が変わることがあります。
再起動が必要そうに見えても、まず進捗と構成を保存し、停止前後を比較できる状態にします。
保存したいのは、エラー番号だけではありません。
開始日時、停止日時、停止した進捗率、交換したベイ、交換前後のドライブ情報、残存ドライブの警告、実行した操作を時系列で残します。画面は一部分ではなく、ページ全体と詳細画面の両方を保存すると役立ちます。
| 記録する項目 | 記録する理由 |
|---|---|
| メーカー・型番・RAIDレベル | 再構築方式と許容故障台数を確認するため |
| 各ベイの容量・型番・シリアル | ドライブ順と交換履歴を混同しないため |
| 停止した進捗率と時刻 | どの段階で異常が表面化したか整理するため |
| エラー全文・イベントログ | 読み取り、書き込み、切断、電源を切り分けるため |
| 異音・発熱・切断の有無 | 物理障害を疑い通電を止める基準にするため |
| 開始前後に行った操作 | 構成が変化した範囲を把握するため |
ドライブを抜く必要が生じても、先に本体全体とベイ順を撮影し、一本ずつ対応が分かるよう記録します。
複数台を同時に抜いて机へ並べると順番を失いやすいため、構成情報と物理位置をセットで残してください。
再構築がどこで失敗したかを4系統に分ける
次に、エラーの発生場所を「読み取り元」「書き込み先」「接続経路」「電源・制御」の4系統に分けます。
これは自力で修理するためではなく、同じ失敗を繰り返さず、データ救出に必要な原本を守るための整理です。
残存ドライブの読み取りで止まった可能性
リビルドは残存ドライブの広い範囲を連続して読み取るため、潜在的な不良セクタや読み取り不安定が表面化します。
停止前に速度が極端に落ちた、同じ進捗で長時間動かない、残存側にSMART警告が出た場合は、再読込を重ねない判断が重要です。
SMARTは安全を保証する判定ではなく、状態情報の一部です。
値を確認する場合も、長時間の完全テストや修復を追加せず、SMART警告時にクローン前に確認することを参考に、音、速度、切断、重要度と合わせて判断します。
交換先ドライブへの書き込みで止まった可能性
新品でも初期不良、容量差、規格不一致、ファームウェア相性があり、書き込み先として安定するとは限りません。
同じ公称容量でも実セクタ数がわずかに小さいと、交換先として受け付けない機種があります。
ただし、交換先の問題に見えても、残存側から読めないため書き込みまで進めない場合があります。
交換先だけを次々入れ替えると操作履歴が複雑になり、自動再構築が繰り返されることもあるため、エラー内容と開始条件を記録してから判断します。
ベイ・ケーブル・電源・コントローラーで止まった可能性
ドライブ自体が読めても、ベイの接点、SATA・SASケーブル、電源供給、バックプレーン、RAIDコントローラーで切断すれば再構築は止まります。
複数ドライブが同時に消えた、再起動ごとに認識ベイが変わる、筐体全体が不安定なら、単独ドライブの故障と決めつけません。
ケーブルの差し直しや別ベイへの移動は簡単に見えますが、元の位置情報を失ったり、自動初期化や再構築を誘発したりする可能性があります。
唯一の原本なら、構成を記録せずに接続経路を入れ替えないでください。
停電・強制終了・ソフトウェアで止まった可能性
停電や瞬断で止まった場合、ドライブが壊れていなくても処理途中の状態が残ります。
復電後に自動再構築が始まる機種もあるため、通電前にバックアップの有無と停止時の情報を整理します。
ファームウェア、管理ソフト、コントローラー設定の問題も考えられますが、更新や設定初期化は構成認識を変える操作です。
データ保全前に「最新化すれば直る」と進めず、現バージョンと設定を保存してください。
再実行前に避けたい操作
再構築が止まった後は、試行回数を増やすほど状況が分かりやすくなるとは限りません。
むしろログが上書きされ、ドライブ状態が変化し、どの構成が元だったか分かりにくくなることがあります。
- 原因不明のまま「再実行」「再同期」「修復」を繰り返す
- 警告表示だけを根拠に別の残存ドライブを交換する
- 複数ドライブを同時に抜き、順番を入れ替える
- 一台ずつWindowsやMacへ接続して初期化・フォーマットする
- 新しいRAID、ストレージプール、ボリュームを同じドライブで作る
- 整合性チェック、スクラブ、全域SMARTテストを追加する
- ファームウェア更新や設定初期化を先に行う
- 復元先を同じRAIDや交換途中のドライブへ指定する
- エラーを無視して通常業務、録画、同期、バックアップを再開する
RAID 1のようなミラー構成でも、片側を単独で読めるとは限りません。
暗号化、独自パーティション、ボリューム管理、更新時点の差があるため、OSが初期化を求めても実行しないでください。
機器を再び使えるようにする修理と、現在残っているデータを取り出す作業は目的が異なります。
判断に迷う場合は、データ復旧とパソコン修理の違い・依頼順序を確認し、必要データを先にするか決めます。
まだ共有やボリュームを読める時は重要データからコピーする
再構築停止後も共有フォルダを読める場合、通常業務へ戻すのではなく、必要データの退避を優先します。
ただし、異音、切断反復、強い発熱、読み取り速度の急低下がある時はコピー自体が負荷になるため、自力作業を止めます。
コピーできる条件がそろうなら、最初に業務継続に必要で、別の保存先に存在しない、小容量のデータから選びます。
フォルダ全体を一度に動かすより、会計、顧客、契約、制作原稿など優先順位を決め、コピー先は問題のRAIDとは別の正常な媒体にします。
- 別コピーがない重要データを一覧にする
- 小容量で開く必要が高いファイルを先にする
- 問題のRAIDとは別の正常な保存先を用意する
- 移動ではなくコピーを使い、元データを削除しない
- コピー後に保存先でファイル数、容量、代表ファイルを確認する
- 速度低下、エラー増加、切断、異音が出たら中止する
コピーできたファイルも、開けるか、更新日時が正しいか、必要な関連ファイルがそろっているか確認します。
成功表示だけで原本を消さず、救出結果を検証するまでRAIDの再構築や初期化へ進まないでください。
データ救出方法は原本を変えない順に選ぶ

安全性を優先するなら、問題のRAIDへ追加書き込みを行わない方法から検討します。
正常なバックアップ、別端末コピー、スナップショットがあれば、まずそれらを隔離した環境で確認します。
正常な別コピーから必要データを戻す
必要な時点のバックアップがあり、内容を別環境で検証できるなら、故障RAIDを直す前に業務用のコピーを作れます。
ただし、バックアップ先が問題のNASと常時同期されていた場合は、削除や破損も反映されていないか確認します。
まだ読めるボリュームから別媒体へコピーする
物理的な危険症状がなく、読み取りが安定している場合だけ、重要度順のファイルコピーを検討します。
ファイル移動、整理、削除、アクセス権変更は行わず、元のRAIDを読み取り元として扱います。
構成ドライブを複製し、複製側で仮想的に再構成する
ボリュームを読めない、複数ドライブが不安定、再構築で状態が変わった場合は、各ドライブの原本を保全し、可能な範囲でセクタ単位の複製を作ってから解析する方法があります。
複製側でRAIDパラメーターを検証すれば、原本へ再構築を書き込まずにファイルシステムを探せます。
ただし、不安定なドライブの複製は、読み取り順、再試行回数、冷却、接続機器によって負荷が変わる専門作業です。
異音、切断、認識不安定、複数台障害がある状態で一般的なコピーソフトを何度も試すと悪化する可能性があります。
専門相談では、原本ドライブを直接再構築しないか、クローンやイメージを作ってから解析するか、復元先を別媒体にするかを確認します。
費用や対応方法を比べる時は、データ復旧業者の料金と特徴を比較した記事も判断材料になります。
どの方法でも、救出先を問題のRAIDにしないことが共通です。
原本、作業用複製、救出先を分けることで、途中結果に問題があっても最初の状態へ戻って検討できます。
RAIDレベルごとに再実行の危険度を考える
RAIDレベルによって冗長性と再構築方法は異なりますが、名称だけで安全とは判断できません。
実際のドライブ本数、どのベイが交換されたか、過去の警告、容量差、独自方式を合わせて確認します。
| 構成 | 停止後に特に確認する点 |
|---|---|
| RAID 0 | 通常は冗長性がなく、一台欠損をリビルドで補う前提ではない。新規作成を避ける |
| RAID 1 | どちらが新しいか、両方が安定して読めるか、途中同期で内容差が生じたか |
| RAID 5 | 残存ドライブに追加の読み取り不良がないか、一台故障という前提が正しいか |
| RAID 6 | 二台分の冗長性だけで安全と決めず、三台目の不安定や構成不明がないか |
| RAID 10 | 故障台数だけでなく、同じミラー組の組み合わせを失っていないか |
| 独自方式 | 一般的なRAID名へ推測で置き換えず、メーカー情報と構成履歴を残す |
RAID 5で一台を交換した後に止まった場合、さらに別の一台を交換すると、構成成立に必要な情報を失うおそれがあります。
RAID 6でも複数台の読み取り不良や順番違いがあれば、許容台数の数字だけでは判断できません。
RAID 1では、残った側を正しい原本と決めつけず、更新時点と状態を確認します。
途中同期によって一部だけ新しくなっている可能性もあるため、重要ファイルの日時や内容を別媒体へ救出して検証します。
自力作業を中止して相談する基準
データが唯一の原本で、再構築が一度でもエラー停止したなら、専門相談を早めに検討する価値があります。
特に複数ドライブ障害、異音、認識の変化、業務停止につながる重要データがある場合は、試行回数を増やさない方が安全です。
- 二台以上のドライブに警告、未認識、I/Oエラーがある
- カチカチ音、擦れる音、焦げ臭さ、強い発熱がある
- 通電や再起動のたびに認識台数、ベイ、容量が変わる
- 元のドライブ順、RAIDレベル、交換履歴が分からない
- 途中まで再構築された後、ボリュームが見えなくなった
- 暗号化、仮想マシン、データベースなど整合性が重要である
- 正常なバックアップがなく、必要データがRAIDにしかない
- 一般的なコピーでも速度低下、エラー増加、切断が起きる
反対に、検証済みの完全なバックアップがあり、RAIDを初期化しても必要データを失わない場合は、機器修復を優先できることがあります。
ただし復元テストをしていないバックアップは、ファイル名が見えるだけで正常とは限らないため、代表ファイルを別環境で開いて確認します。
相談前に準備する情報
相談時は、原因を自分で断定する必要はありません。
観察した事実と実行済み操作を分けて伝えると、追加操作を減らし、必要な診断方法を選びやすくなります。
- NAS・サーバー・RAIDカードのメーカーと型番
- RAIDレベル、ドライブ本数、各容量、ホットスペアの有無
- 各ベイの型番・シリアル・元の位置
- 最初に異常へ気づいた日時と症状
- 交換したドライブ、交換日時、選んだ操作
- 再構築の開始時刻、停止時刻、進捗率
- 画面のエラー全文、イベントログ、警告写真
- 異音、発熱、停電、落下、水濡れの有無
- 再起動、差し直し、再試行、診断など実行済み操作
- 必要なデータの種類、容量、優先順位、希望時期
- バックアップ、クラウド、別端末コピーの確認結果
梱包や持ち込みでドライブを外す場合は、ベイ番号とシリアルの対応が分かるよう一本ずつ管理します。
静電気、衝撃、湿気を避け、ラベルを磁気面や通気孔へ貼らないようにしてください。
「何度か再実行した」「途中で電源を切った」といった操作も隠さず伝えます。
責任を問うためではなく、どこまで構成が変わったか、原本と複製をどう扱うかを判断するために必要な情報です。
復旧後は再構築とバックアップを分けて備える
データを救出できた後は、同じRAIDへ戻す前に、機器の原因とバックアップ設計を分けて見直します。
RAIDはドライブ故障時の継続性を高める仕組みですが、誤削除、上書き、ランサムウェア、停電、筐体故障、複数台障害から過去のデータを戻すバックアップではありません。
- RAIDとは別の機器へ世代バックアップを取る
- 重要データはオフラインまたは別拠点にも保管する
- バックアップから代表ファイルを定期的に復元テストする
- SMART、温度、容量、ドライブ警告を定期確認する
- UPSで停電・瞬断へ備え、停止手順を共有する
- ドライブ交換時は型番、容量、ベイ、日時を記録する
- リビルド開始前にバックアップと残存ドライブ状態を確認する
再構築の完了後も、代表ファイル、共有権限、データベース、仮想マシンなどを検証します。
RAIDが「正常」になったことと、必要なファイルが正しいことは別なので、検証前に古いバックアップや救出データを消さないでください。
RAID再構築エラーについてよくある質問
進捗が長時間変わらないだけなら待つべきですか?
機種、容量、負荷によって進捗表示が長く変わらないことはあります。
ただし、エラー増加、異音、切断、発熱、残り時間の急増がある場合は、単に遅いと決めず、表示と症状を記録して中止基準を判断します。
新品の交換ディスクへ替え直せば再実行できますか?
交換先の初期不良や容量差が原因なら改善する可能性はありますが、残存ドライブや筐体経路が原因なら解決しません。
別の交換先を試す前に、停止ログ、残存側の状態、容量・規格、元の構成を確認してください。
電源を切ると再構築途中のデータが消えますか?
影響はRAID方式、機種、停止段階、電源の切り方で異なるため、一律には答えられません。
緊急の物理症状がなければ、進捗とログを保存し、メーカーの停止方法と現在の障害状態を確認してから判断します。
交換前の故障ディスクは捨ててもよいですか?
データ救出と検証が終わるまで保管してください。
途中まで書き込まれた交換先より、交換前ディスクに必要な情報が残っている場合があります。ベイ位置とシリアルを記録し、ほかのドライブと混ぜないようにします。
再構築が完了すればデータも必ず正常ですか?
いいえ。再構築はRAIDの冗長性を作り直す処理であり、誤削除、上書き、破損したファイル内容を過去へ戻す処理ではありません。
完了後も重要ファイルを開き、容量、更新日時、内容、関連データの整合性を確認します。
まとめ|再構築をやり直す前に停止時点の情報と原本を守る
RAID再構築がエラーで止まった時は、同じ処理をすぐ繰り返さず、通常書き込みと自動処理を止めます。
進捗率、エラー全文、ドライブ順、交換履歴、異音や発熱を記録し、読み取り元、書き込み先、接続経路、電源・制御のどこで失敗したかを整理してください。
まだ安定して読める場合は、重要データから別の正常な媒体へコピーします。
複数ドライブ障害、異音、認識変化、構成不明がある場合は再試行を増やさず、原本を保全し、複製側での解析を含むデータ救出を検討します。
RAIDを再び正常表示にすることと、必要なデータを安全に取り出すことは別です。
データが唯一の原本なら、修復より保全を先にし、救出結果を検証してから再構築や初期化へ進みましょう。
