データ救出

(Jo^▽^)ノぁぃ♪

今回は、メインPCのデータドライブとして使っていた1TB SATA SSDで発生した異常と、約350GBのデータを別PCへ救出するまでの記録です。
最初からSSDの故障を疑っていたわけではありません。
別件のバックアップ復旧作業中に、「どうも転送速度がおかしい」と気付いたことが始まりでした。
結果的には、SSDが完全に読めなくなる前にデータを退避することができました。
そして最後には、エンジニアとして非常に基本的な操作が、切り分けの決め手になりました。

1. 異常の発見

1-1. 発端はノートPCのイメージ復旧

ノートPCのシステムイメージを、メインPCのDドライブに保存していました。
ノートPCのSSDを交換し、修復ディスクからネットワーク経由で新しいSSDへ復旧しようとしましたが、うまくいきません。
そこでメインPCにSATA SSDを接続し、Dドライブに保存してあるバックアップファイルをコピーしようとしました。
ところが、妙に遅い。
ここで初めて、「Dドライブの読み出し速度がおかしいのでは？」と気付きました。
もしノートPCの復旧作業をしていなければ、この異常には気付かなかったかもしれません。

1-2. SATAケーブルとSATAポートを交換

まずは基本的な切り分けです。
　・SATAケーブルを交換
　・接続するSATAポートを変更
しかし、症状は変わりません。
タスクマネージャーでDドライブを見ると、読み取り速度が数百KB/s程度まで落ちることがあり、SSDとしては明らかに異常な挙動です。

この時点で、SSDそのものに問題がある可能性を考えました。
完全に読めなくなってからでは遅い。
そこで、原因究明より先に「データ救出」を優先することにしました。

2. 約350GBのデータを救出

2-1. 別PCへrobocopy

Dドライブは約350GB使用していました。

これを別PC（SUB）のSSDへ、ネットワーク経由で退避します。

使用したのはWindows標準のrobocopyです。
/Zで再開可能モード、/R:1でエラー発生時の再試行を1回に制限。
読めないファイルに何度もアクセスして、異常が疑われるSSDへ余計な負荷を掛けないようにしました。
故障が疑われるストレージでは、完全な診断より先に、「読めるうちに、できるだけ多く救出する」ことが重要です。

2-2. コピー速度が極端に低下

救出中、Dドライブの読み出し速度は安定しません。
数MB/s出ることもあれば、数百KB/sまで低下することもあります。
ネットワーク側の転送量も、それに合わせて大きく変動します。
この挙動から、単純にLANが遅いのではなく、コピー元であるDドライブの読み出し待ちになっていることが分かります。
さらに、Windowsのシステムイメージには100GBを超える巨大なVHDXもありました。

2-3. robocopyにもエラー発生

ログを確認すると、いくつかのファイルで、エラー19（0x00000013）が発生していました。
ただし、これは単純な読み出しエラーと断定できるコードではないため、該当ファイルや発生時のrobocopyログを確認しながら切り分けました。
特にWindowsバックアップのZIPファイルや、巨大なVHDXで発生しています。
また、System Volume Information配下では、エラー5「アクセスが拒否されました」も発生しました。
こちらは通常のユーザーデータ救出という意味では、大きな問題ではありません。
さらに巨大なVHDXのコピー中には、エラー59「予期しないネットワーク エラーが発生しました」も発生しました。
それでも、robocopyの再開機能を利用しながら救出を継続しました。

2-4. 一度終わっても、もう一度robocopy

1回目のコピーが終了しても、それで終わりにはしません。
同じrobocopyをもう一度実行します。
既に同じ内容が存在するファイルはスキップされるため、2回目は実質的に、「差分確認＋取りこぼしの再コピー」になります。

最終結果では、約16万5千ファイルの大部分がスキップされ、実際にコピーされたのはごく少数でした。
これで、1回目のコピーでほぼ救出できていたことを確認できました。

2-5. 救出するデータにも優先順位を付ける

Dドライブには、ノートPC「AH77」のWindowsシステムイメージも保存していました。
しかしAH77は既に240GB SSDへ復旧済みで、実機も正常に起動しています。
つまり、AH77のバックアップは今回の緊急救出で最優先にする必要はありません。
一方、メインPC「GALL」のWindowsシステムイメージは重要です。
DドライブのWindowsImageBackup内には、約106.5GBのVHDXがあります。
こちらは別途robocopyでSUBへ救出しました。
巨大なVHDXのため、ネットワーク転送には約12時間掛かりました。
それでも最終的には、失敗 0でコピー完了。

これで、
　・Dドライブの通常データ
　・GALLのWindowsシステムイメージ
の両方をSUBへ退避することができました。

2-6. 「GALLフォルダが見えない」

ところがSUB側を確認すると、GALLフォルダがExplorerに表示されません。
新しく「GALL」というフォルダを作ろうとすると、「既に存在する」という扱いになります。
コマンドプロンプトから確認すると、フォルダ自体は確かに存在しています。
attribで属性を確認すると、System属性とHidden属性が付いていました。
そこで属性を解除。
再確認すると、ExplorerにもGALLフォルダが正常に表示されました。
データが消えたのではありません。
「存在するが表示されていない」だけでした。

2-7. 新しい1TB SSDを手配

ここまでの症状から、DドライブのSSDは交換する方針としました。
新しい1TB SATA SSDを用意し、旧Dドライブがまだ読めるなら、ネットワークを介さずSATA間で直接コピーします。
もし旧Dが途中で完全に読めなくなっても、SUBには救出済みのデータがあります。

つまり、旧D　→　一次復旧元SUB　→　バックアップ側の保険という二段構えです。

3. SSDの故障診断

3-1. CrystalDiskInfoでSMARTを確認……できない？

ここまでデータを救出して、ようやくSSDそのものの診断に入ります。
旧Dの状態を確認するため、CrystalDiskInfoを導入しました。
ところが起動してみると、C:のNVMe SSDしか表示されません。
Windowsの「ディスクの管理」では、
　・D: 1TB SATA SSD
　・E: SATA SSD
　・F: SATA SSD
　・C: NVMe SSD
の4台すべてを正常に認識しています。
デバイスマネージャーでもSATA SSDは存在しています。
しかしCrystalDiskInfoではNVMeしか見えない。
「SATA側のSMART取得経路に問題があるのか？」「ATA_PASS_THROUGHの設定か？」などと、さらに切り分けを進めました。
設定を変更して再検出しても反応しません。

3-2. エンジニアの心得　その1

ここで一度、考えるのをやめました。
複雑なところへ入り込み始めています。
こんな時こそ、「道に迷ったら基本に帰る」です。
PCを単に再起動するのではなく、
　シャットダウン
　↓
　電源遮断
　↓
　起動
を行いました。

再起動はホットスタート。
電源を完全に遮断してからの起動はコールドスタート。
ソフトウェア的な再起動と、ハードウェアを電源状態から初期化することは同じではありません。
回路屋なら当然知っている話です。
「リセットを掛ける」のと、「電源を落として全ノードを初期状態へ戻す」のは別物です。

3-3. 道は開けた

コールドスタート後、CrystalDiskInfoを起動。
今度はSATA SSDが表示されました。
ようやく問題の1TB SSDについて、SMART情報を取得できる状態になりました。
表示された内容は、
健康状態　正常 100%
温度　　　40℃
使用時間　8897時間
総読込量　5059GB
総書込量　3363GB
さらに、代替処理済みセクタ数　0訂正不可能セクタ数　　0Ultra DMA CRCエラー数　0でした。

これは予想外です。
実際の読み出しでは数百KB/sまで速度が低下し、robocopyでは読み出しエラーまで発生しています。
SATAケーブルを交換しても変わらない。
SATAポートを変更しても変わらない。
それなのにSMART上は、「正常100%」です。
少なくとも、単純なNANDの寿命や不良セクタ、SATA伝送エラーだけでは説明しにくい結果になりました。

3-4. SMARTの「正常」を過信してはいけない

今回改めて分かったのは、SMARTが正常 ＝ 実使用上も正常とは限らないということです。
SMARTはSSD内部で管理されている各種情報を取得し、状態判断の材料にする仕組みです。

しかし実際のシステムには、
　・SSDコントローラ
　・SATA PHY
　・ホスト側SATAコントローラ
　・ドライバ
　・電源状態
　・内部状態遷移
など、SMARTの寿命表示だけでは捉えられない要素があります。

今回のように、「SMARTは100%だが、実際にはまともな速度で読めない」という場合、私は実動作を優先して判断します。
計測値だけを見るのではなく、「現物の挙動を見る」これも故障解析の基本です。

4. 今回の故障解析から得たこと

4-1. 今回の救出で重要だったこと

今回の作業を振り返ると、重要だったのは次の点です。
「何となく遅い」を見逃さなかった
最初の異常はエラー表示ではなく、転送速度の低下でした。
診断よりデータ救出を優先した
故障が疑われるストレージは、診断を続けている間にも完全に読めなくなる可能性があります。
SATAケーブルとポートを先に切り分けた
基本的な外部要因から先に除外しました。
robocopyの再開機能を利用した
巨大データの救出では、途中から再開できることが非常に重要でした。
同じrobocopyを再実行した
一度コピーして終わりではなく、差分を確認して取りこぼしを再チェックしました。
データに優先順位を付けた
AH77は既に実機復旧済み。一方、GALLのシステムイメージは未復旧だったため、こちらを優先しました。
最後は「基本に帰った」
CrystalDiskInfoがSATA SSDを認識しないため複雑な設定を追い始めましたが、解決の糸口になったのは、「一度、完全に電源を切る」という最も基本的な操作でした。

4-2. まとめ

今回のトラブルは、単純な、「SSDが壊れたので交換した」という話ではありませんでした。

ノートPCの復旧作業
↓
コピー速度の異常に気付く
↓
SATAケーブル・ポートを切り分ける
↓
SSDの異常を疑う
↓
約350GBを別PCへ救出
↓
robocopyのエラーと格闘
↓
GALLのWindowsシステムイメージも救出
↓
SMARTを確認しようとするがSATA SSDが見えない
↓
設定を追っても解決しない
↓
「基本に帰る」
↓
シャットダウン → 電源遮断 → コールドスタート
↓
SATA SSDのSMART取得成功という流れになりました。
故障解析をしていると、原因を追うほど複雑な方向へ進んでしまうことがあります。
しかし、そんな時ほど基本に戻る。

エンジニアの心得　その1
「道に迷ったら基本に帰る」
今回、一番効いたのは高度な診断ツールでも特殊なコマンドでもなく、最後にはこの基本動作でした。

4-3. このSSDは本当に故障しているのか？

SMART上は正常100%。
しかし実使用では、明らかな速度低下と読み出しエラーが発生しています。
このため現時点では、「SMARTが正常だから継続使用してよい」とは判断しません。

重要データは既に別PCへ退避済みです。
新しい1TB SSDへ交換後、旧SSDは重要データの保存用途から外し、必要なら改めて単体で速度測定や全領域読み出しなどを行い、原因を追ってみます。

データが一つしかない状態で故障診断を続けるのと、データを救出してから故障解析するのでは、意味がまったく違います。

「まず守る。その後で調べる。」
これも修理・故障解析の基本です。