passer-byの日記： NTFS disk サルベージ（続） 4
日記 by
passer-by
前回の続き。といっても少し。
HDD のクラッシュの方は機械的トラブルを想定してディスクイメージを ddrescue で吸い出してから TestDisk で救出する戦略を考えた。が、考えてみると ddrescue が走るのは Linux だが十分な大きさを持つドライブは NTFS だけだったので、急遽 Windows ホストの VMware で Linux を走らせそこから共有フォルダ機能で書き出すことに。
で、やってみると VMware からの USB 経由アクセスが死にそうなほど遅い事が判明。なのでおとなしく諦め、SSD の場合と同じく Windows から TestDisk で NTFS イメージを読んで必要なディレクトリ以下をコピーすることにした。
TestDisk の挙動を見ていると、問題のディスクは（1）最初読むのに時間がかかる（2）ある瞬間以降に全領域が等しく読めなくなる、という症状なことがわかった。ので、コピー途中で読めなくなる→ディスクの USB を抜き差しして TestDisk 再起動して失敗したサブディレクトリから再開、の繰り返しでサルベージを完了する。なんか途中から失敗しなくなってその後数日は安定して読めていたのは色々と謎。読めなくなる時はまるごとダメなので、多分電気的なトラブルなのだと思うのだけど、どーしてある時から安定したのやら。再利用は怖いので考えてないが。
ddrescue は cygwin にも入ってますよ (スコア:2)
admin 権限で cygwin 起こせば /dev/sd* 抜けるし保存先も NTFS で問題ないです。
Cygwin 忌諱している人多いですし WSL 出て iyh してる人も多いですけど、年季が違うので WSL に出来ないことしれっとやってのけちゃう場合もあるんですよね。
uxi
Re:ddrescue は cygwin にも入ってますよ (スコア:1)
あー、cygwin...。すっかり頭から抜け落ちておりました。
次は試してみます。ありがとうございました。
前回の日記で (スコア:0)
復活させたパーティションの block size が 4096 bytes と、NTFS の標準値 512 bytes と異なっていた
これってディスクの仕様が由来で、今のディスクはHDDもSSDもセクタサイズが4KBだったりするけど、そのせいじゃないの?
Re:前回の日記で (スコア:1)
はい、おそらくディスク仕様由来です。
不思議なのは何年か前にこの SSD を最初に（dd で HDD を吸い出して）設定した時には特に異常なく Windows で使えていたことですが（今回は USB 経由で繋いでみたところマウントしてくれませんでした）、起動ボリュームのときは問題にしないとかだったのかもしれません。
面倒なのでこれ以上は追求してません（が将来どこかで同じ問題にハマるんだろうな……）。