LoginSignup
7
5

More than 5 years have passed since last update.

@MahoTakara(Maho Takara)

ベアメタル CentOS の OSバックアップとリストアのメモ

Last updated at Posted at 2017-05-24

Bleumix インフラストラクチャー Baremetal Server の CentOS を Linuxのコマンドによるバックアップ、および、ディスク障害からのバックアップ時点までに復旧するリストア方法の備忘録です。対象のCentOSは、CentOS6.x x86-64, CentOS7.x x86-64で、バックアップの取得先は、Bluemix インフラストラクチャー の オブジェクト・ストレージです。
Bluemix インフラストラクチャー の Flex Image は CentOS7.x がサポート対象となっていません。このため、CentOS7.x の OSイメージのバックアップが、手軽に出来ないという課題がありました。

スクリーンショット 2017-05-23 13.09.44.png

特記事項

  • 本方法では、オブジェクト・ストレージの１オブジェクトの最大制限 5GB の制約を受けません。 したがって、OS起動ストレージが、5GB を超えるデータが保存されていても、すべてバックアップする事が出来ます。
  • RedHat Enterprise Linux 6 / 7 の検証は実施していません。
  • 本方法を仮想サーバーのバックアップに適用して、ベアメタルサーバーへリストアすることは検証していません。 また、その逆も検証していません。
  • 本方法を４コアのベアメタルのバックアップに適用して、10コア等の大きなサイズのベアメタルへリストアする事は検証していません。すなわち、異なるベアメタルサーバーへリストアも検証していません。
  • 本方法を他社の仮装サーバーや物理サーバーのバックアップに適用して、Bluemix インフラストラクチャー のベアメタルサーバーへリストアする事は検証していません。
  • (注意）本方法は技術ノウハウを提供することが目的であり、利用者へのOSバックアップ・リストアを保証するものではありません。自己責任において利用をお願いします。

準備作業

このバックアップとリストアの方法では、Bluemix インフラストラクチャーのオブジェクト・ストレージに、アカウントを持っている必要があります。 アカウントの取得方法は、https://control.softlayer.com/ のメニューから Storage -> Object Storage -> Order Object Storage でアカウントを取得しておきます。

定期的なOSバックアップ取得として活用するのであれば、本記事で紹介するツール群をインストールしておく事をお勧めします。

基本的な作業の概要

基本的な流れは次の様になります。

バックアップの準備作業概要

  • バックアップ・ツールのダウンロード (GitHub からのクローン)
  • オブジェクト・ストレージの認証情報をツールの設定ファイルにセット

バックアップ実行概要

  • バックアップ用のシェルスクリプトの実行

リストア実行手順概要

  • ディスク交換後、OSのリロードを実行
  • レスキュー・カーネルで起動
  • リストア・ツールのダウンロード (GitHub からのクローン)
  • オブジェクト・ストレージの認証情報のセット
  • リストア用のシェルの実行
  • 再起動

それでは、ここから詳細な内容に入っていきます。CentOS6.x と CentOS7.x ではコマンドやファイルなどが異なっていますが、シェルの中で切り替えて実行しています。

CentOS のバックアップ準備

ここから、すべて root での作業で、rootのホームディレクトリ /root で実行することを想定しています。 まず、git コマンドをインストールします。

# yum install git -y

次に、オブジェクト・ストレージにバックアップするためのツールを導入します。このツールのシェルは、rootのホームディレクトリ /root/os_tools で実行することを想定して書いていますので、それ以外の場所で実行する場合は、シェルを編集する必要があります。

バックアップ・ツールのダウンロード

# git clone https://github.com/takara9/os_tools

オブジェクト・ストレージの認証情報をツールの設定ファイルにセット

オブジェクト・ストレージの認証情報をツールの設定ファイルにセットします。 サンプルのファイル名は、credentials.json.sample でクローンしたファイルの中に含まれています。 このファイルの内容を本当の認証情報に置き換えます。

# mv credentials.json.sample credentials.json

このファイルの内容は、以下の様になっていますから、ポータル画面のオブジェクト・ストレージの認証情報 (Credentials) の内容に編集します。

{
    "username": "IBMOS000001-1:IBM000001",
    "password": "63411c19faee094567cab66d5127e40f5b8f13192cbcc16d21b751f330e13df",
    "data_center": "tok02"
}

CentOS バックアップの実行

CentOS の OSバックアップは、以下のシェル・スクリプトを実行するだけです。 

# ./backup_os

バックアップ先のオブジェクト・ストレージには、次の様にデータが保管されます。 sda1 と sda3 はメタファイルになっており、このメタファイルをダウンロードする事で、5GBを超えるファイルも一括で取得できます。

スクリーンショット 2017-05-24 14.49.40.png

このシェル・スクリプトは、次の特徴を持っています。

  • リストアに必要なファイル群が、オブジェクト・ストレージにアップロードされます。
  • CentOS のバージョンに合わせて、実行するコマンドを変更するようになっています。
  • バックアップの所用時間は、ベアメタル導入直後の状態(1.6GB使用) で30秒前後です。
  • バックアップデータの一貫性を確保するための再起動やシングルユーザーモードへの移行を実施しません。
  • sda1 をブート・ディスク、sda3 を ルート・ディスクとして固定設定しています。
  • 一つのオブジェクトが5GBを超えるサイズに対応しています。
  • オブジェクト・ストレージのコンテナを参照することで、バックアップの内容を確認できます。

CentOS リストアの実行

ベアメタルのディスクが壊れた場合、データセンターの技術員が壊れたディスクを交換して、もとのOSをリロード（再インストール）する処まで実施してくれます。そこで、この記事は、OSリロード完了した状態から、バックアップ取得時点まで復元する事を主に記載します。 OSのパーティションを設定、ファイルシステム作成等の作業は考慮していません。

ディスク交換後、OSのリロードを実行

ポータルから実行するには、サーバーの詳細画面のアクションのメニューを展開して、OSリロードを選択することで、OSの再インストールをスタートできます。 下記のスクリーン・ショットでは、上から４番目の項目です。
スクリーンショット 2017-05-23 14.10.02.png

レスキュー・カーネルで起動

ベアメタルの内臓ディスクに、バックアップしたOSイメージをコピーするために、ベアメタルサーバーをレスキューモードで起動します。 前述のアクション・メニューの上から３番目 Rescue をクリックします。 レスキュー・モードで起動が完了すると、パブリックIP または プライベートIP に対して、rootユーザーでログインできます。この時の認証は、ポータルから参照できる root のパスワードを用います。

レスキュー・カーネルを起動する際に、KVM Console を起動しておくと、重大なOSエラー等がコンソールへ出力されるので、問題を早く発見する事ができます。 KVMコンソールを利用するには、SSL VPN 接続している必要があります。　次のスクリーン・ショットは、レスキュー・カーネルを起動した時のもので、起動直後はNICが初期化されていないため、IPアドレスにsshでアクセスして、ログインする事ができません。 起動後しばらくすると、NIC のポートがリンクアップしていきますので、これが完了すると、ssh を使って、プライベート側のIPアドレスへ接続する事ができる様になります。
スクリーンショット 2017-05-24 15.57.56.png

リストア・ツールのダウンロード

これは前述のバックアップ・ツールのダウンロードと同じです。

# git clone https://github.com/takara9/os_tools

オブジェクト・ストレージの認証情報のセット

前述のオブジェクト・ストレージの認証情報のセットと同じです。 もし判らなければ、オブジェクト・ストレージにアップロードされていますから、ポータルからオブジェクト・ストレージにアクセスして、credentials.json をダウンロードする事で、参照できます。

リストア用のシェル・スクリプトの実行

レスキュー・カーネルからリストアを実行するには、次のコマンドを実行します。

# /root/os_tools/restore_os

このシェルを実行すると、レスキュー・カーネルのルートファイルシステムの下に、/sysimage/boot と /sysimage としてマウントされ、リストアされた状態になります。この後 /sysimage に展開された内容に対して、grub.conf、fstab を自動修正します。

[root@rescuelayer os_tools]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/loop5       3997376 1820116   2118944  47% /
devtmpfs        32657848       0  32657848   0% /dev
tmpfs           32930796       4  32930792   1% /dev/shm
tmpfs           32930796 2062488  30868308   7% /run
tmpfs           32930796       0  32930796   0% /sys/fs/cgroup
/dev/loop0        522810  522810         0 100% /run/initramfs/live
tmpfs           32930796       8  32930788   1% /tmp
varcacheyum     32930796   76752  32854044   1% /var/cache/yum
vartmp          32930796       0  32930796   0% /var/tmp
tmpfs            6586160       0   6586160   0% /run/user/0
/dev/sda1         253871    2051    238713   1% /sysimage/boot
/dev/sda3      960011672   73380 911149404   1% /sysimage

注意事項
レスキュー・カーネルは、CentOS7.xベースのため、レスキュー・カーネルの mkfs系コマンドで、ファイルシステムを作成した場合、CentOS6.x系では未サポートの内容を含むため、ファイルシステムをマウントできなくなる事があります。 CentOS6.x を復旧させる場合には、ポータル操作で OS reload によって作成されたファイルシステムへリストアする事がお勧めです。

再起動

再起動して、CentOSが起動して、login プロンプトが表示されると成功です。

# reboot

トラブルシューティング

  • リストア後の起動時に、カーネルパニックが発生して起動不能となる

スクリーンショット 2017-05-24 22.04.28.png

原因は、CentOS6.x のgrub.conf の / のディスク(sda3) の UUID を指定が間違っている場合、本問題が発生する。 grub.conf の UUID を再確認する。

参考資料

7
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
5