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を一旦消す手順なので、実施する場合は注意してください。
またコマンドはコンソール上なのでコピペができないと思います。
バックアップと一緒に上記コマンドのスクリプト作って取っておいたがいいかもですね。

以上ウ