PC HDD から SSD へ換装 ddrescue

SSD に換装しよう ... 。
と思ったのが、地獄の始まり。
まぁ、何とか凌げたから良いものの、
一時はどうなるか！　でした ... 。


少し前と異なり、2.5 インチ SSD (SATA) も随分とお安くなりました。

流石に、草臥れて来た 古～い ノート PC なのですが、
見た目は 極普通に 稼働している様に見えます。
しかし、
内部で不整合がある様で、
改善や修復を行っても、元の様に 不安定 になります。
不安定 と書きましたが、　使え無いレベル では 無い のです。
まぁ、我慢出来る範囲 ... 。
そうです。　変な挙動を見せる事があるのが、
痛い処。
将来に向けての 一抹の不安材料。


いざ、2.5 インチ SSD に お引越し となると、
隠れていた 不整合 が顔を覗かせて、
作業を遮る状態です。

さて、
HDD は 500GB で、用意した SSD は 512GB と、容量違い。
出来れば、同一容量にして置けば、不安要素も減った筈ですが ... 。

フリーの お引越し ツール を 幾つか試しましたが、
悉く 壊滅！ なのです。
そう、最後迄、完走する事無く、
途中で 座礁 して、失敗！ に終わるのです。

恐らく、理由は、
元の HDD が 不良セクタ を抱えている事。
オマケに、
OS Windows の内部でも不整合を抱えていて、
帳尻が合わない状況なのでしょう。
表面的に、整合が取れていると報告されても、
其の実、完璧な状態では無く 動いている 、　と。
MFT が（部分的に）壊れていると 報告 する ツールもありましたし、
CRC が不一致で読み出しに失敗するツールもありました。

不良セクタ部分は 使用禁止 のフラグが立ち、
データは無いと思うのですが、
或いは、シャットダウンの終了処理の最中、
其処にアクセスして仕舞ったのかも知れません。
故に、
前に書いた様に、週末に落として週明けに立ち上げた瞬間に、
地獄の蓋が開いた ... と。
そう、　スリープで逃げている平日には事は起こりませんでしたから。
起こるべくして、事は起こった　のだと思います。

そして、　修復を経た後も、完璧な状態とは程遠い なのでしょうね。

此の手の状況を打破するには、新しい記憶装置でクリーンインストールが王道ですが、
何分にも、古～い PC 。
オマケに、
此の PC のみの 従前の古い 環境 もあって、捨て難い状況なのですね。
温存して置きたい処。

かと言え、　最初から、環境を再現する作業を熟すのは、
避けて置きたい処 なのです。


其処で、辿り着いたのが、
前回お世話になった Ubuntu にある ディスクコピーツール ddrescue 。

不良セクタ がある前提で、コピー作業を熟します。
なので、今回の対応には　ピッタリ　でしょう。

因みに、
Ubuntu LiveUSB に ddrescue は入っていませんし、
入れたとしても、次回には消されているので、
毎回、Install が必要となります。

そう、Internet 接続は 必須！ と言う事になりますね。

　　USB 接続の Wifi Rooter なら 疑似 Ethernet を Ubuntu が確立しますが、
　　Wifi 接続の場合は SSID や キー の入力 が必要でしょう。

ddrescue の Install は こう です。

1. Terminal（端末）立ち上げ
2. sudo apt update
3. sudo apt-get install gddrescue

実際に動かす前に、ドライブを確認します。　　重要！。
今回は　dev/sda (HDD) と dev/sdc (SSD) と、でした。

　　Terminal から Command で行う方法もありますが、
　　今回は GUI からで 済ませました。

そして、肝心な ddrescue の実行です。

4. Terminal から
5, sudo ddrescue -f -v -n /dev/sda /dev/sdc

　　尚、重症なケースでは、
　　sudo ddrescue -f -n -v /dev/sda /dev/sdb logfile.log
　　# next
　　sudo ddrescue -f -d -r1 -v /dev/sda /dev/sdb logfile.log
　　とステップを分ける事もある様です。
　　今回、OS 絡みの 救え無い ファイル があっても、
　　最悪、OS Image から dism させる心算ですので、
　　.log による 複数回の吸い上げ は しません でした。

但し、 HDD > SSD （容量違い 500 > 512、共に MBR、USB 接続は 2.0） でもあり、
６時間を費やしています。
流石に、長～い ですね。

Terminal の std-out（出力）を掲載して置きましょう。

ubuntu@ubuntu:~$ sudo ddrescue -f -v -n /dev/sda /dev/sdc
GNU ddrescue 1.23
About to copy 500107 MBytes from '/dev/sda' to '/dev/sdc'
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors       Initial skip size: 9856 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
     ipos:  161676 MB, non-trimmed:        0 B,  current rate:    9984 B/s
     opos:  161676 MB, non-scraped:    73728 B,  average rate:  23621 kB/s
non-tried:        0 B,  bad-sector:     4096 B,    error rate:     256 B/s
  rescued:  500107 MB,   bad areas:        8,        run time:  5h 52m 52s
pct rescued:   99.99%, read errors:       12,  remaining time:          1s
                              time since last successful read:          0s
Finished                                      
ubuntu@ubuntu:~$

当初、
容量の増分は各パーティションに振り分けられ、
未使用領域（未割当）無し で 構成 されています。

OS の入ったドライブ（パーティション）の容量が増えているのが、不安です。
理由は　C:¥Windows¥bootstat.dat は ドライブ情報をも保持　だから (?)。

しかし、電源断と再投入を経て、似た構成に変わっていました。
（詳細は不明　勘違いだったのか？　画面コピーのタイミングを間違えたのか？）
（ファイル名の時刻は UTC　JST なら UTC+9:00）

恐る恐る PC 本体 の HDD を SSD に換装し（此れが結構なハードルかも？）、
OS Windows で立ち上げて見ます。


換装して、最初の起動時に、自動修復 が走ります。
一回目は 失敗 の様ですが、
再度、メニューから試すと、
暫く、アクセスランプが着き捲った挙句に、
修復完了となり、
目出度く、起動になりました。

自動修復が失敗したら どうしようか？ と不安でしたが、
安堵 安堵 です。


通電前に、容量が増やされていた各パーティションは、
従前の容量に戻され、
増加部分は 未割当 として最後尾に残されていました。

其の後、sfc /scannow や dism /Online /Cleanup-Image /ScanHealth を経て、
正常化！。
sfc では、回復プロセスも伴った様子でした。
dism の方は 問題無し です。
認証も問題は無さそうです。


此れで、暫くは、安泰！ だと思いたいです。

古～い PC ですから、CPU も おっとり の動きですが、
IO 絡みが HDD から SSD によって 高速化 された 恩恵 で、
全体的なスピードアップに繋がっています。

何よりも 嬉しい のは、
不安定な要素 を 解消 出来たであろう事。
安心して、処理が任せられる状態に復帰した事が、一番！。　　;)

何時、地雷を踏むかと恐れ乍ら の 状況 を 打破 出来た事が大きいです。