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