2018年09月15日(土) - 23:02 | カテゴリ:
Linux
前回軽く書いていたHDDのクラッシュ修復。
色々と頑張ったが、待避させた時には手遅れだったのか救出不可能だった。
という事で、何をやったがダメだったのか備忘録。
ちなみに、今回お亡くなりになったのはコチラのHDD。
本来はデスクトップ用な物を自鯖で24h/365d稼働させていた事もあり、
約3年でクラッシュした。
- データコピー
定説通り、適当な余りHDDにddやらddrescueでデータコピーを実行。
…しようとしたら、そもそもコピーする段階でエラーが発生して読込み出来なかった。
流石に、ハードウェアコピーする機械は所持していないので、
今回は仕方なくデータ救えなくなる事を覚悟で元HDDでデータ救出を実行。
- fsckでFS修復
定説通りにfsckを実行。
今回のHDDはext4だったので、途中まで普通に走ったが、
ddでエラー出た辺りのブロックでエラー再発したので停止。
- 復旧天使の実行
物は試しと復旧天使を実行してみた所、一部のデータは0バイト状態で見えた。
ただ、0バイトなのでファイルの残骸しか残っておらず断念。
- 再度、fsck実行
ここまで来たら復旧は諦めて、fsckをエラー吐かせつつ全領域実行してみた。
2TBを実行するのに丸3日掛かったが、最終的には完走。
ただ、やはりファイルは復元出来なかった。
………
最終的には復旧出来なかったが、それなりに技術調査しながらやっていたので楽しかった。
まず、復旧させる時は真っ先にread-onlyでマウントするのが定石だが、
ハードウェアレベルで故障している場合は、そもそもマウント自体がアウトだった。
あと、先にfsckを実行したが真っ先に修復アプリに頼るのも一つの手かもしれない。
今回はext4だったが、xfsだとまた変わるのかもしれない。
xfsはfsckの代わりにxfs_repairコマンドになったが、
ダーティログを持つFSを修復出来なかったりするが、
天下のredhat様が色々とドキュメントを公開しているので、ある程度までは対応出来る。
そもそも、バックアップ取得しておくのが最良だが、
稀に復旧チャレンジする場面があるので、憶えておこうと思う。
« 続きを隠す
