画像やリンクが無効になっている可能性もあるのでご了承下さい。
2019/07/10 03:47 頃、新しくなった SSD (Crucial BX500 120GB) が smartctl の返値に 32 を返すことが気になり、smartctl -t long /dev/sda と打ち込んだらそのまま息を引き取った。具体的には BX500 を繋いだままだとサーバーマシンが起動しないという物。Windows マシンに USB 接続してもドライブ自体認識しないので手の施しようがない。
smartctl コマンドでストレージの診断を行う機会も少なくはないし、過去にこう言った目に遭ったことも無いから「まさか壊れるとは」なんて思っても見なかった。
幸いにも別で接続してるバックアップ用 HDD に 2019/07/09 01:00 時点でのシステムフルバックアップが残っていたのでそこから復旧させるべくアレコレやっておいた。
先ずは以前まで使っていた Crucial RealSSD C300 64GB を呼び起こしてマウント。
CentOS 7 をインストールしてから USB ブートのレスキューモードへ切り替え。以前の面倒な失敗を踏まえ、カーネルパラメータに selinux=0 を付けてレスキューモードの起動をしておいた。
後は rsync -aAXv なんちゃらとやって SSD にリカバリ。
しかしここでミス。/boot までバックアップしていたもんだからそれが SSD に乗っかってブートしなくなると言う罠。
再びレスキューモードで起動して grub2.cfg を開き、弄るなと書いてあるのに手動書換で対応。UUID を対応する物に変えたりパラメータ弄ったりしてやっとこさ起動にこぎ着けた。
その後は fstab 弄って別で載せてる HDD x2 を自動マウントするようにしつつ syslog と munin を眺めて一段落と。
今回は特に grub2.cfg との格闘が面倒だった。ssh 経由で弄れないのでコンソール直叩きで UUID を控えて打ち込みとか面倒臭い事極まり無い。
生憎色々技術不足な部分が本当に多いので苦労したけど自力で全て解決出来たので良いお勉強にはなったかなと。
今後は弄った grub 周りがどう影響してくるかが課題。
しかし眠いし疲れた…
2019/07/10 18:30 追記
取り敢えず動作確認の取れた後は直ぐに寝ておいた。
起床後は設定ミスって LVM にしていなかった swap パーティションを削除して空き領域を作った後、PV 作って VG に入れて lvcreate で swap 領域を作成後、swapon コマンド打ち込んでいつも通りのパーティション構成に戻せた。
あとは grub で LVM の swap を見に行くカーネルパラメータがあったので、/etc/default/grub にあるパラメータを現環境に合わせて書き換え。
grub2-mkconfig -o /boot/grub2/grub.cfg と打ち込んでから再起動させてそのまま正常に起動すること確認して本件は取り敢えず終息ということで。
肝心の SSD は Amazon に問い合わせた結果、購入後 30 日以内だからということで交換対応頂けるそうで既に手配済み。
交換品が届き次第、また smartctl コマンド打ち込んで死亡しないか確認した後の交換作業としたいところ。
コメント