システムのバックアップや復元機能がプラットフォームの設定 Playbook に統合されました。さらなる情報は、「クラスター環境のバックアップおよび復元」を参照してください。
注釈
復元するには、バックアップしたバージョンと同じバージョンに復元するようにしてください。ただし、プラットフォームインストールのバージョンをバックアップおよび復元する場合は、最新のマイナーバージョンを必ず使用するようにしてください。たとえば、現在使用しているプラットフォームバージョンが 2.0.x の場合は、最新の 2.0 のインストーラーのみを使用してください。
また、バックアップと復元は、現在のプラットフォームバージョンでサポートされている PostgreSQL バージョンで のみ 機能します。詳細は、『Ansible Automation Platform Installation and Reference Guide』の「ir_requirements」を参照してください。
プラットフォームの設定 Playbook は、プラットフォームインストーラーの tar ファイルを展開したパスから setup.sh として呼び出されます。このシェルは、インストール Playbook で使用したものと同じインベントリーファイルを使用します。設定スクリプトでは、以下の引数を指定してバックアップと復元を行うことができます。
-b: データベースのインストールではなくバックアップを実行します。
-r: データベースのインストールではなく復元を実行します。
root ユーザーとして、適切なパラメーターを指定して setup.sh と設定通りにプラットフォームのバックアップと復元を呼び出します。
root@localhost:~# ./setup.sh -b
root@localhost:~# ./setup.sh -r
バックアップファイルは、setup.sh スクリプトが存在するパスと同じところに作成されます。以下の EXTRA_VARS を指定すると変更できます。
root@localhost:~# ./setup.sh -e 'backup_dest=/path/to/backup_dir/' -b
以下の例に記載されているように、EXTRA_VARS でデフォルト以外のパスを指定しない限り、デフォルトの復元パスが使用されます。
root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r
オプションで、設定スクリプトに引数として渡すことで使用したインベントリーファイルを上書きすることができます。
setup.sh -i <inventory file>
setup.sh の設定 Playbook が含まれる install.yml ファイルの他に、 バックアップや復元用の backup.yml と restore.yml ファイルもあります。
これらの Playbook にはバックアップと復元の 2 つの機能があります。
システム全体のバックアップは以下をバックアップします。
データベース
SECRET_KEY ファイル
システム毎のバックアップには以下が含まれます。
カスタムのユーザー設定ファイル
手動のプロジェクト
復元では、バックアップを作成したファイルおよびデータを、コントローラーの新規インストールしたまたは作業中の 2 つ目のインスタンスに復元します。
システムを復元する際、インストーラーはバックアップファイルが存在するかどうか確認してから復元を開始します。バックアップファイルがない場合には、復元に失敗します。
注釈
ホストファイル内で SSH キーまたはユーザー/パスワード変数を指定して、コントローラーホストが正しく設定されており、そのユーザーに sudo アクセスが設定されていることを確認します。
ディスクの容量: 設定ファイル、キー、その他の関連ファイル、およびプラットフォームシステム設定のデータベースをバックアップするために必要な容量があるように、ディスク領域の要件を確認します。
システムの認証情報: ローカルデータベースまたはリモートデータベースを使用している場合には必要なシステムの認証情報があることを確認します。ローカルシステムでは、認証情報の設定方法によっては root または sudo アクセスが必要です。リモートシステムでは、バックアップまたは復元しようとしているリモートシステムへのアクセス権を付与するために異なる認証情報が必要になる場合があります。
プラットフォームインストールのバージョンをバックアップおよび復元する場合は、最新のマイナーバージョンを必ず使用するようにしてください。たとえば、現在使用しているプラットフォームのバージョンが 2.0.x の場合は、2.0 のインストーラーのみを使用してください。
setup.sh を使用して、デフォルトの復元ファイルパス /var/lib/awx から、復元を行う場合には、依然として -r を指定して復元する必要がありますが、それ以上引数を受け入れなくなります。デフォルト以外の復元パスを指定する必要がある場合には、ユーザーは追加変数としてこれを指定する必要があります (root@localhost:~# ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r)。
バックアップファイルを setup.sh インストーラーと同じディレクトリーに配置している場合は、復元 Playbook は自動的に復元ファイルの場所を特定します。この場合には、バックアップファイルの場所を指定するときに、restore_backup_file の追加変数を使用する必要はありません。
クラスター環境のバックアップおよび復元の手順は、このセクションで説明されている留意事項を以外は、単一インストールとほぼ同じです。
新規クラスターに復元する場合は、データベースにアクセスする際にはそれぞれのクラスター間で競合状態になる可能性があるので、以前のクラスターをシャットダウンしてから続行するようにしてください。
ノードごとのバックアップは、バックアップと同じホスト名のノードのみに復元されます。
既存のクラスターに復元する場合には、復元には以下が含まれます。
PostgreSQL データベースのダンプ
(データベースダンプに含まれる) UI アーティファクト
(``/etc/tower``から取り込む) コントローラーの設定
コントローラーのシークレットキー
手動のプロジェクト
バックアップを別のインスタンスまたはクラスターに復元する場合は、/etc/tower の下の手動プロジェクトとカスタム設定が保持されます。ジョブ出力とジョブイベントはデータベースに保存されるため、影響を受けません。
復元プロセスは、復元の前に存在するインスタンスグループを変更しません (また、新規インスタンスグループの導入もありません)。複数のインスタンスグループに関連づけられていたコントローラーリソースを復元した後、新しいコントローラークラスターに存在するインスタンスグループに再度割り当てる必要があります。