まずは情報収集

エラーメッセージでググってみたが、日本語では1件しかまともな情報は見つからなかった。

• Windows10Pro (1709)での記憶域パリティReFSボリュームがアクセスできなくなった

refsutil salvage -FAというコマンドで復旧できることは分かった。

英語でもちらほら情報はあるものの、これいといって参考になりそうなものはなかった。

ちなみに頼みの綱TechNet ForumではMicrosoftモデレーターが「バックアップから戻せ」みたいな的外れな回答を寄こしており、不安が募るばかり。

他にも情報がないか探してみると、Twitter上で同様のエラーを報告している人がいた。

いつの間にかReFSのパリティドライブが見えなくなっていた
イベントログには「ボリューム F: ReFS でフォーマットされていますが、ReFS はこのボリュームをマウントできません。ReFS は状態 ボリュームの修復に失敗しました。 に遭遇しました。」
再起動しても直らず
結構致命的かもしれん・・・

-- 不可思議絵の具 (@YgkbJp) February 9, 2020

壊れた記憶域ボリューム、色々やったが復活しないので「refsutil salvage -FA」コマンドで救出開始
寝る前に流し、今見たら救出を始めた所だったので、洗い出しだけで12時間は掛かったということか(容量9TB)
先は長いw

-- 不可思議絵の具 (@YgkbJp) February 11, 2020

この方もrefsutil salvage -FAコマンドで復旧したようだ。どうやらこの方法が良さそうだ。

　

refsutilについて調べてみる

refsutilコマンドは名前のとおりReFSUtilというユーティリティのことを指すようだ。

コマンドを実行するにはソース ボリューム、作業ディレクトリ、ターゲット ディレクトリ（とオプション）を指定する必要がある。

refsutil salvage -FA <ソース ボリューム> <作業ディレクトリ> <ターゲット ディレクトリ> <オプション>

上記ドキュメントにはそれぞれどのように指定するか説明がある。

• ソース ボリューム
  • 回復させたいReFSボリュームを「L:」のように指定するか、ボリュームマウントポイントを指定する。
• 作業ディレクトリ
  • 一時ファイルとログを保持する場所を指定する。ソースボリューム上を指定してはいけない。
• ターゲット ディレクトリ
  • 回復したファイルをコピーする先を指定する。ソースボリューム上を指定してはいけない。

また、オプションについては以下の説明がある。

• -m
  • 削除されたファイルも含めて、可能なすべてのファイルを回復します。
    警告: このパラメーターによってプロセスの実行時間が長くなるだけでなく、予期しない結果が生じる可能性もあります。
• -v
  • 詳細モードを使用するように指定します。
• -x
  • 必要に応じて、最初にボリュームを強制的にマウント解除します。 その後、ボリュームに対して開いているすべてのハンドルは無効になります。 たとえば、「 refsutil salvage -QA R: N:\WORKING N:\DATA -x 」のように入力します。

つまり、今回壊れたドライブを「W:」、復旧したデータを退避させるドライブを「F:」とすると、

refsutil salvage -FA W: F:\temp_recv F:\rescued_data -x -v

のように指定すればいいということになる。-x -vオプションは念のため指定した。

　

退避先ディスクの用意

今回ぶっ壊れたドライブ「W:」は8TBほぼ満載状態だったので、退避先のHDDを用意するのに苦労した。

別で使用中の8TBがもう一台あったため、そこのデータを全て他のドライブに退避して「F:」とすることにした。

とはいえもう一台のHDDもそれなりにデータ量があったので、それを全て退避するのにかなり時間がかかってしまった。

壊れた記憶域ボリュームの救出処理が終わった
容量9TBで63時間（2.6日）掛かった
昔消したファイルも修復しているようで、ファイルの出入りが激しいフォルダは正常ファイル・異常ファイルが混じってグチャグチャだ(汗
ただ、ぱっと見、ほぼ復活しているように見える

-- 不可思議絵の具 (@YgkbJp) February 13, 2020

その後に待っている復旧にもかなり時間がかかりそうなので気が重い...9TBで63時間って...。

　

コマンドを精査する

コピー先HDDのデータ退避中に暇だったのでもう少し効率のいい方法がないか調べてみた。

refsutilの-FAオプションはフルスキャン後に復旧データのコピーが入るようだが、これは結局フルスキャン(-FS)後にコピー(-C)を連続で行ってくれるだけのようだ。

ReFS Salvage にはスキャン フェーズとコピー フェーズがあります。自動モードでは、スキャン フェーズとコピー フェーズが連続して実行されます。
手動モードでは、各フェーズを別々に実行できます。進行状況とログが作業ディレクトリに保存され、フェーズを個別に実行するだけでなく、スキャン フェーズを中断/再開することができます。

となると、まずクイックスキャン(-QS)を単体で実行して素早く復旧できるかどうかを確認し、復旧できそうならそのままコピー(-C)。ダメそうなら諦めて(-FA)でフル復旧を実行するのがよさそうだ。

どのみち壊れたドライブはマウント不可でこれ以上データが壊れることはないため(これがReFSの仕様？狙い？)、最悪時間はかかるけど何度でも繰り返すことはできるだろう。

　

クイックスキャンの結果

C:\WINDOWS\system32>refsutil salvage -QS W: F:\temp_recv -x -v
Microsoft ReFS Salvage [Version 10.0.11070]
Copyright (c) 2015 Microsoft Corp.

ローカル時刻: 12/19/2022 0: 48: 45

指定されたオプション: -v -x

ReFS バージョン: 3.4
ブート セクターは確認済みです。
クラスター サイズ:  4096 (0x1000)。
クラスター カウント : 1953497088 (0x74700000)。
スーパーブロックは確認済みです。
チェックポイントは確認済みです。

スキャン自体は正常に終了したが、F:\temp_recvに出力されるはずのfoundfiles.<volume signature>.txtが作成されなかった。

念のため-QAオプションも実行してみたが結果は同じ。クイックではダメのようだ。

諦めて-FAオプションで実行したところ、foundfiles.txtとスキャンログ？と思われるテキストファイルが出力され始めた。

コマンドプロンプトには見つかったファイル情報と思われる内容がどんどん出力されていく。

Identified File: Table[0x3a1d'0]\ファイル名
Size (0x0 Bytes) Volume Signature: 0x60d8d1fe Physical LCN: 0x3423ea0 = <0x6863ea0, 0x6863ea1, 0x6863ea2, 0x6863ea3> Index = 0x6
Last-Modified: 12/17/2022 12:37:58 PM TableId: 0x3a1d'0 VirtualClock: 0x116fb TreeUpdateClock: 0x170

半日ほどでスキャンが完了したようで、最終的にはこのようなファイルが出力された。ここまでで約14時間。

スキャンが完了すると引き続きコピーが実行され、コマンドプロンプトには復旧されたファイルがずらっと出力されていく。

コピー中: \\?\F:\rescued_data\volume_60d8d1fe\ファイル名...完了
コピー中: \\?\F:\rescued_data\volume_60d8d1fe\ファイル名...完了
コピー中: \\?\F:\rescued_data\volume_60d8d1fe\ファイル名...

パスを見たところフォルダ構造も保ったまま復旧されているようで、丸々元の状態に戻すことができそうだ。

ただし24時間近くたった時点で1TBしか復元されておらず、とにかく時間がかかるのは覚悟しておいた方がよさそう。

　

復元完了...じゃない

2日ほど放置していたら復元（コピー）が完了していた。総経過時間は49時間。

想定よりずいぶん早いなぁ、と思ってコマンドプロンプトを見ると、

コピー中: \\?\F:\rescued_data\volume_60d8d1fe\ファイル名...警告: 出力ファイルを開けません!
警告: ディスクがいっぱいであるため、操作が失敗しました
これが仮想プロビジョニング対応ボリュームである場合は、このボリュームをバッキングする物理記憶域がすべて使用されています。

コピー中: \\?\F:\rescued_data\volume_60d8d1fe\ファイル名...警告: 出力ファイルを開けません!
警告: オブジェクト パス コンポーネントがディレクトリ オブジェクトではありません。
コマンドが完了しました。

こんなエラーが。ああ、ディスク容量が足りなくて途中から失敗してたんだ...。

しかし同じサイズのHDDを用意したのになぜ容量が足りなくなるんだ？

と思いF:\rescued_data\を見てみると、$RECYCLE.BINというフォルダが結構な容量を取っていた。ゴミ箱のファイルまで復元してくれていたのね...。

　

やり直しできるのか

復元された$RECYCLE.BINは要らないので削除。

容量不足でコピーされなかったファイル達は、偶然にもすべて1フォルダ内だけだったので簡単に特定できた。

あとはこれらのファイルをコピーし直したいんだが、このまま同じコマンドを叩くとまた49時間も待つことになる。それは勘弁したい。

上で書いたように-FAオプションはフルスキャン(-FS)後にコピー(-C)が行われる仕様で、フルスキャンの結果は作業ディレクトリに出力済みだ。

このfoundfiles.60D8D1FE.txtに復元対象のファイルがリストアップされている。

Volume Signature: 0x60d8d1fe

Identified File: \$RECYCLE.BIN\S-1-5-21-1159125001-2913831128-2118923469-1001\$I06MVUTファイル名
Size (0x96 Bytes) Volume Signature: 0x60d8d1fe Physical LCN: 0xa04704 = <0x1430704, 0x1430705, 0x1430706, 0x1430707> Index = 0x58
Last-Modified: 11/13/2022 09:14:36 PM TableId: 0x79b'0 VirtualClock: 0x1ad99 TreeUpdateClock: 0x110

Identified File: \$RECYCLE.BIN\S-1-5-21-1159125001-2913831128-2118923469-1001\$I0GSIY6ファイル名
Size (0x7c Bytes) Volume Signature: 0x60d8d1fe Physical LCN: 0xa04704 = <0x1430704, 0x1430705, 0x1430706, 0x1430707> Index = 0x59
Last-Modified: 12/18/2022 10:06:23 AM TableId: 0x79b'0 VirtualClock: 0x1ad99 TreeUpdateClock: 0x110

こんな感じでエグい行数のデータが出力されている。テキストファイルなのに76MBもある。

ここから不要ファイル行を抹消し、復元したいファイルだけを残してみた。

そして下記コマンドでコピーのみ実行してみたところ、

refsutil salvage -C W: F:\temp_recv F:\rescued_data2 -x -v

F:\temp_recv\foundfiles.60D8D1FE.txt を処理しています
コンテナー テーブルのエントリ ページを 4068 ページ処理しました (無効なページ数 0)。
コンテナー インデックス テーブルのエントリ ページを 1 ページ処理しました (無効なページ数 0)。
コピー中: \\?\F:\rescued_data2\volume_60d8d1fe\ファイル名...警告: ソ ース ファイルのファイルのエクステントを列挙できません!
警告: データ整合性のチェックサム エラーが発生しました。ファイル ストリーム内のデータは破損しています。
警告: データ ストリームをコピーできません!
警告: データ整合性のチェックサム エラーが発生しました。ファイル ストリーム内のデータは破損しています。
コピー中: \\?\F:\rescued_data2\volume_60d8d1fe\ファイル名...警告: ソース ファイルのファイルのエクステントを列挙できません!
警告: データ整合性のチェックサム エラーが発生しました。ファイル ストリーム内のデータは破損しています。
警告: データ ストリームをコピーできません!
警告: データ整合性のチェックサム エラーが発生しました。ファイル ストリーム内のデータは破損しています。
コピー中: \\?\F:\rescued_data2\volume_60d8d1fe\ファイル名...完了
コピー中: \\?\F:\rescued_data2\volume_60d8d1fe\ファイル名...完了
コピー中: \\?\F:\rescued_data2\volume_60d8d1fe\ファイル名...

目的のファイルだけコピーされ始めた。

いくつか壊れちゃってるみたいでチェックサムエラーが出ているが、残りは順調に復元されているようだ。

　

無事完了

結局、この方法でほとんどのデータを無事救出することができた。

元ReFS、今はRAWになってしまったWドライブはサクっとNTFSにフォーマットし直し、Fドライブに復旧したファイル達を戻してやることで復旧が完了した。さらばReFS。

　

ちなみに、

復旧できなかったファイルは0バイトで保存される様子。

「チェックサムエラーで復元できなかったので0バイトのファイル置いときますね」をやられるとなかなか辛い。

復元したすべてのファイルを確認できているわけではないので、気づいていないだけで他のファイルもボロボロ壊れてるんだろうか...怖いな。

すべての復元が終わった後、0バイトのファイルがないかドライブ全体をファイル検索してみた方がいいだろう（実際に検索してみたが、無くなっても支障のないファイルだけだったので助かった）。

というかコピー(-C)時のエラーログは別途ファイル出力するようにしてほしいなぁ...。

　

感想と補足

ReFSはトラブル時の情報が皆無なのが不安な上、何かあった時にドライブ丸ごとアクセス不可になり、復旧もドライブ丸ごとしかできないというのは非常に使い勝手が悪い。

その反面、異常があればすぐアクセスを止めて被害拡大を阻止してくれるので、FAT32の頃によくあった「いつの間にかファイルが壊れている」ということが起きづらい点は長所だろう。

元々サーバー等のエンタープライズ向けに作られていて、データ破損の防止や障害からの復旧など、信頼性を重視した設計であることを考えればこれらの短所、長所は十分に納得できる。

つまるところ「ReFSを選択することが本当にふさわしいか」を考慮して適切なファイルシステムを選択しなければならないというわけだ。

正直ここまで復旧が面倒くさいとは思わなかったので、信頼性と利便性を天秤にかけて自分の使い方にあった方を選んだ方がいい。

　

リムーバブルメディアはサポート外

ちなみにReFSがいきなりRAWになる事例は過去にも起きていたらしい。

これは「ReFS でフォーマットされたリムーバブル ボリュームが RAW としてマウントされる、または、マウントできない」という事象で、今回とよく似ている。

原因ははっきりしていて「ReFSに対応していないリムーバブルメディアをReFSでフォーマットした」と書かれている。

考えたことなかったけどリムーバブルメディアはそもそも非対応なんだ...。

こちらの記事では、この制約は「ReFSのもともとの制限」で「2016年1月3日の時点からこの記載は存在していた」とのことで、意外と知られていないのだろう。

もし外付けHDDなどのリムーバブルメディアをReFSで運用していたら、面倒なことになる前にNTFSなど正式サポートされているフォーマットに変更した方がいいだろう。