24 Relax-and-Recover (Rear)による障害復旧 #
概要#
Relax-and-Recover (旧称「ReaR」。この章ではRearと略記)は、システム管理者による使用を意図した障害復旧フレームワークです。Rearは、障害発生時に保護対象となる特定の運用環境に合わせて調整する必要があるBashスクリプトのコレクションです。
特別な設定を必要とせずにそのまま使用できる障害復旧ソリューションはありません。したがって、障害が発生する前に準備しておくことが不可欠です。
24.1 概念の概要 #
以降のセクションでは、障害復旧の一般的な概念を述べ、Rearを使用した復旧を実現するために必要となる基本的な手順について説明します。また、Rearの要件に関するいくつかの指針、知っておくべき制限事項、およびシナリオとバックアップツールについても紹介します。
注記: Rearについて
Rearの複雑な機能を理解することは、ツールでの作業を意図したように行うために重要です。したがって障害が発生する前に、この章を注意深く読んで、Rearについての理解を深めてください。また、Rearの既知の制限事項を認識し、システムをあらかじめテストする必要もあります。
24.1.1 障害復旧プランの作成 #
最悪のシナリオが発生する前に、ITインフラストラクチャに重大なリスクがあるかどうかの分析、予算の見積もり、障害復旧プランの作成などの対応策を講じます。障害復旧プランを手元に用意していない場合は、以下の手順ごとに情報を入手します。
リスクの分析： インフラの確かなリスク分析を実施します。可能性のあるすべての脅威を一覧表示し、深刻度を評価します。これらの脅威が発生する可能性を判断し、優先順位を設定します。可能性と影響の簡単な分類を使用することを推奨します。
予算のプラニング： 分析結果には、どのリスクが耐えうるもので、どれがビジネスにとって致命的であるかを全般的に示します。リスクを最小限にする方法およびそれに要するコストを自問して検討します。会社の規模に応じて、IT予算全体の2～15%を障害復旧に使用します。
障害復旧プランの作成： チェックリストの作成、手順のテスト、優先順位の設定と割り当て、ITインフラのインベントリ調査を行います。インフラのサービスが失敗した際、問題に対処する方法を定義します。
テスト： 念入りなプランを定義したら、それをテストします。最低でも1年に1度テストします。ご使用のメインITインフラと同じテストハードウェアを使用します。
24.1.2 障害復旧とは #
運用環境に存在するシステムが、ハードウェアの損傷、誤設定、ソフトウェア上の問題など、原因がどのようなものであっても破損した場合は、システムを再作成する必要があります。再作成は、同じハードウェア上または互換性のある代替ハードウェア上で実行できます。バックアップからファイルを復元するだけでは、システムを再作成することにはなりません。システムの再作成では、パーティション、ファイルシステム、マウントポイントの面からのシステムのストレージ作成や、ブートローダの再インストールなどの作業も必要になります。
24.1.3 Rearによる障害復旧 #
システムが正常に稼働しているときに、ファイルのバックアップを作成し、復旧メディア上に復旧システムを作成します。復旧システムには、復旧インストーラが収められています。
システムが破損した場合は、損傷したハードウェアを必要に応じて交換し、復旧メディアから復旧システムをブートして復旧インストーラを起動します。復旧インストーラによるシステムの再作成では、まず、ストレージにパーティション、ファイルシステム、マウントポイントを作成し、続いてバックアップからファイルを復元します。最後に、ブートローダを再インストールします。
24.1.4 Rearの要件 #
Rearを使用するには、運用環境を実行するマシンおよびそれと同一のテストマシンが必要です。つまり、同一のシステムが2台以上必要になります。ここでいう「同一」とは、たとえば、ネットワークカードを、同じカーネルドライバを使用する他のネットワークカードに置き換えることができるということです。
警告: 同一のドライバが必要
運用環境のドライバと同じドライバを使用していないハードウェアコンポーネントは、Rearでは同一のコンポーネントとは見なされません。
24.1.5 Rearバージョンの更新 #
よい古いバージョンのサービスパックと互換性を持つために、SUSE Linux Enterprise High Availability Extension 12 SP5には、異なるRearバージョン: 1.16 (RPMパッケージ rear116の一部)、1.17.2.a (rear1172a)、1.18a (rear118a), および2.4 (rear23a)が付属しています。最新バージョンには、アップストリームGitHubプロジェクトからの、若干の最新の拡張が含まれます。
注記: 変更ログでの重要な情報の検索
バグ修正、非互換性、および他の問題に関する情報はすべて、パッケージの変更ログで検索できます。障害復旧手順を再検証する必要がある場合は、Rearのより最新のパッケージバージョンも確認することをお勧めします。
Rearには次の問題がありますので注意してください。
UEFIシステムで障害復旧を許可するには、バージョン1.18.aおよびパッケージ ebisoが必要です。このバージョンのみが新しいヘルパーツール
/usr/bin/ebisoをサポートします。このヘルパーツールは、UEFIブート可能RearシステムISOイメージの作成に使用されます。特定のRearバージョンによる障害復旧手順をテスト済みで、その手順が十分に機能しているのであれば、Rearを更新しないでください。Rearパッケージをそのまま保持し、障害復旧手法を変更しないようにします。
Rearの各バージョン更新は、インストール済みのバージョンが誤って別のバージョンに置き換えられることがないよう、相互に意図的に衝突する別個のパッケージとして提供されています。
次の場合に、既存の障害復旧手順を完全に再検証する必要があります。
Rearバージョンの更新ごとに。
Rearを手動で更新する場合。
Rearで使用されるソフトウェアごとに。
parted、btrfs、などの低レベルのシステムコンポーネントを更新する場合。
24.1.6 Btrfsに伴う制限事項 #
Btrfsを使用する場合は次の制限事項が発生します。
- システムにサブボリュームは存在しても、スナップショットのサブボリュームが存在しない場合
Rearバージョン1.17.2.a以上が必要です。このバージョンは、スナップショットのサブボリュームが存在しない「通常の」Btrfsサブボリューム構造の再作成をサポートしています。
- システムにスナップショットのサブボリュームが存在する場合
警告
ファイルベースのバックアップソフトウェアでは、Btrfsスナップショットのサブボリュームを通常どおりにはバックアップできず、復元することもできません。
Btrfsにはコピーオンライト機能があることから、Btrfsファイルシステム上にある最近のスナップショットサブボリュームはディスク容量をほとんど必要としません。一方、ファイルベースのバックアップソフトウェアを使用すると、これらのファイルは完全なファイルとしてバックアップされます。最終的に、これらのファイルはその本来のファイルサイズで2回バックアップされることになります。したがって、元のシステム上に以前に存在していたときと同じ状態にスナップショットを復元することができません。
- SLE12システムに適合するRear設定が必要な場合
SLE12 GA、SLE12 SP1、およびSLE12 SP2の設定には、いくつかの不適合Btrfsのデフォルト構造があります。そのため、適合するRear設定ファイルを使用することはたいへん重要です。
/usr/share/rear/conf/examples/SLE12*-btrfs-example.confのサンプルファイルを参照してください。
24.1.7 シナリオとバックアップのツール #
Rearでは、ハードディスク、フラッシュディスク、DVD/CD-RなどのローカルメディアからのブートやPXEを介したブートが可能な障害復旧システム(システム固有の復旧インストーラなど)を作成できます。バックアップデータは、例 24.1に説明があるNFSなどのネットワークファイルシステムに保存できます。
Rearは、ファイルのバックアップに取って代わるツールではなく、それを補完するツールです。Rearは、汎用的なtarコマンドのほか、いくつかのサードパーティのバックアップツールをデフォルトでサポートしています。このようなバックアップツールとして、Tivoli Storage Manager、QNetix Galaxy、Symantec NetBackup、EMC NetWorker、HP DataProtectorなどがあります。バックアップツールとしてEMC NetWorkerを使用したRearの設定例については例 24.2を参照してください。
24.1.8 基本手順 #
障害発生時にRearを使用して効果的な復旧を実現するには、以下の基本手順を実行する必要があります。
- Rearおよびバックアップソリューションのセットアップ
この手順では、Rear設定ファイルの編集、Bashスクリプトの調整、使用するバックアップソリューションの設定などのタスクを実行します。
- 復旧インストールシステムの作成
保護対象のシステムが稼働しているときに、
rear mkbackupコマンドを使用して、ファイルのバックアップを作成し、システム固有のRear復旧インストーラなどの復旧システムを生成します。- 復旧プロセスのテスト
Rearを使用して障害復旧メディアを作成した場合は、その障害復旧プロセスを必ず十分にテストしておくようにします。ここでは、運用環境を構成するハードウェアと同一のハードウェアを備えたテストマシンの使用が不可欠です。詳細については、24.1.4項 「Rearの要件」を参照してください。
- 障害からの復旧
障害が発生した場合は、必要に応じて損傷したハードウェアを交換します。続いて、Rear復旧システムをブートし、
rear recoverコマンドで復旧インストーラを起動します。
24.2 Rearおよびバックアップソリューションのセットアップ #
Rearをセットアップするには、少なくともRear設定ファイル/etc/rear/local.confを編集する必要があります。さらに、Rearフレームワークを構成するBashスクリプトも必要に応じて編集します。
特に、Rearが実行する以下のタスクの定義が必要です。
システムをUEFIを使用してブートする場合： システムをUEFIブートローダを使用してブートする場合は、パッケージ ebiso をインストールし、次の行を
/etc/rear/local.confに追加します。ISO_MKISOFS_BIN=/usr/bin/ebiso
ファイルをバックアップする方法および障害復旧システムを作成して保存する方法： これは、
/etc/rear/local.confで設定する必要があります。正確な再作成を必要とする対象(パーティション、ファイルシステム、マウントポイントなど)： これは、
/etc/rear/local.confで定義できます(たとえば、除外対象を定義できます)。標準とは異なるシステムを再作成するには、Bashスクリプトの拡張が必要になることがあります。復旧プロセスの仕組み： Rearで復旧インストーラを生成する方法の変更やRear復旧インストーラによる実行タスクとの適合を可能にするには、Bashスクリプトの編集が必要です。
Rearを設定するには、/etc/rear/local.conf設定ファイルに目的のオプションを追加します(これまで使用されてきた設定ファイル/etc/rear/sites.confは、パッケージから削除されました。なお、このファイルを前回のセットアップから引き継いでいる場合、Rearでは引き続きこのファイルが使用されます)。
すべてのRear設定変数とそのデフォルト値は、/usr/share/rear/conf/default.confに設定されています。/etc/rear/local.confなどで設定されているユーザ設定に合わせたサンプルファイルのいくつか(*example.conf)は、examplesサブディレクトリ下にあります。詳細については、Rearのマニュアルで該当のページを参照してください。
適合するサンプル設定ファイルをまずはテンプレートとして使用し、必要に応じて修正することで、個別の設定ファイルを作成します。いくつかのサンプル設定ファイルからさまざまなオプションをコピーし、システムに適合した特定の/etc/rear/local.confファイルにそれらをペーストします。特定の構成向けに利用できる変数の概要などが含まれるため、元のサンプル設定ファイルをそのまま使用しないでください。
Rear設定ファイルを変更した場合は、次のコマンドを実行して、その出力を確認します。
rear dump
例 24.1: NFSサーバを使用したファイルバックアップの保存 #
Rearはさまざまなシナリオで使用できます。以下の例では、ファイルのバックアップを収めるストレージとしてNFSサーバを使用しています。
『SUSE Linux Enterprise Server 12 SP5管理ガイド』(https://documentation.suse.com/sles-12/html/SLES-all/cha-nfs.html)の説明に従って、YaSTでNFSサーバを設定します。
目的のNFSサーバの設定を
/etc/exportsファイルで定義します。NFSサーバ上でバックアップデータの保存先とするディレクトリに、適切なマウントオプションが設定されていることを確認します。次に例を示します。/srv/nfs *([...],rw,no_root_squash,[...])
/srv/nfsをNFSサーバ上のバックアップデータへのパスに置き換えて、マウントオプションを調整します。バックアップデータにアクセスするには、no_root_squashの指定が必要になることが普通です。これは、rear mkbackupコマンドがrootとして実行されるためです。さまざまな
BACKUPパラメータ(設定ファイル/etc/rear/local.confに記述されています)を調整して、該当のNFSサーバ上にRearからファイルのバックアップを保存できるようにします。この例は、インストールしたシステムの/usr/share/rear/conf/examples/SLE12-*-example.confにあります。
例 24.2: サードパーティのバックアップツール(EMC NetWorkerなど)の使用 #
tarの代わりにサードパーティのバックアップツールを使用するには、Rear設定ファイルを適切に設定する必要があります。
以下は、EMC NetWorkerを使用する場合の設定例です。この設定スニペットを/etc/rear/local.confに追加し、それぞれのセットアップに応じて調整します。
BACKUP=NSR
OUTPUT=ISO
BACKUP_URL=nfs://host.example.com/path/to/rear/backup
OUTPUT_URL=nfs://host.example.com/path/to/rear/backup
NSRSERVER=backupserver.example.com
RETENTION_TIME="Month"24.3 復旧インストールシステムの作成 #
24.2項の説明に従ってRearを設定した後、Rear復旧インストーラを持つ復旧インストールシステムを作成したうえで、以下のコマンドを使用してファイルのバックアップを作成します。
rear -d -D mkbackup
このコマンドでは以下の手順が実行されます。
ターゲットシステムを分析し、ディスクのレイアウト(パーティション、ファイルシステム、マウントポイント)やブートローダに関する情報を中心として必要な情報を収集する。
最初の手順で収集した情報を使用して、ブート可能な復旧システムを作成する。ここで得られるRear復旧インストーラは、障害から保護する個々のシステム専用のインストーラです。このインストーラは、この固有のシステムを再作成する目的でのみ使用できます。
設定済みのバックアップツールを呼び出し、システムとユーザファイルをバックアップする。
24.4 復旧プロセスのテスト #
復旧システムを作成した後、運用マシンと同一のハードウェアを備えたテストマシンで復旧プロセスをテストします。24.1.4項 「Rearの要件」も参照してください。テストマシンの設定が適切で、メインマシンの代わりとして機能できることを確認します。
警告: 運用マシンと同一のハードウェア上での包括的なテスト
マシン上で障害復旧プロセスを十分にテストする必要があります。復旧手順を定期的にテストし、すべてが想定どおりに機能することを確認します。
手順 24.1: テストマシン上での障害復旧の実行 #
24.5 障害からの復旧 #
障害が発生した場合には、必要に応じて損傷したハードウェアを取り替えます。次に、手順 24.1の説明に従って、修復したマシンまたは元のシステムの代替として機能することをテスト済みの同一構成のマシンを使用して手順を進めます。
rear recoverコマンドでは以下の手順が実行されます。
回復プロセス #
ディスクのレイアウト(パーティション、ファイルシステム、およびマウントポイント)を復元する。
バックアップからシステムとユーザファイルを復元する。
ブートローダを復元する。
24.6 その他の情報 #
rearマニュアルページ/usr/share/doc/packages/rear/README