写真：PC Watch

　ある日筆者は、Windows 11で使用しているSSDでエラーが発生した。そこでライブイメージのUbuntuにgddrescueをインストールして、データを救出する形で急遽購入したSSDにコピーをした。以降、何事もなかったかのように使えるようになった。 【画像】エラーで止まったところ 　今回の内容を要約すると、この1行になるが、大変珍しいことに再現可能な状態で復旧できたため、時系列で見ていきたい。 ■ きっかけ 　そもそものきっかけはソースネクストがNovaBACKUPのアップデートを知らせてきたことにある。 　ソースネクストは、「NovaBACKUP 18.7」をWindows 11でも使えるとして販売しているが、NovaBACKUPの開発元はWindows 11対応を19.7以降としている。 　このギャップが気になって、安価で販売されていた時に購入したものと思われるが、その後インストールした記憶がないので、興味を失ったのだろう。 　しかしアップデートして19.8になるというのであれば俄然気になる。早速インストールしてバックアップを実行してみたところエラーで止まってしまったので、まあそんなものかと思ってしまった。もちろんこれは濡れ衣であるが。 　そういえばうちにはもう1本バックアップソフトがあったなということを思い出し、HD革命/Backup Next Ver.5を(文字どおり)箱から取り出し、インストールしてバックアップを実行してみると、やはりエラーで止まってしまった。 　エラーメッセージを読むと、(ハードディスクとなっているが)ソフトウェアではなくSSD側の問題であることが分かった。CrystalDiskinfoをインストールして確認してみたところ、バッドセクターがあるということで間違いなさそうだ。 ■ 代替SSDの確保とハードウェアによるクローン 　正直なところこのWindows 11は検証用で、仮にSSDが使えなくなってもあまり問題はない。しかしWindowsはセットアップに時間がかかるし、データをそっくり移して手間が省けるのであればそれに越したことはない。早速CT500MX500SSD1を注文し、SSDを移行することにした。 　ストレージにエラーを認めた場合に真っ先にすることは、PCの電源をオフにしてそれ以上のエラー増加を避けることと、代替のストレージを確保することだ。手元に在庫があるなら心強いが、通常はないだろう。筆者はなかった。厳密には同じSSDを在庫していたが、もう使わないだろうと手放してしまっていたのだ。惜しいことをした。 　新しいSSDが到着してまず最初にやったのは、うちにはHDD/SSDをクローンできるハードウェアがあるので、これを使用することだった。エラースキップ機能があるので、ひとまず完了はするだろうと考えていたのだ。 　しかし待てど暮せど完了しなかった。中断し、次の手を考えることになった。 ■ Ubuntuのブートとgddrescue 　次に考えられる手段としては、dd系の何かだ。ddはディスクのクローンに使われるが、今回のようにバッドセクターが含まれる用途には向かない。今回の用途にふさわしいのはgddrescueだ。もうこれでダメならどうしようもないという最終兵器くらいに思っておくといい。前段階としてもう1つくらい何かないかと考えてみたものの、全く思い浮かばなかった。のっけから最終兵器のお出ましだ。 　UbuntuのインストールイメージをコピーしたUSBメモリから起動し、まずは「ディスク」でどのくらいバッドセクターがあるかを見てみる。S.M.A.R.T.に対応していれば表示されるはずだ。 　ただし、当時同じ画面を確認してみると、バッドセクターが15個だった。 　急激に増えたのかと考えてしまったのだが、そういうわけでもなさそうなのは後々分かった。 　Ubuntuのライブイメージにはgddrescueパッケージはインストールされていないため、インストールする必要がある。 　gddrescueパッケージに含まれるddrescueコマンドを実行した。 　今回は例として「-r 10」オプションをつけている。エラーがあっても10回までは繰り返すという意味だが、過剰だったので2か3くらいでいいだろう。元のSSDが/dev/sdaで、新規に購入したSSDが/dev/sdbだ。ここを間違えたら全てが終了するので、3回くらい指差し確認をしてからコマンドを実行しよう。 　そのまましばらく待つと作業完了する。今回は2時間13分かかった。完全にストレージの容量と速度に依存するので、500GBくらいのSATA接続SSDだと2時間ちょっとだと考えておけばいいだろう。 　こちらも作業当時のスクリーンショットがあったので、比較してみよう。 　作業時間が4分長いのは謎だが、「bad-sector」は「98304B」で同じだ。S.M.A.R.T.によるバッドセクターの数にはかなりの開きがあるが、ddrescueコマンドでは変化がない。このあたりがS.M.A.R.T.から正確な状態を読み取る難しさだ。 ■ Windowsでの操作 　ここまで来たらUbuntuをシャットダウンし、Windowsを起動する。まずはCrystalDiskinfoを見てみよう。 　問題ない状態になった。 　とはいえファイルシステム的には不整合な状態になっているので、これを修正する。「ディスクの管理」から該当ストレージのプロパティを表示し、「ツール」タブの「チェック」をクリックする。 　「このドライブでエラーが検出されました」になるので、「ドライブのスキャン」をクリックする。続けて修復する。 　これで修復は完了するので、先程中断したバックアップを再び実行してみる。今度は完走した。 ■ いかに早く気づくか 　今回はOSのブートが可能な状態でSSDのエラーに偶然気がついた。だからデータのロスなくストレージの交換ができた。これが全てだ。もしブートしなくなってから気がついたら、復旧不可能だったことだろう。 　皆が皆定期的にセクター単位のバックアップを取っていたらいいのだろうが、あまりに非現実的すぎる。CrystalDiskinfoや「ディスク」のようなツールで、S.M.A.R.T.の値を確認するほうがまだ現実的だ。 　ただし現在のUbuntuの「ディスク」では、NVMe SSDのS.M.A.R.T.の値は取得できない。よってsmartmontoolsパッケージに含まれるsmartctlコマンドなどで確認する必要がある。このあたりは率直にUbuntuに足りないところだといえる。