サーバー保守業務でのバックアップ対応
はじめに
こんにちは。サーバ運用保守業務を行っている uma です。
サーバ保守業務においてバックアップはとても重要なカテゴリの一つです。
バックアップは会社の大事な資産を守ることにつながります。
この記事では、あるユーザーが一部コンテンツを削除してしまい、
復元作業をしなければならないとなったときのシミュレーションをしてみたいと思います。
通常はバックアップ復元対応において手順書は準備されているかとは思いますが、
いざ自分が対応するとなったら、アタフタしてしまいますよね…
少しでも想定される内容をおさえておくことが重要だと思います。
考える事象
下記状況下でどのようにして復元対応を行うのが最適なのかを考えてみたいと思います。
<状況>
- スナップショットは毎日朝の03:00に取得している
- 朝の11:00頃、誤って一部のコンテンツデータを削除してしまった
- 緊急のコンテンツ復元依頼
あなたは運用保守担当です。どう対応するのが最適だと思いますか?
復元の検討
朝の11:00頃にある特定のコンテンツのみ削除してしまったということなので、その日の朝の03:00のバックアップから復元すれば良いことは分かります。次に、なるべくならコンテンツ以外のところはロールバックしてほしくないと私は考えました。但し、実際はそんなに単純な判断では足りず、復旧までの時間も考慮しなければなりません。例えば、コンテンツのみだけだとしても、コピーの時間も復旧までの時間として考慮しなければなりません。そこはお客様と相談し、最適な方法を検討することが重要になります。
今回のテストでは、大した容量もないので誤って削除してしまったデータのみを復元するのが妥当でしょう。そう判断して対応をすすめます。
さくらのクラウドで実践
事象発生から対応までを”さくらのクラウド”で疑似的に実践してみます。
雰囲気を伝えるのみとしますので細かな手順については割愛します。
・該当サーバに対するディスクのアーカイブ（バックアップ）を予め準備
・偶発的にバーチャルホストの以下コンテンツディレクトリを削除してしまった（ということにします）
# rm -rf /var/www/vhost/wp/public_html
（本当だったら冷汗がでますね….汗）
・URLの閲覧確認 → 当然閲覧できない…
・バックアップから戻す（ここからがバックアップからの復元スタートです！）
・さくらのクラウドのコントロールパネルより、「ディスク → マイアーカイブ選択（※先に準備したバックアップを指定） → 作成」の順に復元対応をすすめていきます。
・サーバを停止
アタッチ（接続）ボリュームを用意出来たらサーバ停止をおこないます。
さくらのクラウドの場合、ディスクボリュームをアタッチするためにはサーバーを停止しなければなりません。
・ディスクボリュームをアタッチ
・サーバを起動
・OSにログイン
# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 475M 0 475M 0% /dev/shm
tmpfs 190M 5.3M 185M 3% /run
/dev/vda2 20G 5.4G 14G 30% /
tmpfs 95M 4.0K 95M 1% /run/user/1000
#
・アタッチされたディスクデバイスの存在を確認
下記のとおり /dev/vdb2 デバイスが見れますね
# ls -la /dev/vd*
brw-rw—- 1 root disk 253, 0 Aug 28 20:40 /dev/vda
brw-rw—- 1 root disk 253, 1 Aug 28 20:40 /dev/vda1
brw-rw—- 1 root disk 253, 2 Aug 28 20:40 /dev/vda2
brw-rw—- 1 root disk 253, 16 Aug 28 20:40 /dev/vdb
brw-rw—- 1 root disk 253, 17 Aug 28 20:40 /dev/vdb1
brw-rw—- 1 root disk 253, 18 Aug 28 20:40 /dev/vdb2
#
・マウント領域を準備してアタッチしたディスクボリュームをマウント
# mkdir /MNT
# mount /dev/vdb2 /MNT
# ls -ld /MNT/var/www/vhost/wp/public_html
drwxr-xr-x 6 apache apache 4096 Aug 18 20:14 /MNT/var/www/vhost/wp/public_html
・該当のコンテンツ領域をコピーして復元
事前確認でコンテンツがとんでもない容量だった場合は、03:00のスナップショットのディスクで起動した方が復旧ははやい場合があります。
# cp -ip /MNT/var/www/vhost/wp/public_html /var/www/vhost/wp/.
# umount /MNT
・URLの閲覧確認
修復された。よかったです…
まとめ
今回は、さくらのクラウドで実践しましたが、AWSでも考え方は同じで、やることも同じだと思います。
また、部分復元かまるごと復元かについては、復旧時間も考慮しお客様と決めていくことが重要です。もちろんOSが起動しない場合や、復元範囲が広すぎる場合の対応は、スナップショットを取得したところまでロールバックする方が良いでしょう。
事前のバックアップ方法も検討した上で、状況に応じて最適解を見つけていきましょう。
