もう、ひと月が経つ。
台風が2発も来るのに明日は会合をやるのか!? などと言っていた夕方。バックアップを取り始めたところでカコンカコンカコン……内蔵の東芝HDDが寿命を迎えた。あれから13年なので、まぁ及第か。
即死という風でもないので、再起動などかけつつデータのサルベージを試みるが、さすがに厳しい。重いXPMは到底無理、ちょっとしたデータも途中でフリーズしてしまう。今日の分はあきらめよう。
MMX-Pentiumで5年、Pentium4で10年、i7-2600で14年。
いきなりHDDを換装したりグラボを載せ替えたりと不具合が多かったi7機も意外と持ったものだ。処理能力は間に合うのだが、OSのサポート切れで各方面から見放されつつあるのと、コネクタ等の物理的な劣化が目立ってきたのと、そんなこんなですっぱり新機に乗り換えることにした。
値段を見ると、またh……となりそうだったが、かなり懲りたのでNECのビジネスノートにした。あとで調べたら24年夏モデルらしい。
i5-1235Uで256GB SSD、USBたくさん、有線LANあり、HDMIにVGAコネクタまでついている。液晶はFHDに届かないが、据え置きでU2711につなぐので問題はない。1万円の中古メモリ(DDR4 1R×8 16GB)を付けて24GB、8.5万ならまぁお値打ちだろう。
ちなみにOSはWin11Pro 22H2なので、動き始めるまでにだいぶ長くアップデートが要る。最終的には25H2となる。
Win7からの移行なので、作法には戸惑う。いま時なので、AI(Gemini)にあれこれ聞きながら進める。いい時代になったものだ。
何から始めようかと考えたが、とりあえずサルベージをすることにした。
旧機のHDDは約1TB。160GB(C:\)と700GB余にパーティションが切られている。700GBにデータを置いていたので、そこを浚う。大概は外付けにコピーしてあるのだが、漏れもあった。
こちらもGeminiに頼りっぱなしで進める。
かつてはKNOPPIXをDVD-ROMに焼いて、そこからアレコレ頑張ったりもしたのだが、正直なところ使いこなせず、PCが無ければ調べることもできずで、成果は乏しかったと記憶する。
今回は、SystemRescue(systemrescue-13.01-amd64.iso/1,357,627,392bytes)を使った。32GBのUSBメモリ(実際はもっと小さくてよい)にRufus(rufus-4.15.exe/1,989,992bytes)を使って書き込む。各PCの作法に則ってUSBメモリからブートする。
ごちゃごちゃ表示されたのち、コマンドプロンプトの入力待ちのような状態になる。
手順としては、
lsblkで一覧を出して容量などからサルベージ先と保存先を確認、
mkdir /mnt/backupのように保存用のディレクトリ(フォルダ)を作成し、
mount -t ntfs-3g /dev/sdg1 /mnt/backupのような形でマウントする。
この時点で???だったのだが、linuxではmkdirでメモリ上などに場所を作ったうえで、裏口にでっかいストレージなどをこっそりつなげる(マウントする)、というイメージらしい。
ここで指定した/dev/sdg1が、USB接続したHDDなど保存先になる。起動ごとに変わることがあるので、注意が必要。
Geminiの最初に示した手順では、このマウントができなかったのだが、上記のようにntfsであることを明示することで通った。
サルベージ先はマウントしない。ともかくセクタ単位でひたすら読み出し、イメージファイルに落とす。それにはddrescueというツールを使う。具体的には、
ddrescue -n /dev/sda4 /mnt/backup/rescue700gb.img /mnt/backup/rescue.mapのようなコマンドになる。
/dev/sda4がサルベージされるパーティション、rescue700gb.imgが吸い出したデータのイメージデータ、rescue.mapはセクタが読めたか読めなかったか、という情報を保管するファイルになる。
いずれも通常のファイルなので、保存先ドライブにすでにファイルなどがあっても問題はない。
これによって、1.9GBのイメージが救出できた。……ダメじゃん。
理由は、読めないセクタにぶつかった際、セクタをスキップするらしい。物理的保護のため、その幅が倍々ゲームになる(/nオプション)ため、一気に最後尾まで飛んで何も読めなかった模様。non-scraped:という項目に、その量が表示される。
その後、
ddrescue -d -r1 /dev/sda4 /mnt/backup/rescue700gb.img /mnt/backup/rescue.mapというコマンドを発したところ、non-scrapedが爆速(38MB/sぐらい)でbad-sectorに変換されていった。HDDのアクセスランプはチカリとも点かない。
どうもこれは、HDDが気絶した状態のようなので、Ctrl+Cで急ぎ止める。rescue.mapを健常なPCで開き、bad-sectorとして記録された部分をnon-scrapedに割り振り戻す。単純なテキストなので、メモ帳で編集可能。
ひと晩寝かして冷ましたのち、
ddrescue -f -E 1MiB /dev/sda4 /mnt/backup/rescue700gb.img /mnt/backup/rescue.mapを実行。これはエラーレート(bad-sectorへの変換)が1MB/sを超えたら異常とみなして終了するという意味らしい。
結局、1日と4時間余りかかって、99.94%を救出。run time 1d4h32m、bad areas 8,read errors 7、といった表記。bad-sectorは480㎆あまり。
全体から見れば埃のような量だが、それでもこれだけある。Win95なら余裕でインストールできるんじゃないか。
吸出しが終わったので、
cd /
umount /mnt/backup
poweroffとしてやると、片付け作業ののちにぷつんと電源が切れる。
できあがったimgファイルは、OFSmount(ofsmount.exe 3.1.1003.0/16,019,608bytes)を使って開く。
読み取り専用のHDDとしてマウントすれば、新たなドライブとして扱える。マウントの際、ドライブレターも選べる。
ドライブとして読めるようになったら、イメージからファイルを救出するわけだが、ふつうにコピペよりはツールを使った方がよい。
fastcopy(fastcopy.exe 5.11.3/5,179,776bytes)は、高速コピーがウリだが、エラーログが残せるのがうれしい。今回のように、生きてるか死んでるか、読めるか読めないかのイメージから引っ張り出すには最適。ただし、フォルダの指定方法に癖がある。
そのほかの主なツールとしては、メーラにSylpheed(Sylpheed-3.7_setup.exe 3.7/8,233,467bytes)を採用した。
たいていはthunderbirdが勧められるが、古典的3ペインで、メール単位で*.emlで保存され、振り分けルール(メッセージルール)も判りやすい。
*.dbxをまとめて読み込んで構造も再現……まではできないが、単体で読み込めるので必要に応じてインポートしていけばいいかな、とお気楽に運用することにした。
ショートカットキーがいくつか設定できるが、完ぺきにOE(OutlookExpress)を再現することはできない。が、このへんも徐々に覚えていけばいいか、とお気楽運用を決めた。
もう少しサルベージを進めた後には、USBメモリは「回復ドライブ」作成に供する予定。
25H2にするのにドエライ時間がかかるし。

0 件のコメント:
コメントを投稿
.