昨日(6/12)から室温が急激に上昇し昼間に30℃を軽く越えてしまうようになったためか、このメモを書いているWebサーバーが突然 Panic とリブートを繰り返すようになってしまいました。このサーバーを使い始めたのは昨年の10月頃だったはずなので、初めての本格的な夏を迎えようとしているわけですが、6月でこの調子では、真夏はどうなるんだろう?
先日から高負荷時に突然再起動が発生していましたが、昨日や本日は負荷とは関係なく再起動します。
原因究明なんてやってるヒマはないので、パーティション丸ごとバックアップして、別のマシンに復元することにしました。実は、昨晩、ストレージ関係はそのままにして、マザーボードを交換する作業を行いましたが、別のマザーボードではIDEのジオメトリとアクセスモードが一致しないのか、DMA関係のエラーが出てカーネル起動中に /dev/ad1s1d がマウントできずリカバリーシェルに落ちてしまい、挫折。やむなく元のマザーボードに戻し運用をしながら、パーティションを dump コマンドでバックアップを開始。
基本的には、/ 、 /usr、/home をバックアップして、別のマシンにリストアすればいいわけです。ただし、ログファイルなど更新が頻繁なファイルも消すことなく、移行しなくてはいけません。バックアップしてから、新サーバーが動き出すまでに、旧サーバーで更新されるログ情報などが失われてしまうようなことは避けなくてはいけません。
更新が少ない /usr は運用したまま dump バックアップでも問題ありません。 / パーティション、特に /var は常時書き込みが発生しているため、一番いいのは運用を一旦停止しシングルユーザーモードにした後 dump するのがベストです。しかし、そうするとダウンタイムが長くなるため今回は一度 dump でフルバックアップした後、サーバー停止直前に、全てのサービスを停止させ、再度差分 dump することにしました。 /home に関しては移行しないファイルもあるので dump は使わず cpio でファイル保存。
具体的なバックアップ方法としては、
- 運用中に行った作業
- cd /mnt （事前に /mnt にバックアップ用パーティションを接続しておく。）
- # dump -0uaLC 32 -f root.dump /
- # dump -0uaLC 32 -f usr.dump /usr
- root.dump と usr.dump を別のサーバーに移す。
- サービスを停止させた後に行った作業
- # dump -1uaLC 32 -f root1.dump /
- # dump -1uaLC 32 -f usr1.dump /usr
- # cd /home
# find . |cpio -ov > /mnt/home.cpio - root1.dump, usr1.dump, home.cpi を別のサーバーに移す。
注: FreeBSD11 ではdump -L （live file system) を使うと
mksnap_ffs: Cannot create snapshot //.snap/dump_snapshot: /: Snapshots are not yet supported when running with journaled soft updates: Operation not supported
となりますので L を省略のこと。
新サーバーでは、まずはネットワークとコマンドが使える最小の仮OSをインストールして起動して、初期化しないパーティションに旧サーバーのバックアップを ftp でコピー。（以下の mnt2 にマウント予定。）
その後で、FreeBSD livefs CDで起動して fixit を実行。fixit シェルで restore コマンドを発行してシステムを復元。OSが起動すしたあとで、/home をリカバー。
fixit のシェルで行う具体的なリストア作業は、
- 事前に /mnt2 パーティションに root.dump, root1.dump, usr.dump usr1.dump, home.cpio をコピーしておきます。
- # TMPDIR=/mnt2
# export TMPDIR
空きスペースがある書き込み可能なディレクトリを準備しておかないと restore コマンドの作業領域が無いため restore コマンドがエラーで終了してしまうために必要なコマンドです。 - ルートパーティションをリカバー
# cd /mnt
# restore -rvf /mnt2/root.dump
# restore -rvf /mnt2/root1.dump - /usr パーティションをリカバー
#cd /mnt/usr
# restore -rvf /mnt2/usr.dump
# restore -rvf /mnt2/usr1.dump - ハードウェアが異なるので、/mnt/etc/fstab と /mnt/etc/rc.conf を新しいハードウェアに合わせてカスタマイズ（デバイスファイル名を編集）
特に fstab の修正を忘れてリブートすると、パーティション名が異なる場合は起動しないため、もう一度 fixit シェルから作業を行うハメになるので注意。起動中の修復シェルから行えるかも。 - fixit を抜けてOSを再起動
- /home のリカバーがまだなので、root でログインして cpio でリカバー。
# cd /home
# cpio -idumv < backup/dir/home.cpio
このあとで/home データが回復して、サーバー運用が再開。停止していたrc.conf スイッチなどを復活させてOSを再起動するかサービスだけ再立ち上げ。
これで、全ての情報を保ったまま新しいサーバーに移行することが出来ました。結局3時間くらい（20:30頃から23:30頃までの間）サーバーを停止していたことになります。文章で書くと dump/restore しただけですが、不安定なサーバーのファイルシステムをバックアップするのがえらく大変でした。しかも、別のリモートサーバーのOS更新中に、手元サーバーに異常が頻発し始めたものだから、この二日間は大変な思いをしました。サーバーは速くなくてもいいから厳しい条件でも確実に動き続けて欲しいわ。