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


以上ウ