6.4. バックアップとリストアによるアクティブおよびパッシブな Satellite Server の障害復旧


障害復旧に備えるために、アクティブなプライマリーサーバーとパッシブなセカンダリーサーバーの 2 つの Satellite Server を設定できます。プライマリーサーバーの定期的なバックアップを設定します。プライマリーサーバーに障害が発生した場合は、セカンダリーサーバーでバックアップを復元して、新しいプライマリーサーバーとして使用できます。

6.4.1. 前提条件

アクティブ Satellite Server のバックアップを復元して、パッシブ Satellite Server を作成します。アクティブサーバーの定期的なバックアップを設定します。

手順

  1. アクティブな Satellite Server の定期的なオフラインバックアップのスケジュールを定義します。万が一のデータ損失に対する許容度とストレージオプションを考慮してください。頻繁にバックアップを取ると、障害発生時に失われるデータ量は少なくなりますが、バックアップには大量のストレージ容量が必要になります。Satellite バックアップのサイズは、「バックアップサイズの予測」 を参照してください。

    完全バックアップと増分バックアップを組み合わせることができます。定期的にバックアップが作成されるようにする cron ジョブの例は、「週次の完全バックアップの後に日次の増分バックアップを実行する例」 を参照してください。

  2. 定義したスケジュールに従って、アクティブな Satellite Server の定期的なオフラインバックアップを実行するようにスケジュールします。バックアップの実行方法は、11章Satellite Server および Capsule Server のバックアップ を参照してください。
  3. バックアップディレクトリーが暗号化され、安全な場所に定期的に同期されていることを確認します。デフォルトでは、Satellite はバックアップを /var/satellite-backup ディレクトリーに保存します。

    重要

    Satellite Server のバックアップには /root/ssl-build ディレクトリーの機密情報が含まれています。たとえば、ホスト名、SSH キー、リクエストファイル、SSL 証明書などが含まれます。バックアップを暗号化するか、安全な場所に移動すると、ホストの破損や不正アクセスのリスクを最小限に抑えることができます。

  4. パッシブ Satellite Server として機能するシステムに最新のバックアップを復元します。バックアップの復元は、12章バックアップからの Satellite Server または Capsule Server の復元 を参照してください。
  5. オプション: バックアップの復元を自動化して、パッシブサーバーを最新のバックアップで定期的に更新します。パッシブサーバーを定期的に復元すると、アクティブサーバーに障害が発生した場合の切り替え時間を短縮できます。

    バックアップを復元する頻度を検討してください。更新頻度が高いほど、データ損失の可能性は減りますが、インフラストラクチャーと自動化のコストは増加します。

  6. パッシブサーバーの電源をオフにします。アクティブサーバーの電源をオンのままにします。
  7. バックアップ保持ポリシーを定義します。保存するバックアップの数を検討してください。古いバックアップを定期的に削除すると、ストレージの使用量が最適化されます。

検証

  1. 定義したスケジュールに従って Satellite がバックアップを実行していることを確認します。
  2. 分離されたステージング環境でさらにテスト手順を実行します。

    1. アクティブサーバーが完全にダウンした状態を再現します。アクティブサーバーにアクセスできないようにするには、マシンの電源をオフにするか、サーバーが仮想マシン (VM) 上で実行されている場合は仮想マシンを停止するか、ファイアウォールを使用してマシンを分離します。
    2. アクティブサーバーの DNS レコードをパッシブサーバーの DNS レコードと切り替えます。
    3. テスト Satellite Server の機能を評価します。詳細は、「サービスのステータスの取得」 を参照してください。
    4. これらの検証チェックを定期的に実行してください。

アクティブな Satellite Server に障害が発生した場合は、パッシブなセカンダリーサーバーをアクティブ化します。

手順

  1. 障害が発生したアクティブサーバーの電源がオフになっており、バックアップがパッシブサーバーに同期されていないことを確認します。
  2. アクティブサーバーの DNS レコードをパッシブサーバーの DNS レコードと切り替えます。これにより、ホストは接続されたままになり、再登録する必要がなくなります。
  3. 新しいアクティブ Satellite Server の機能を評価します。詳細は、「サービスのステータスの取得」 を参照してください。

6.4.4. サービスのステータスの取得

Satellite は、一連のバックエンドサービスを使用します。トラブルシューティングを行うときに、Satellite サービスのステータスを確認できます。

手順

  • Satellite Web UI で、Administer > About に移動します。

    • Smart Proxies タブで、すべての Capsule のステータスを表示します。
    • Compute Resources タブで、接続されているコンピュートリソースプロバイダーのステータスを表示します。
    • Backend System Status テーブルで、すべてのバックエンドサービスのステータスを表示します。

CLI 手順

  • データベースと Satellite サービスから情報を取得します。

    $ hammer ping
    Copy to Clipboard Toggle word wrap
  • systemd で実行されているサービスのステータスを確認します。

    # satellite-maintain service status
    Copy to Clipboard Toggle word wrap

    詳細は、satellite-maintain service --help を実行して確認してください。

  • ヘルスチェックを実行します。

    $ satellite-maintain health check
    Copy to Clipboard Toggle word wrap

    詳細は、satellite-maintain health --help を実行して確認してください。

6.4.5. 週次の完全バックアップの後に日次の増分バックアップを実行する例

以下のスクリプトでは、日曜日に完全バックアップを実行した後に、増分バックアップを毎日実行します。増分バックアップが実行されるたびに、新しいサブディレクトリーが作成されます。このスクリプトでは、日次の cron ジョブが必要になります。

#!/bin/bash -e
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DESTINATION=/var/backup_directory
if [[ $(date +%w) == 0 ]]; then
  satellite-maintain backup offline --assumeyes $DESTINATION
else
  LAST=$(ls -td -- $DESTINATION/*/ | head -n 1)
  satellite-maintain backup offline --assumeyes --incremental "$LAST" $DESTINATION
fi
exit 0
Copy to Clipboard Toggle word wrap

satellite-maintain backup コマンドでは、PATH 内に /sbin ディレクトリーおよび /usr/sbin ディレクトリーを格納する必要があり、確認プロンプトをスキップするために --assumeyes オプションを使用することに注意してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat