dump/restoreコマンドを用いたシステム領域復旧の話。
IBMCloudではImagetemplateが使用できるので、ポータル上からポチポチするだけでOS領域のみのバックアップ・リストアできて楽です。が、以下の懸念点があります。(2018/08/03時点)
・テンプレートの保管に月$25/GBかかる
・OSのパスワードが新しいものに変わる
・IPアドレスなどネットワーク周りの設定が初期化される
・OSリロードという策もあるが、システムの領域は真っさらになる上にカーネルバージョンも強制的に最新のものになる
上記のようにクラウド独自のバックアップサービス使用が困難、かつLinuxバックアップサーバ―が1台しかないとかだと、バックアップサーバ―自体のシステム復旧が必要になった時どうする？となります。
てことで、ここでは"OSレベルでdump/restoreコマンドを使用した復旧手順"です。
流れとしては、
①dumpコマンドでOS領域(/と/boot)を2ndディスクにバックアップしておく (バックアップ先をNFSとかにしてもOK)
②メディアからブートしてレスキューモード起動 (クラウドのレスキューブートを使用)
③リストア先に合わせてパーティション作成
④/と/bootのファイルシステム作成
⑤マウントしてリストア実行
⑥/dev,/proc,/sysをバインド
⑦リストアした/システムをルートにする
⑧/boot/grub2/grub.cfgを書き換える
⑨/etc/fstabを書き換える
⑩GRUB2をPReP Bootデバイス(/dev/xvda)に再インストール
⑪メディアを外してリブート
いや～めんどくさい。
事前準備
・OS領域はIBMCloudのVSIデバイス”/dev/xvda”とします。
・バックアップ先として/bkupに2ndDISKのFSをマウントしているものとします。
まずパーティションやLVM情報を事前に取得しておきましょう。
sfdisk -d /dev/xvda > /bkup/sfdis.dat
pvdisplay > /bkup/pvdis.dat
vgdisplay > /bkup/vgdis.dat
cat /etc/fstab > /bkup/fstab.dat
mount > /bkup/mount.dat
blkid > /bkup/blkid.dat
vgcfgbackup VG名 -f /bkup/vgcfg.dat (/領域にLVMが組まれている場合は実施)
dumpコマンドがない場合はインストール
yum install dump
ーーー注意ーーーーー
※dumpはFSタイプが"EXT"でのみ使用できます。
※IBMCloudのVSIのタイプに合わせて本手順では"EXT"とします。
※FSタイプを確認して、もし"XFS"であれば"xfsdump"をインストールしてください。オプションも若干変わります。
ーーーーーーーーーー
①dumpコマンドでバックアップを取る。
dump 0 -f /bkup/root.dump /dev/xvda2
dump 0 -f /bkup/boot.dump /dev/xvda1
これでバックアップ完了です。
/bkup以下を確認して.dumpファイルがあることを確認しましょう。
②メディアからブートしてレスキューモード起動
物理ならメディアをぶち込み
仮想環境なら管理画面からISOマウント
クラウドならカスタマーポータルからレスキューブートします。(IBM Cloud)
ちなみにメディアのバージョンが古すぎるとこの後の手順でひっかかるので、なるべくリストアするシステムと近いバージョンにしましょう。同じメジャーバージョンなら安心です。
また、レスキューメディアとリストアシステムのアーキテクチャ(64,32bit)も合わせておく必要があります。
③パーティション作成
ISOブートしてKVMコンソールでレスキューモードに入りましょう。
CentOS7ではTrouble shootingからRescue a CentOS systemを選択します。
sh-4.2#
などのプロンプトがでてくればOK
2ndDISKのデバイスはみえているはずなので、
適当なリストアファイル用ディレクトリを作成します。(本手順では/bkup)
リストアファイルが置いてある/bkupをマウント
mount /dev/vg_bkup/lv_bkup /bkup
もしデバイスのstateがnot availableになっててできない場合は有効化。
lvchange --available y /dev/vg_bkup/lv_bkup
バックアップしたファイルが見えているか確認。
ls -l /bkup
事前準備で取得したsfdis.datから構成情報をリストア
sfdisk --force /dev/xvda < /bkup/sfdis.dat
※事前準備でvgcfgbackupしていた場合は以下も実施
lvm vgscan
lvm vgcfgrestore -f /bkup/vgcfg.dat ${VGNAME}
④ファイルシステム再作成
/と/bootのシステムを再作成します。FSタイプは実機に合わせましょう。
mkfs.ext3 -f /dev/xvda1
mkfs.ext3 -f /dev/xvda2
⑤マウントしてリストア実行
リストア対象のファイルシステムをマウントしておく必要があるので、一時的なマウント先を作成します。名前やパスはなんでもいいです。
mkdir /restore
rootをマウントしてリストア
※デバイス名に注意
mount /dev/xvda2 /restore
cd /restore
restore -rf /bkup/root.dump
一次領域アンマウント
cd /
umount /restore
bootをマウントしてリストア
mount /dev/xvda1 /restore
cd /restore
restore -rf /bkup/boot.dump
アンマウント
cd /
umount /restore
再度、rootをマウント
mount /dev/xvda2 /restore
⑥/dev,/proc,/sysをバインド
これしないと後のgrub2関係がうまくいかないっぽいのでそれぞれバインド
mount --bind /proc /mnt/sysimages/proc
mount --bind /sys /mnt/sysimages/sys
mount --bind /dev /mnt/sysimages/dev
⑦リストアした/システムをルートにする
chrootでルート変更
chroot /restore
/bootをマウント
mount /dev/xvda1 /boot
⑧/boot/grub2/grub.cfgを書き換える
ファイルシステムを再作成した時点でUUIDが変わっています。
そのため、/boot/grub2/grub.cfgに書かれている(/boot) のUUIDを
再作成した方のUUIDに書き換える必要があります。
grub.cfgは直接編集NGなので、現環境に合わせてgrub.cfgを再生成する以下コマンドを実施。
/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
⑨/etc/fstabを書き換える
/etc/fstabも同様、書き換える必要があります。
こちらは直接編集可ですが、手打ちは怖いので以下のコマンドを実行。
export NEWUUID=`blkid | grep /dev/xvda1 | awk '{print $2}' | cut -d '"' -f 2`
export OLDUUID=`cat /bkup/fstab.dat | grep /boot | awk '{print $1}' | cut -d '=' -f 2`
sed -i.org -e "s/UUID=${OLDUUID}/UUID=${NEWUUID}/g" /etc/fstab
⑩GRUB2をPReP Bootデバイス(/dev/xvda)に再インストール
/sbin/grub2-install /dev/xvda
"install finished. no error reported"
と表示されればOK
⑪メディアを外してリブート
あとはリブートし、リストアしたシステムからブートするようにします。
この手順はOS領域のFSを一旦消す手順なので、実施する場合は注意してください。
またコマンドはコンソール上なのでコピペができないと思います。
バックアップと一緒に上記コマンドのスクリプト作って取っておいたがいいかもですね。
以上ウ