Azure Database for PostgreSQL バックアップとは

Azure Backup と Azure Database Services を連携させることで、バックアップを最大 10 年間保持する、Azure Database for PostgreSQL サーバー向けのエンタープライズクラスのバックアップソリューションが構築されます。このソリューションには、長期的な保有期間以外に、次の機能が用意されています。

個々のデータベースレベルで、顧客がコントロールするスケジュールされたバックアップとオンデマンドバックアップ。
任意の Azure Database for PostgreSQL サーバーまたは任意の種類の BLOB ストレージにデータベースレベルで復元します。
すべての操作とジョブの一元的な監視。
個別のセキュリティドメインと障害ドメインにバックアップの保存。ソースサーバーまたはサブスクリプションが侵害された場合、Backup コンテナー (Azure Backup マネージドストレージアカウント) でバックアップは安全なままです。
復元の柔軟性を高めるための pg_dump の使用。データベースのバージョン間で復元できます。

このソリューションは個別に使用できます。また、データ保有期間が最大 35 日の Azure PostgreSQL のネイティブバックアップソリューションに加えて使用することもできます。ネイティブソリューションは、最新のバックアップから復旧する場合など、運用復旧に適しています。 Azure Backup ソリューションを使用すると、コンプライアンスのニーズを満たし、より細かく柔軟なバックアップと復元機能を提供することができます。

PostgreSQL 単一サーバーの保管バックアップの変更

Azure Database for PostgreSQL の 単一サーバー デプロイオプションは 、2025 年 3 月 28 日に廃止されました。その日に、Azure Backup for PostgreSQL 単一サーバーに変更が実装されました。退職について詳しく知る。

Azure Backup は、保管庫のバックアップや復元ポイントの長期保持など、コンプライアンスと回復性のソリューションを提供します。 2025 年 3 月 28 日に、次の変更が実施されました。

バックアップ構成は、新しい PostgreSQL 単一サーバーワークロードでは許可されません。
スケジュールされたすべてのバックアップジョブは、完全に中止されます。
このワークロードに対して新しいバックアップポリシーを作成したり、既存のバックアップポリシーを変更したりすることはできません。

廃止日には、PostgreSQL シングルサーバデータベースのスケジュールされたバックアップジョブが完全に停止しました。新しい復元ポイントを作成することはできません。

ただし、既存の PostgreSQL シングルサーバデータベースのバックアップは、バックアップポリシーに従って保持されます。復元ポイントは、保持期間の有効期限が切れた後にのみ削除されます。復元ポイントを無期限に保持するか、リテンション期間の有効期限が切れる前に復元ポイントを削除するには、回復性コンソールを参照してください。

請求の変更

2025 年 3 月 31 日以降、PostgreSQL の単一サーバーデータベースを保護するための保護インスタンス (PI) 料金は請求されなくなりました。ただし、バックアップの保存料金は引き続き適用されます。ストレージ料金を回避するには、回復性からすべての復元ポイントを削除します。

注

Azure Backup は、保有期間の有効期限が切れた後でも、最後の復元ポイントを保持します。この機能により、将来の使用のために最後の復元ポイントにアクセスできるようになります。最後の復元ポイントは手動でのみ削除できます。最後の復元ポイントを削除してストレージ料金を回避する場合は、データベース保護を停止します。

復元の変更点

PostgreSQL の単一サーバーデータベースは、[ファイルとして復元] を使用して復元できます。次に、復元されたファイルから新しい PostgreSQL フレキシブルサーバーを手動で作成する必要があります。

注

[データベースとして復元] オプションは 2025 年 3 月 28 日現在サポートされていませんが、[ファイルとして復元] は引き続きサポートされています。

バックアッププロセス

バックアップ管理者は、バックアップする PostgreSQL データベースを指定できます。指定されたデータベースに接続するために必要な資格情報を格納する Azure Key Vault の詳細を指定することもできます。データベース管理者は、これらの資格情報を Key Vault に安全にシードします。
Azure Backup Server は、指定された Azure Database for PostgreSQL サーバーで認証するための適切なアクセス許可と、データベースをバックアップするためのアクセス許可があるかどうかを検証します。
Azure Backup は、保護された Azure Database for PostgreSQL サーバーと通信するために、バックアップ拡張機能がインストールされている worker ロール (仮想マシン) をスピンアップします。この拡張機能は、コーディネーターと PostgreSQL プラグインで構成されます。コーディネーターは、バックアップや復元などのさまざまな操作のワークフローをトリガーします。プラグインは実際のデータフローを管理します。
スケジュールされた時刻になると、コーディネーターは、pg_dump (カスタム) を使用して Azure Database for PostgreSQL サーバーからバックアップデータのストリーミングを開始するようにプラグインに指示します。
このプラグインによって、データが Azure Backup マネージドストレージアカウント (Azure Backup ボールトによってマスクされます) に直接送信されるため、ステージング場所は不要になります。このデータは Microsoft マネージドキーで暗号化されます。 Azure Backup サービスでは、データがストレージアカウントに格納されます。

バックアッププロセスを示す図。

Azure Database for PostgreSQL サーバーを使用した Azure Backup 認証

Azure Backup は、Azure からの厳密なセキュリティガイドラインに準拠しています。バックアップするリソースに対するアクセス許可は想定されません。ユーザーは、これらのアクセス許可を明示的に付与する必要があります。

キーコンテナーベースの認証モデル

Azure Backup サービスは、各バックアップの実行中に Azure Database for PostgreSQL サーバーに接続する必要があります。この接続には、データベースに対応するユーザー名とパスワード (または接続文字列) が使用されますが、これらの資格情報は Azure Backup と一緒には格納されません。代わりに、データベース管理者はこれらの資格情報を [シークレットとして Azure Key Vault] 内に安全にシード処理する必要があります。

ワークロード管理者は、資格情報の管理とローテーションを担当します。 Azure Backup は、バックアップを作成するために、キーコンテナーから最新のシークレットの詳細を呼び出します。

ワークロードまたはデータベースフローを示す図。

PostgreSQL データベースのバックアップに必要な権限

Azure Backup ボールトのマネージド ID に対して、次のアクセス許可を付与します。
- Azure Database for PostgreSQL サーバーでの閲覧者アクセス権。
- Key Vault シークレット Key Vault に対するユーザー アクセス (シークレットに対するアクセス許可の取得 と 一覧表示 )。
次の場所に対するネットワーク通信経路アクセス権:
- Azure Database for PostgreSQL サーバー: [Azure サービスへのアクセスを許可する] を [はい] に設定します。
- Key Vault: [信頼された Microsoft サービスを許可する] を [はい] に設定します。
データベースに対するデータベースユーザーのバックアップ権限を設定します。

注

バックアップ管理者として目的のリソースに対する書き込みアクセス権がある場合は、バックアップの構成フロー内で 1 回のクリックでこれらのアクセス許可を付与できます。必要なアクセス許可がない場合 (複数のペルソナが関係している場合) は、Azure Resource Manager テンプレートを使用します。

PostgreSQL データベースの復元に必要な権限

復元の権限は、バックアップに必要な権限と似ています。ターゲットの Azure Database for PostgreSQL サーバーと対応するキーコンテナーに対するアクセス許可を手動で付与する必要があります。バックアップの構成フローとは異なり、現在これらのアクセス許可をインラインで付与する操作は用意されていません。

データベースユーザーが、データベースに対し、キーコンテナーに格納されている資格情報に対応する次の復元権限を持っていることを確認します。

ALTER USER ユーザー名「CREATEDB」を割り当てます。
データベースユーザーに、ロールazure_pg_adminを割り当てます。

Microsoft Entra ID ベースの認証モデル

以前の認証モデルは、完全に Microsoft Entra ID に基づいていました。 Key Vault ベースの認証モデル (前に説明したように) が、構成プロセスを容易にする代替オプションとして使用できるようになりました。

Microsoft Entra ID ベースの認証モデルを使用するための自動スクリプトと関連する指示を入手するには、こちらのドキュメントをダウンロードしてください。これにより、バックアップと復元のために、Azure Database for PostgreSQL サーバーへの適切な一連のアクセス許可が付与されます。

注

新しいすべての構成の保護は、新しいキーコンテナー認証モデルでのみ実行されます。ただし、Microsoft Entra ID ベースの認証を使用して保護が構成されている既存のすべてのバックアップインスタンスは、今後も存続され、定期的なバックアップが行われます。これらのバックアップを復元するには、Microsoft Entra ID ベースの認証に従う必要があります。

Azure Database for PostgreSQL サーバーとキーコンテナーに対するアクセス権を手動で付与する手順

Azure Backup に必要なすべてのアクセス許可を付与するには、次の手順を使用します。

Azure Database for PostgreSQL サーバーに対するアクセス許可

Azure Database for PostgreSQL サーバー上のマネージド ID に対して、Azure Backup コンテナーの 閲覧者アクセス権を設定します。
[Azure サービスへのアクセス許可] フラグを [はい] に設定することにより、Azure Database for PostgreSQL サーバーでのネットワーク通信経路アクセス権を設定します。

キーコンテナーに対するアクセス許可

Azure Backup コンテナーの [キーコンテナーシークレットユーザー] アクセスを、キーコンテナーのマネージド ID に設定します (シークレットに対する Get と List のアクセス許可)。アクセス許可を割り当てるには、ロールの割り当てまたはアクセスポリシーを使用します。両方のオプションを使用してアクセス許可を追加する必要はありません。これは役に立たないためです。
- Azure ロールベースのアクセス制御 (Azure RBAC) 承認を使用するには:
  1. [アクセスポリシー] で、[アクセス許可モデル] を [Azure ロールベースのアクセス制御] に設定します。
  2. [アクセス制御 (IAM)] で、Azure Backup コンテナーの キーコンテナーシークレットユーザーに、キーコンテナーのマネージド ID に対するアクセス権を付与します。そのロールのベアラーは、シークレットを読み取ることができます。
  詳細については、「 Azure ロールベースのアクセス制御を使用して Key Vault のキー、証明書、シークレットへのアクセスを提供する」を参照してください。
- アクセスポリシーを使用するには:
  1. [アクセスポリシー] で、 [アクセス許可モデル] を [コンテナーアクセスポリシー] に設定します。
  2. シークレットに対する Get 権限と List 権限を設定します。
  詳細については、「Key Vault アクセスポリシーを割り当てる (レガシ)」を参照してください。
キーコンテナーのネットワーク見通し内アクセスを設定するには、[信頼された Microsoft サービスにこのファイアウォールのバイパスを許可しますか?] を [はい] に設定します。

データベースに対するデータベースユーザーのバックアップ権限

pgAdmin ツールで次のクエリを実行します。 username をデータベースユーザー ID で置き換えます。

DO $do$
DECLARE
sch text;
BEGIN
EXECUTE format('grant connect on database %I to %I', current_database(), 'username');
FOR sch IN select nspname from pg_catalog.pg_namespace
LOOP
EXECUTE format($$ GRANT USAGE ON SCHEMA %I TO username $$, sch);
EXECUTE format($$ GRANT SELECT ON ALL TABLES IN SCHEMA %I TO username $$, sch);
EXECUTE format($$ ALTER DEFAULT PRIVILEGES IN SCHEMA %I GRANT SELECT ON TABLES TO username $$, sch);
EXECUTE format($$ GRANT SELECT ON ALL SEQUENCES IN SCHEMA %I TO username $$, sch);
EXECUTE format($$ ALTER DEFAULT PRIVILEGES IN SCHEMA %I GRANT SELECT ON SEQUENCES TO username $$, sch);
END LOOP;
END;
$do$

注

バックアップを既に構成したデータベースが UserErrorMissingDBPermissions で失敗する場合は、このトラブルシューティングガイドを参照して、問題の解決に役立ててください。