サーバクラーッシュ！...涙。でも上を向いて歩こう！（号外）

今回はちょっとリアルなトラブル。なので当然ながらマニアックな話です。
UNIX（Linux）用語が何の説明もなく出てきますので、いつもご愛読いただいている皆様には、ワケわからんかもしれません。
ご容赦を。

もう20年ほど自宅で使っているサーバがコケた。20年といっても、中身は何度か入れ替えしてるので、見た目がいっしょという程度なのだけど、ずっと同じホスト名でLinux（主にCentOS。今はRockyLinux）を動かしているので、それなりに愛着はある。

こんだけ長期間使ってると、それなりにトラブルは起きるので、途方に暮れるとまではいかないんだけど、でも憂鬱な作業なのは間違いない。

最初は、リモートでssh接続できないところからだった。
物理コンソールを開くと、なんかI/O errorの文字がチラホラと見える。この時点でおそらくディスククラッシュだろうことは見えていた。

リモート接続できないと何もできんので、リブートさせたところ、今度は/boot（カーネル入ってるパーティションね）のマウントすらできずに、かたまってしまった。
というわけで、まずは鉄則であるログの確認。
journalctl -xb でログを見ると、やはりI/Oエラーが連発している。いよいよHDDが逝ってしまったことを覚悟する。

一応、リカバリをやってみようと思って、/bootに対して xfs_repairコマンドを-L付きで実行（ジャーナルを無視して強制修復）してみると、エラーはかなり出たものの、見た目は修復できた。
/bootの中身はほぼカーネルだけなので、ジャーナル無視しても大丈夫だろう。

これでうまくいったらラッキーだなぁ、と思いつつ再度リブート。
でも、別のI/Oエラーで止まる。今度は/varで起きてるみたい。/bootと同様に xfs_repairをやってみたが、今度はコマンド自体がエラーを吐いて終わった。
fatal error -- Input/output error

こりゃぁ、あきらめてディスク交換して再インストールだなぁ。メンドクセー。

「がんばりすぎないセキュリティ」を何年も主宰して、バックアップの重要性もさんざん書いている筆者なので、サーバのバックアップも一応は取ってる。
自宅ではサーバを複数台稼働させているので、相互バックアップを取っている。バックアップといっても、必要なconfig（/etc配下など）とアプリ（redmineなど）とデータ（postgreSQLとMariaDB）をアーカイブして取っているだけだし、複数マシンが同時クラッシュするとお手上げという程度。

もっとも、redmineなど導入が面倒なものについては、リストア検証はしていて、その手順書も残してある。（手順書は作業用マシンのOneDriveに置いてある）
筆者的にはリカバリするための準備は十分にしておいたつもりだ。

このあたりは、noteにも書いてるけど、バックアップは手間とコストのせめぎあいなので、いかに手を抜いて最低レベルを確保するかがキモになる。今回のトラブルはその検証に丁度いいと思っている。

さて、次回にはその再インストールのことを書いていこう。
きっと、思わぬ抜けやポカもあると思うけど、それを全て記録するのも大事なこと。
実際のところ、redmineは仕事にも使ってるんで週明けには完全復旧させないと、いろいろと面倒だから。

果たして笑顔で復旧できるのか、はたまた、頭を抱えて自分の不備をののしることになるのか。
サーバ復旧物語のはじまりはじまり。

続きはこちらのマガジンでどうぞ

サーバ復旧物語｜えがおIT研究所｜note