31 ReaR (Relax-and-Recover)による障害復旧 #
Relax-and-Recover (「ReaR」)はシステム管理者が使用する障害復旧フレームワークです。Rearは、障害発生時に保護対象となる特定の運用環境に合わせて調整する必要があるBashスクリプトのコレクションです。
障害復旧ソリューションはすぐには機能しません。したがって、障害が発生する前に準備をする必要があります。
31.1 概念の概要 #
以降のセクションでは、障害復旧の一般的な概念を述べ、ReaRを使用した復旧を実現するために必要となる基本的な手順について説明します。また、ReaRの要件に関する指針、知っておくべき制限事項、およびシナリオとバックアップツールについても紹介します。
31.1.1 障害復旧プランの作成 #
最悪のシナリオが発生する前に、ITインフラストラクチャに重大なリスクがあるかどうかの分析、予算の見積もり、障害復旧プランの作成などの対応策を講じます。障害復旧プランを手元に用意していない場合は、以下の手順ごとに情報を入手します。
リスクの分析. インフラの確かなリスク分析を実施します。可能性のあるすべての脅威を一覧表示し、深刻度を評価します。これらの脅威が発生する可能性を判断し、優先順位を設定します。可能性と影響の簡単な分類を使用することを推奨します。
予算のプランニング. 分析結果には、どのリスクが耐えうるもので、どれがビジネスにとって致命的であるかを全般的に示します。リスクを最小限にする方法およびそれに要するコストを自問して検討します。会社の規模に応じて、IT予算全体の2～15%を障害復旧に使用します。
障害復旧プランの作成. チェックリストの作成、手順のテスト、優先順位の設定と割り当て、ITインフラのインベントリ調査を行います。インフラのサービスが失敗した際、問題に対処する方法を定義します。
テスト. 念入りなプランを定義したら、それをテストします。最低でも1年に1度テストします。ご使用のメインITインフラと同じテストハードウェアを使用します。
31.1.2 障害復旧とは #
運用環境に存在するシステムが、ハードウェアの損傷、誤設定、ソフトウェア上の問題など、原因がどのようなものであっても破損した場合は、システムを再作成する必要があります。再作成は、同じハードウェア上または互換性のある代替ハードウェア上で実行できます。バックアップからファイルを復元するだけでは、システムを再作成することにはなりません。システムの再作成では、パーティション、ファイルシステム、マウントポイントの面からのシステムのストレージ作成や、ブートローダの再インストールなどの作業も必要になります。
31.1.3 ReaRによる障害復旧 #
システムが正常に稼働しているときに、ファイルのバックアップを作成し、復旧メディア上に復旧システムを作成します。復旧システムには、復旧インストーラが収められています。
システムが破損した場合は、損傷したハードウェアを必要に応じて交換し、復旧メディアから復旧システムをブートして復旧インストーラを起動します。復旧インストーラはシステムを再作成します。まず、ストレージにパーティション、ファイルシステム、マウントポイントを作成し、続いてバックアップからファイルを復元します。最後に、ブートローダを再インストールします。
31.1.4 ReaRの要件 #
ReaRを使用するには、運用環境を実行するマシンおよびそれと同一のテストマシンが必要です。つまり、同一のシステムが2台以上必要になります。ここでいう「同一」とは、たとえば、ネットワークカードを、同じカーネルドライバを使用する他のネットワークカードに置き換えることができるということです。
運用環境のドライバと同じドライバを使用していないハードウェアコンポーネントは、ReaRでは同一のコンポーネントとはみなされません。
31.1.5 ReaRバージョンの更新 #
SUSE Linux Enterprise High Availability 15 SP7で使用できるReaRのバージョンを確認するには、次のコマンドを実行します。
#zypper search --type package --verbose rear
バグ修正、非互換性、および他の問題に関する情報はすべて、パッケージの変更ログで検索できます。障害復旧手順を再検証する必要がある場合は、ReaRのより最新のパッケージバージョンも確認することをお勧めします。
ReaRには次の問題がありますので注意してください。
UEFIシステムで障害復旧を許可するには、ヘルパーツール
/usr/bin/xorrisofsを提供するパッケージxorrisoが必要です。このヘルパーツールは、UEFIブート可能ReaR復旧システムISOイメージの作成に使用されます。特定のReaRバージョンによる障害復旧手順をテスト済みで、その手順が十分に機能しているのであれば、ReaRを更新しないでください。ReaRパッケージをそのまま保持し、障害復旧手法を変更しないようにします。
ReaRの各バージョン更新は、インストール済みのバージョンが誤って別のバージョンに置き換えられることがないよう、相互に意図的に衝突する別個のパッケージとして提供されています。
次の場合に、既存の障害復旧手順を再検証する必要があります。
ReaRバージョンの更新ごとに。
ReaRを手動で更新する場合。
ReaRで使用されるソフトウェアごとに。
parted、btrfsなどの低レベルのシステムコンポーネントを更新する場合。
31.1.6 Btrfsに伴う制限事項 #
Btrfsを使用する場合は次の制限事項が発生します。
- システムにサブボリュームは存在しても、スナップショットのサブボリュームが存在しない場合
ReaRバージョン1.17.2.a以上が必要です。このバージョンは、スナップショットのサブボリュームが存在しない「通常の」Btrfsサブボリューム構造の再作成をサポートしています。
- システムにスナップショットのサブボリュームが存在する場合
- 警告
ファイルベースのバックアップソフトウェアでは、Btrfsスナップショットのサブボリュームを通常どおりにはバックアップできず、復元することもできません。
Btrfsにはコピーオンライト機能があることから、Btrfsファイルシステム上にある最近のスナップショットサブボリュームはディスク容量をほとんど必要としません。一方、ファイルベースのバックアップソフトウェアを使用すると、これらのファイルは完全なファイルとしてバックアップされます。最終的に、これらのファイルはその本来のファイルサイズで2回バックアップされることになります。したがって、元のシステム上に以前に存在していたときと同じ状態にスナップショットを復元することができません。
- SLEシステムに適合するReaR設定が必要な場合
たとえば、SLE12 GA、SLE12 SP1、およびSLE12 SP2の設定には、いくつかの不適合Btrfsのデフォルト構造があります。そのため、適合するReaR設定ファイルを使用することはたいへん重要です。サンプルファイル
/usr/share/rear/conf/examples/SLE12*-btrfs-example.confを参照してください 。
31.1.7 シナリオとバックアップのツール #
ReaRでは、ハードディスク、フラッシュディスク、DVD/CD-RなどのローカルメディアからのブートやPXEを介したブートが可能な障害復旧システム(システム固有の復旧インストーラなど)を作成できます。バックアップデータは、例 31.1に説明があるNFSなどのネットワークファイルシステムに保存できます。
ReaRは、ファイルのバックアップに取って代わるツールではなく、それを補完するツールです。ReaRは、汎用的なtarコマンドのほか、いくつかのサードパーティのバックアップツールをデフォルトでサポートしています。このようなバックアップツールとして、Tivoli Storage Manager、QNetix Galaxy、Symantec NetBackup、EMC NetWorker、HP DataProtectorなどがあります。バックアップツールとしてEMC NetWorkerを使用したReaRの設定例については例 31.3を参照してください。
31.1.8 基本手順 #
障害発生時にReaRを使用して効果的な復旧を実現するには、以下の基本手順を実行する必要があります。
- ReaRおよびバックアップソリューションのセットアップ
この手順では、ReaR設定ファイルの編集、Bashスクリプトの調整、使用するバックアップソリューションの設定などのタスクを実行します。
- 復旧インストールシステムの作成
保護対象のシステムが稼働しているときに、ファイルのバックアップを作成し、システム固有のReaR復旧インストーラを含む復旧システムを生成します。
tarを使用した基本的なバックアップの場合 、rear mkbackupコマンドを使用して、バックアップと復旧システムの両方を作成します。サードパーティのバックアップツールの場合は、
rear mkrescueコマンドを使用して復旧システムを作成し、サードパーティのバックアップツールを使用してバックアップを作成します。- 復旧プロセスのテスト
ReaRを使用して障害復旧メディアを作成した場合は、その障害復旧プロセスを必ず十分にテストしておくようにします。ここでは、運用環境を構成するハードウェアと同一のハードウェアを備えたテストマシンの使用が不可欠です。詳細については、31.1.4項 「ReaRの要件」を参照してください。
- 障害からの復旧
障害が発生した場合は、必要に応じて損傷したハードウェアを交換します。続いて、ReaR復旧システムをブートし、
rear recoverコマンドで復旧インストーラを起動します。
31.2 ReaRおよびバックアップソリューションのセットアップ #
ReaRの最新バージョンをインストールするには、次のコマンドを実行します。
#zypper install rear
以前のバージョンのReaRをインストールする必要がある場合は、パッケージバージョンを指定できます。次に例を示します。
#zypper install rear23a
ReaRを設定するには、ReaR設定ファイル/etc/rear/local.confに設定を追加します。さらに、ReaRフレームワークを構成するBashスクリプトも必要に応じて編集します。特に、ReaRが実行する以下のタスクの定義が必要です。
ファイルをバックアップする方法および障害復旧システムを作成して保存する方法. これは、
/etc/rear/local.confで設定する必要があります。再作成を必要とする対象(パーティション、ファイルシステム、マウントポイントなど)。. これは
/etc/rear/local.confで定義できます。標準とは異なるシステムを再作成するには、Bashスクリプトの拡張が必要になることがあります。復旧プロセスの仕組み. ReaRで復旧インストーラを生成する方法の変更やReaR復旧インストーラによる実行タスクとの適合を可能にするには、Bashスクリプトの編集が必要です。
すべてのReaR設定変数およびそのデフォルト値は/usr/share/rear/conf/default.confで説明されています。
以下に、便利な設定オプションの例をいくつか示します。/usr/share/rear/conf/examples/サブディレクトリには、別のシナリオのサンプルファイルもあります。これらを使用して、/etc/rear/local.confファイルを作成できます。
SUSE Linux Enterprise Server 15 SP7の『管理ガイド』の説明に従って、YaSTを使用してNFSサーバを設定します。
目的のNFSサーバの設定を
/etc/exportsファイルで定義します。NFSサーバ上のディレクトリに適切なマウントオプションが設定されていることを確認します。たとえば、rear mkbackupコマンドがrootとして実行されるので、no_root_squashが必要になる場合があります。詳細については、man exportsを参照してください。さまざまな
BACKUPパラメータ(設定ファイル/etc/rear/local.confに記述されています)を調整して、該当のNFSサーバ上にReaRからファイルのバックアップを保存できるようにします。この例は、インストールしたシステムの/usr/share/rear/conf/examples/SLE*-example.confにあります。
tarによるBtrfsサブボリュームのバックアップ #
Btrfsはサブボリュームを使用して設定しますが、tarでは--one-file-systemオプションを使用してバックアップを作成するため、サブボリュームは除外されます。したがって、サブボリュームのマウントポイントをReaR設定に明示的に含める必要があります。
この設定スニペットを/etc/rear/local.confに追加し、それぞれのセットアップに応じて調整します。詳細情報と追加オプションについては、/usr/share/rear/conf/examples/SLE*-btrfs-example.confにあるサンプルファイルを参照してください。
OUTPUT=ISO BACKUP=NETFS BACKUP_URL=nfs://host.example.com/path/to/rear/backup BACKUP_PROG_INCLUDE=( /root /boot/grub2/i386-pc /tmp /opt /var /boot/grub2/x86_64-efi /srv /usr/local )
BACKUP_PROG_INCLUDEのマウントポイント次のコマンドを実行して、特定のシステム上のサブボリュームのマウントポイントを確認できます。
#findmnt -n -r -o TARGET -t btrfs | grep -v '^/$' | egrep -v 'snapshots|crash'
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"
サポートされているサードパーティのバックアップツールの詳細については、man rearのBACKUP SOFTWARE INTEGRATIONのセクションを参照してください。
デフォルトでは、ReaRはマルチパスデバイス上のファイルシステムを無視します。ReaRでは、マルチパスデバイスはローカルシステムの一部ではなくリモートストレージ上にあると想定するためです。ReaRでこれらのファイルシステムを含めるには、次の行を/etc/rear/local.confに追加します。
AUTOEXCLUDE_MULTIPATH=n
システムがUEFIブートローダでブートする場合は、追加の設定が必要です。
パッケージxorrisoをインストールします:。
#zypper install xorriso次の行を
/etc/rear/local.confに追加します。ISO_MKISOFS_BIN="/usr/bin/xorrisofs"
システムがUEFIセキュアブートで起動する場合は、次の行も追加する必要があります。
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/sles/shim.efi"
UEFIのReaR設定変数の詳細については、/usr/share/rear/conf/default.confファイルを参照してください。
31.3 復旧インストールシステムの作成 #
31.2項の説明に従ってReaRを設定した後、ReaR復旧インストーラを持つ復旧インストールシステムを作成した上で、ファイルのバックアップを作成します。
tarバックアップによる復旧システムの作成 #
rear mkbackupコマンドを実行します。
#rear -d -D mkbackup
このコマンドは以下のステップを実行します。
ターゲットシステムを分析し、ディスクのレイアウト(パーティション、ファイルシステム、マウントポイント)やブートローダに関する情報を中心として必要な情報を収集する。
最初の手順で収集した情報を使用して、ブート可能な復旧システムを作成する。ここで得られるReaR復旧インストーラは、障害から保護する個々のシステム専用のインストーラです。このインストーラは、この固有のシステムを再作成する目的でのみ使用できます。
内部バックアップツールを呼び出し、システムファイルとユーザファイルをバックアップする。
rear mkrescueコマンドを実行します。#rear -d -D mkrescueこのコマンドはターゲットを分析して復旧システムを作成しますが、ファイルのバックアップは作成しません。
サードパーティのバックアップ ツールを使用してファイルのバックアップを作成します。
31.4 復旧プロセスのテスト #
復旧システムを作成した後、運用マシンと同一のハードウェアを備えたテストマシンで復旧プロセスをテストします。31.1.4項 「ReaRの要件」も参照してください。テストマシンの設定が適切で、メインマシンの代わりとして機能できることを確認します。
マシン上で障害復旧プロセスを十分にテストする必要があります。復旧手順を定期的にテストし、すべてが想定どおりに機能することを確認します。
31.5 障害からの復旧 #
障害が発生した場合には、必要に応じて損傷したハードウェアを取り替えます。次に、手順 31.1の説明に従って、修復したマシンまたは元のシステムの代替として機能することをテスト済みの同一構成のマシンを使用して手順を進めます。
rear recoverコマンドは次の手順を実行します。
ディスクのレイアウト(パーティション、ファイルシステム、およびマウントポイント)を復元する。
バックアップからシステムとユーザファイルを復元する。
ブートローダを復元する。
31.6 詳細情報 #
rearのマニュアルページ/usr/share/doc/packages/rear/