目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availabilityのドキュメント / 管理ガイド / ストレージとデータレプリケーション / ReaR (Relax-and-Recover)による障害復旧
適用項目 SUSE Linux Enterprise High Availability 15 SP6

27 ReaR (Relax-and-Recover)による障害復旧

Relax-and-Recover (ReaR)はシステム管理者が使用する障害復旧フレームワークです。Rearは、障害発生時に保護対象となる特定の運用環境に合わせて調整する必要があるBashスクリプトのコレクションです。

障害復旧ソリューションはすぐには機能しません。したがって、障害が発生する「前に」準備をする必要があります。

27.1 概念の概要

以降のセクションでは、障害復旧の一般的な概念を述べ、ReaRを使用した復旧を実現するために必要となる基本的な手順について説明します。また、ReaRの要件に関する指針、知っておくべき制限事項、およびシナリオとバックアップツールについても紹介します。

27.1.1 障害復旧プランの作成

最悪のシナリオが発生する前に、ITインフラストラクチャに重大なリスクがあるかどうかの分析、予算の見積もり、障害復旧プランの作成などの対応策を講じます。障害復旧プランを手元に用意していない場合は、以下の手順ごとに情報を入手します。

  • リスクの分析.  インフラの確かなリスク分析を実施します。可能性のあるすべての脅威を一覧表示し、深刻度を評価します。これらの脅威が発生する可能性を判断し、優先順位を設定します。可能性と影響の簡単な分類を使用することを推奨します。

  • 予算のプランニング.  分析結果には、どのリスクが耐えうるもので、どれがビジネスにとって致命的であるかを全般的に示します。リスクを最小限にする方法およびそれに要するコストを自問して検討します。会社の規模に応じて、IT予算全体の2~15%を障害復旧に使用します。

  • 障害復旧プランの作成.  チェックリストの作成、手順のテスト、優先順位の設定と割り当て、ITインフラのインベントリ調査を行います。インフラのサービスが失敗した際、問題に対処する方法を定義します。

  • テスト.  念入りなプランを定義したら、それをテストします。最低でも1年に1度テストします。ご使用のメインITインフラと同じテストハードウェアを使用します。

27.1.2 障害復旧とは

運用環境に存在するシステムが、ハードウェアの損傷、誤設定、ソフトウェア上の問題など、原因がどのようなものであっても破損した場合は、システムを再作成する必要があります。再作成は、同じハードウェア上または互換性のある代替ハードウェア上で実行できます。バックアップからファイルを復元するだけでは、システムを再作成することにはなりません。システムの再作成では、パーティション、ファイルシステム、マウントポイントの面からのシステムのストレージ作成や、ブートローダの再インストールなどの作業も必要になります。

27.1.3 ReaRによる障害復旧

システムが正常に稼働しているときに、ファイルのバックアップを作成し、復旧メディア上に復旧システムを作成します。復旧システムには、復旧インストーラが収められています。

システムが破損した場合は、損傷したハードウェアを必要に応じて交換し、復旧メディアから復旧システムをブートして復旧インストーラを起動します。復旧インストーラによるシステムの再作成では、まず、ストレージにパーティション、ファイルシステム、マウントポイントを作成し、続いてバックアップからファイルを復元します。最後に、ブートローダを再インストールします。

27.1.4 ReaRの要件

ReaRを使用するには、運用環境を実行するマシンおよびそれと同一のテストマシンが必要です。つまり、同一のシステムが2台以上必要になります。ここでいう同一とは、たとえば、ネットワークカードを、同じカーネルドライバを使用する他のネットワークカードに置き換えることができるということです。

警告
警告: 同一のドライバが必要

運用環境のドライバと同じドライバを使用していないハードウェアコンポーネントは、ReaRでは同一のコンポーネントとはみなされません。

27.1.5 ReaRバージョンの更新

SUSE Linux Enterprise High Availability 15 SP6には、パッケージrear23aによって提供されるReaRバージョン2.3が付属しています。

注記
注記: 変更ログでの重要な情報の検索

バグ修正、非互換性、および他の問題に関する情報はすべて、パッケージの変更ログで検索できます。障害復旧手順を再検証する必要がある場合は、ReaRのより最新のパッケージバージョンも確認することをお勧めします。

ReaRには次の問題がありますので注意してください。

  • UEFIシステムで障害復旧を許可するには、少なくともReaRバージョン 1.18.aおよびパッケージebisoが必要です。このバージョンのみが新しいヘルパーツール/usr/bin/ebisoをサポートします。このヘルパーツールは、UEFIブート可能ReaRシステムISOイメージの作成に使用されます。

  • 特定のReaRバージョンによる障害復旧手順をテスト済みで、その手順が十分に機能しているのであれば、ReaRを更新しないでください。ReaRパッケージをそのまま保持し、障害復旧手法を変更しないようにします。

  • ReaRの各バージョン更新は、インストール済みのバージョンが誤って別のバージョンに置き換えられることがないよう、相互に意図的に衝突する別個のパッケージとして提供されています。

次の場合に、既存の障害復旧手順を再検証する必要があります。

  • ReaRバージョンの更新ごとに。

  • ReaRを手動で更新する場合。

  • ReaRで使用されるソフトウェアごとに。

  • partedbtrfsなどの低レベルのシステムコンポーネントを更新する場合。

27.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を参照してください 。

27.1.7 シナリオとバックアップのツール

ReaRでは、ハードディスク、フラッシュディスク、DVD/CD-RなどのローカルメディアからのブートやPXEを介したブートが可能な障害復旧システム(システム固有の復旧インストーラなど)を作成できます。バックアップデータは、例 27.1に説明があるNFSなどのネットワークファイルシステムに保存できます。

ReaRは、ファイルのバックアップに取って代わるツールではなく、それを補完するツールです。ReaRは、汎用的なtarコマンドのほか、いくつかのサードパーティのバックアップツールをデフォルトでサポートしています。このようなバックアップツールとして、Tivoli Storage Manager、QNetix Galaxy、Symantec NetBackup、EMC NetWorker、HP DataProtectorなどがあります。バックアップツールとしてEMC NetWorkerを使用したReaRの設定例については例 27.2を参照してください。

27.1.8 基本手順

障害発生時にReaRを使用して効果的な復旧を実現するには、以下の基本手順を実行する必要があります。

ReaRおよびバックアップソリューションのセットアップ

この手順では、ReaR設定ファイルの編集、Bashスクリプトの調整、使用するバックアップソリューションの設定などのタスクを実行します。

復旧インストールシステムの作成

保護対象のシステムが稼働しているときに、rear mkbackupコマンドを使用して、ファイルのバックアップを作成し、システム固有のReaR復旧インストーラを含む復旧システムを生成します。

復旧プロセスのテスト

ReaRを使用して障害復旧メディアを作成した場合は、その障害復旧プロセスを必ず十分にテストしておくようにします。ここでは、運用環境を構成するハードウェアと「同一の」ハードウェアを備えたテストマシンの使用が不可欠です。詳細については、27.1.4項 「ReaRの要件」を参照してください。

障害からの復旧

障害が発生した場合は、必要に応じて損傷したハードウェアを交換します。続いて、ReaR復旧システムをブートし、rear recoverコマンドで復旧インストーラを起動します。

27.2 ReaRおよびバックアップソリューションのセットアップ

ReaRをセットアップするには、少なくともReaR設定ファイル/etc/rear/local.confを編集する必要があります。さらに、ReaRフレームワークを構成するBashスクリプトも必要に応じて編集します。

特に、ReaRが実行する以下のタスクの定義が必要です。

  • システムをUEFIを使用してブートする場合.  システムがUEFIブートローダでブートする場合は、パッケージebisoをインストールし、次の行を/etc/rear/local.confに追加します。

    ISO_MKISOFS_BIN="/usr/bin/ebiso"

    システムがUEFIセキュアブートで起動する場合は、次の行も追加する必要があります。

    SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/BOOT/shim.efi"

    UEFIのReaR設定変数の詳細については、/usr/share/rear/conf/default.confファイルを参照してください。

  • ファイルをバックアップする方法および障害復旧システムを作成して保存する方法.  これは、/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ファイルに貼り付けます。特定の構成向けに利用できる変数の概要などが含まれるため、元のサンプル設定ファイルをそのまま使用しないでください。

例 27.1: NFSサーバを使用したファイルバックアップの保存

ReaRはさまざまなシナリオで使用できます。以下の例では、ファイルのバックアップを収めるストレージとしてNFSサーバを使用しています。

  1. Administration Guide for SUSE Linux Enterprise Server 15 SP6で説明されているように、YaSTを使用してNFSサーバを設定します。

  2. 目的のNFSサーバの設定を/etc/exportsファイルで定義します。NFSサーバ上でバックアップデータの保存先とするディレクトリに、適切なマウントオプションが設定されていることを確認します。例:

    /srv/nfs *([...],rw,no_root_squash,[...])

    /srv/nfsをNFSサーバ上のバックアップデータへのパスに置き換えて、マウントオプションを調整します。no_root_squashコマンドがrear mkbackupとして実行されるので、rootが必要になる場合があります。

  3. さまざまなBACKUPパラメータ(設定ファイル/etc/rear/local.confに記述されています)を調整して、該当のNFSサーバ上にReaRからファイルのバックアップを保存できるようにします。この例は、インストールしたシステムの/usr/share/rear/conf/examples/SLE*-example.confにあります。

例 27.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"

27.3 復旧インストールシステムの作成

27.2項の説明に従ってReaRを設定した後、ReaR復旧インストーラを持つ復旧インストールシステムを作成した上で、以下のコマンドを使用してファイルのバックアップを作成します。

rear -d -D mkbackup

このコマンドでは以下の手順が実行されます。

  1. ターゲットシステムを分析し、ディスクのレイアウト(パーティション、ファイルシステム、マウントポイント)やブートローダに関する情報を中心として必要な情報を収集する。

  2. 最初の手順で収集した情報を使用して、ブート可能な復旧システムを作成する。ここで得られるReaR復旧インストーラは、障害から保護する個々のシステム「専用」のインストーラです。このインストーラは、この固有のシステムを再作成する目的でのみ使用できます。

  3. 設定済みのバックアップツールを呼び出し、システムとユーザファイルをバックアップする。

27.4 復旧プロセスのテスト

復旧システムを作成した後、運用マシンと同一のハードウェアを備えたテストマシンで復旧プロセスをテストします。関連項目 27.1.4項 「ReaRの要件」.テストマシンの設定が適切で、メインマシンの代わりとして機能できることを確認します。

警告
警告: 運用マシンと同一のハードウェア上での包括的なテスト

マシン上で障害復旧プロセスを十分にテストする必要があります。復旧手順を定期的にテストし、すべてが想定どおりに機能することを確認します。

手順 27.1: テストマシン上での障害復旧の実行
  1. 27.3項で作成した復旧システムをDVDやCDに書き込み、復旧メディアを作成します。PXEを介したネットワークブートとすることもできます。

  2. 復旧メディアからテストマシンをブートします。

  3. メニューからRecover (復旧)を選択します。

  4. rootとしてログインします(パスワードは必要なし)。

  5. 次のコマンドを入力して復旧インストーラを起動します。

    rear -d -D recover

    このプロセスでReaRが実行する手順の詳細については回復プロセスを参照してください。

  6. 復旧プロセスが完了した後、システムが正常に再作成されたかどうか、および運用環境で元のシステムの代替として機能するかどうかを確認します。

27.5 障害からの復旧

障害が発生した場合には、必要に応じて損傷したハードウェアを取り替えます。次に、手順 27.1の説明に従って、修復したマシンまたは元のシステムの代替として機能することをテスト済みの同一構成のマシンを使用して手順を進めます。

rear recoverコマンドは次の手順を実行します。

回復プロセス
  1. ディスクのレイアウト(パーティション、ファイルシステム、およびマウントポイント)を復元する。

  2. バックアップからシステムとユーザファイルを復元する。

  3. ブートローダを復元する。

27.6 詳細の参照先