とりあえずそれっぽく前書き
前兆はあったんですけどね...
ちゃんとバックアップは取りましょう(自戒)
この記事はOSごと再構築することを決めたうえで逝かれてしまったファイルシステムからデータの回収に苦戦した話です
調べても同様のケースの記事が出てこなくて大変だったので備忘録がてら公開してみようと思います
またこの記事で発生した損害等の責任は一切負えません
全て自己責任で行ってください
環境はubuntu 22.04
ライブ起動に使ったのは debian11
vpsはcontaboを使ってます(コスパ最強)
カーネルバージョンは起動不可になってどう見ればいいかわからなかったので許してください
起動不可の状態でも読み取れる方法あれば優しい人教えてください....
一旦結論から
ファイルシステムのジャーナルがいかれてました
起動時にfsckが毎回走りますよね
その時に残っていた壊れたジャーナルを復元しようとしたせいでそこから進まなかったみたいです
sudo mount -o ro,noload /dev/<device>
<device>にはそれぞれの環境のデバイスファイルを指定してください
これで読み込み専用かつnoloadオプションを使うことでジャーナルを無視してマウントすることができます
これで内部のデータが吸い出せたのでデータを回収、そのデータを使いつつOSを入れなおして再構築して終わりました
ログは吸い出せていたんですがぱっと見めぼしい情報がなかったので突然サーバーが死んだ真相は謎のままです
簡単に状況
ある日突然サーバーが死んだというアラートが来ました
個人でしか使っていないサーバーだったのでのんびりどんなもんかなと確認するとブートログ？にrecovering journalという表示で固まっているようでした
試したこと
まずはvpsを契約してるサービスからdebian11のライブ環境で再起動
sudo fsck.ext4 -v /dev/<device>
これで万事解決
と思いきやここでもrecovering journalの表示がでてOSごとフリーズ
どれだけ待ってもfsckが進まない状況に陥りました
そのまま待ち続けているとsshのコネクションも切れて新しい接続も受け付けないみたいだったのでライブ環境で再起動
手間かけさせやがってと思いながら今度は-f オプションもつけてやってみると
またまたOSごとフリーズ
sudo fsck -v -n /dev/<device>
-nオプションを付けて実際には修復処理を行わないことでスーパー ブロックが壊れていることがわかりました
作業後に書き始めてしまったせいでどのようなエラーが出ていたか忘れてしまったのですがsuper block checksum miss matchのようなエラーだったと思います
バックアップのスーパーブロックだとかを見つけ出してそれを使って修復しようとしたりもしたはしたんですが何も変わらず....
最終的に状況は違うものでしたが、ジャーナルを無効化して内容の読み取りができたという海外の記事を見かけたので試してみたら成功しました
終わりに
もともと知識のアウトプットとしてブログを書いたり成果物を作りたいと思っていたのですが先日とある方に背中を押されたので気楽にやって行こうと思います
かなり前の話をまとめたものなのでその時に参照した記事、実行結果の画像などが無くて申し訳ないです
私の場合はバックアップが一切なかったので、なんとか最初に上げたマウント方法でデータを回収し、サーバーを再構築して事なきを得ました
皆さんはこうならないようにしっかりとバックアップを取りましょう