Azure Database for PostgreSQL のバックアップを復元する
この記事では、Azure Backup によってバックアップされた Azure PostgreSQL サーバーにデータベースを復元する方法について説明します。
ターゲット サーバーに対する適切な一連のアクセス許可がサービスにある場合は、コンテナーと同じリージョン内の異なるまたは同じサブスクリプションの任意の Azure PostgreSQL サーバーにデータベースを復元できます。
Azure PostgreSQL データベースを復元する
[バックアップ コンテナー] ->[バックアップ インスタンス] に移動します。 データベースを選択し、 [復元] をクリックします。
また、バックアップ センターからこのページに移動することもできます。
[復元ポイントの選択] ページで、選択したバックアップ インスタンスで利用できるすべての完全バックアップの一覧からいずれかの復旧ポイントを選択します。 既定では、最新の復旧ポイントが選択されます。
復元ポイントがアーカイブ層にある場合は、復元する前に復旧ポイントをリハイドレートする必要があります。 リハイドレートに必要な次の追加パラメーターを指定します。
- Rehydration priority (リハイドレートの優先順位): 既定値は Standard です。
- Rehydration duration (リハイドレート期間): 最大リハイドレート期間は 30 日間、最小リハイドレート期間は 10 日間です。 既定値は 15 日です。 復旧ポイントは、この期間、バックアップ データ ストアに格納されます。
[Restore parameters](復元のパラメーター) ページで、 [Restore as Database](データベースとして復元) と [Restore as Files](ファイルとして復元) のどちらかの復元タイプを選択します。
[Restore as Database](データベースとして復元)
ターゲット サーバーは、ソース サーバーと同じにすることができます。 ただし、元のデータベースの上書きはサポートされていません。 すべてのサブスクリプションのサーバーから、コンテナーと同じリージョン内のサーバーを選択できます。
[Select key vault and the secret](キー コンテナーとシークレットの選択) ボックスの一覧から、ターゲット サーバーに接続するための資格情報が格納されるコンテナーを選択します。
[レビューと復元] を選択すると検証がトリガーされ、サービスにターゲット サーバーに対する復元のアクセス許可があるか確認されます。 これらのアクセス許可は手動で付与する必要があります。
重要
キー コンテナーを介して資格情報が選択された DB ユーザーは、復元されたデータベースに対するすべての特権を持ち、既存の DB ユーザー境界がすべてオーバーライドされます。 たとえば、バックアップされたデータベースに DB ユーザー固有のアクセス許可または制約がある場合 (DB ユーザー A は少数のテーブルにアクセスでき、DB ユーザー B は他の少数のテーブルにアクセスできる、など)、このようなアクセス許可は復元後に保持されません。 これらのアクセス許可を保持する場合は、ファイルとして復元を使用し、関連するスイッチを指定して pg_restore コマンドを使用します。
[Restore as Files: Dump the backup files to the target storage account (blobs).](ファイルとして復元: バックアップ ファイルをターゲット ストレージ アカウント (BLOB) にダンプします。)
すべてのサブスクリプションのストレージ アカウントから、コンテナーと同じリージョン内のストレージ アカウントを選択できます。
- [Select the target container](ターゲット コンテナーの選択) ボックスの一覧から、選択したストレージ アカウントについてフィルターで抽出されたコンテナーのいずれかを選択します。
- [レビューと復元] を選択して、ターゲット ストレージ アカウントに対する復元のアクセス許可がバックアップ サービスにあるかどうかをチェックするための検証をトリガーします。
Note
Azure Database for PostgreSQL のアーカイブ サポートは、限定パブリック プレビュー段階です。
ターゲット ストレージ アカウントに対するアクセス許可を復元する
Azure portal を使用して、ストレージ アカウント コンテナーにアクセスするためのアクセス許可をバックアップ コンテナーの MSI に割り当てます。
[ストレージ アカウント] ->[アクセス制御] ->[ロールの割り当ての追加] にアクセスします。
バックアップ コンテナーの MSI に対する [ストレージ BLOB データ共同作成者] ロールを [ロール] ボックスの一覧から選択します。
または、Azure CLI で az role assignment create コマンドを使用して、復元先の特定のコンテナーに詳細なアクセス許可を付与します。
az role assignment create --assignee $VaultMSI_AppId --role "Storage Blob Data Contributor" --scope $id
assignee パラメーターをコンテナーの MSI のアプリケーション ID に置き換え、scope パラメーターで特定のコンテナーを参照します。 コンテナー MSI のアプリケーション ID を取得するには、 [アプリケーションの種類] で [すべてのアプリケーション] を選択します。 コンテナー名を検索し、アプリケーション ID をコピーします。
リージョンをまたぐデータベースの復元
復元オプションの 1 つとして、リージョンをまたぐ復元 (CRR) を使用すると、Azure Database for PostgreSQL サーバーをセカンダリ リージョン (Azure ペア リージョン) に復元できます。
考慮事項
- この機能の使用を開始するには、「開始する前に」のセクションを参照してください。
- リージョンをまたぐ復元が有効になっているかどうかを確認するには、「リージョンをまたぐ復元の構成」セクションを参照してください。
セカンダリ リージョンのバックアップ インスタンスを表示する
CRR が有効になっている場合は、セカンダリ リージョンのバックアップ項目を表示できます。
Azure portal から、[バックアップ コンテナー] > [バックアップ インスタンス] に移動します。
フィルターを Instance Region == Secondary Region として選択します。
Note
CRR 機能をサポートするバックアップ管理の種類のみがリスト表示されます。 現時点では、PostgreSQL サーバーのセカンダリ リージョンへのプライマリ リージョン データの復元のみがサポートされています。
セカンダリ リージョンに復元する
セカンダリ リージョンの復元エクスペリエンスは、プライマリ リージョンの復元と似ています。
[復元の構成] ペインで復元の詳細を構成するときに、セカンダリ リージョンのパラメーターのみを指定するように求められます。 したがって、セカンダリー リージョンに既にコンテナーが存在し、PosgreSQL サーバーがセカンダリ リージョンのコンテナーに登録されている必要があります。
次のステップを実行します。
[バックアップ インスタンス名] を選択して詳細を表示します。
[セカンダリ リージョンへの復元] を選択します。
復元ポイント、リージョン、およびリソース グループを選択します。
[復元] を選択します。
Note
- データ転送フェーズで復元がトリガーされた後には、復元ジョブを取り消すことができません。
- リージョンをまたぐ復元操作を実行するために必要なロールまたはアクセス レベルは、サブスクリプションの "バックアップ オペレーター" ロール、ソースおよびターゲットの仮想マシンでの "共同作成者 (書き込み)" アクセスです。 バックアップ ジョブを表示するため、サブスクリプションで必要な最小限のアクセス許可は "バックアップ閲覧者" です。
- セカンダリ リージョンで使用できるバックアップ データの RPO は 12 時間です。 このため、CRR をオンにすると、セカンダリ リージョンの RPO は 12 時間 + ログ頻度期間 (15 分以上に設定できます) になります。
セカンダリ リージョンの復元ジョブの監視
Azure portal で、[監視 + レポート] > [バックアップ ジョブ] に移動します。
セカンダリ リージョンのインスタンス リージョンをフィルター処理して、セカンダリ リージョン内のジョブを表示します。