２週間前に発生した、Windows Server の「記憶域」障害は、
２週間経って、ようやく 復旧させることができた。
今回、障害にみまわれた仮想ディスクは、次の２つである。
１．14TBのミラーボリューム（8TB×2台 ＋ 6TB×2台 = 4台構成）
２．6TBのシンプルボリューム（3TB×2台 = 2台構成）
結果は、
１のミラーボリュームの方は、データを完全復旧できたが、
２のシンプルボリュームの方は、全滅だった。
なぜ２週間も経ったかというと、
特殊なソフトを使って無理やり復旧させる過程で、
何度か失敗し、試行錯誤があったからである。
でも次に同じ障害にみまわれた場合に、
今回の経験は活かすことができる。
将来の自分が、今回の経験を活用することができるように、
このブログに、備忘録を残しておきたいと思う。
＜障害の原因について＞
起動ドライブのＳＳＤのブート部分が損傷したことで
ＯＳを再インストールしたが、バージョンの差異により、
（おそらく新しいバージョンのＯＳを上書きした）
「記憶域」の仮想ディスクの構成部分が上書更新され、
アクセス不能に陥った、という事象である。
「記憶域」を構成するシステム情報は、Windows OS ではなく、
対象のハードディスク内に記録されているはずなので、
OSを上書きインストールしても ディスク構成が変わらなければ
影響は受けないはずだ、というのが事前の知識だった。
事実、OSの再インストールの途中では、
「記憶域」の仮想ドライブは正しく認識されていた。
起動後、「Server Core（GUI無し）」を誤って選択していたことに気づき、
別のインストールDVDから、インストールをやり直した後、
Windowsの「記憶域」のディスクにエラー表示がされており、
再起動して Windows Update が適用されたら、
もうディスクがどこにも表示されなくなってしまった。
Microsoft社のドキュメントを見ると、
エラー内容は、次のものに該当するようだった。
———————————————————————————————————
ドライブの正常性状態:異常
認識されないメタデータ
記憶域スペースで認識されないメタデータがドライブで検出されました。
これは通常、ドライブに別のプールからのメタデータが含まれていることを意味します。
アクション: ドライブをワイプして現在のプールに追加するために、ドライブをリセットします。
———————————————————————————————————
ドライブをリセットするということは、データがすべて消失することを意味する。
つまり、正攻法では、解決手段がない、ということだった。
障害の原因については、このように分析しているが、
真の原因は、
「バックアップを完全にとっていなかったこと」である。
バックアップはとっていたが、バックアップ先も「記憶域」だったので、共倒れしてしまったことになり、意味をなしていない。
今回、復旧できなかった 6TBのシンプルボリューム の仮想ディスクがバックアップ先である。
＜購入したもの＞
・ソフト「ReclaiMe Storage Spaces Recovery」 40,060円
・ソフト「ReclaiMe File Recovery Standard」 10,709円
・内蔵ハードディスク 8TB 15,320円（税込）
・内蔵ハードディスク 10TB 20,400円（税込）
・内蔵ハードディスク 10TB 20,400円（税込）
・その他、変換ケーブル等
全部で約１０万円以上の出費があったが、
他人に支払っただけで終わりの「費用」ではなく、
購入したモノが手元に残り、別用途にも活用できる資産である。
＜データ復旧の経過＞
いろいろと失敗＆試行錯誤はあったが、
最終的に成功した手順は、次のとおりである。
このとおりにやれば、次回も復旧できるはずであるが、
「ミラーボリューム」になっていることが条件になる。
「ReclaiMe Storage Spaces Recovery」を起動し、
仮想ドライブを構成しているディスクを選択して「Start」ボタンを押す。
（対象とする仮想ドライブは１つだけにする）
解析結果が表示されるので、その結果が「Good」であることを確認する。
ここまでは、ソフトを購入しなくても、実行可能であり、
結果が「Good」ならば復旧できるのだから、40,060円で購入して先に進めばよい。
あるいは、もう一つのソフト「ReclaiMe File Recovery Standard」だけを 10,709円で購入して、部分的なリカバリ（ファイル救出）を試みるという選択肢もある。
先に進む場合は、「Save config」ボタン右の ▼印を押して、
「Save raw sectore-by-sector image file」をクリックすると、
ソフト購入後に画面表示される シリアル番号 の入力が済むと、
ディスクイメージファイル（拡張子 .img）の出力先を指定できる。
今回の場合、ディスクは 14TBのミラーボリュームで、実質 7.390 TBだったので、
１回目は、8TBのディスクを出力先に指定したけれども容量不足エラー
２回目は、10TBのディスクを出力先に指定したけれども容量不足エラー
３回目は、8TBと10TBをつなげた18TBのスパニングボリュームを指定してエラー解消
という経過をとったが、１回目と２回目は、まる１日かかり、３回目は２日くらいの時間を要した。
３回目で、約14TBのディスクイメージファイルが出力できたので、
それをマウントすれば復旧完了のはずだったが、
「ディスクイメージファイルが壊れています」のエラーが出て、マウントできなかった。
仕方なく急遽、「ReclaiMe File Recovery Standard」のソフトを 10,709円で追加購入し、さらにその出力用として、10TBのハードディスクを追加購入した。
「ReclaiMe Storage Spaces Recovery」ソフトから「Recover files」ボタンを押すと、
最初に選択した、「記憶域」対象ディスクからのファイル復旧を試みる。
最初はこの方法でやってみたが、復元対象ファイルとして、
見知らぬファイルやフォルダがどんどん表示されていく。
どうやら、過去に削除したフォルダまでもが対象になるらしい。
対象となるフォルダだけを選んで復元してみると、ファイル内容が壊れているものが多すぎたので、途中で処理を中断した。
時間ばかりかかるけれども、これでは役に立たない！
次に、マウントできなかった 約14TBのディスクイメージファイル（.img）ファイルを指定して、復元をしてみると、余計なファイルやフォルダは表示されなくなった。
そして、フォルダ単位で復元を試みると、壊れているファイルは皆無だった。
半日以上の時間を要したけど、ようやくすべてのファイルを 10TBハードディスクに復元することに成功した。
復元できた後は、
「記憶域」の仮想ディスクを再作成して、ROBOCOPYコマンドを使ってファイルをコピーした。
今度は、14TBのような大きなボリュームは作らずに、8TB と 6TB の２つのボリュームに分割した。
万が一、次回、今回の方法で復元することになった場合は、10TBのハードディスクが使えるからである。
今回の 10TBハードディスクは、現時点のバックアップとして、しばらくオフラインにして、保存しておこうと思う。