次の方法で共有

Azure portal を使用して Azure PostgreSQL-Flexible サーバーをファイルとして復元する

この記事では、Azure portal を使用してバックアップされたファイルとして Azure PostgreSQL-Flexible サーバーを復元する方法について説明します。

前提条件

Azure Database for PostgreSQL フレキシブル サーバー バックアップから復元する前に、次の前提条件を確認してください。

  • 復元操作に必要な アクセス許可があることを確認します。

  • バックアップ データは、Microsoft テナント内の BLOB としてバックアップ コンテナーに保存されます。 復元操作の間に、バックアップ データはテナントをまたいで異なるストレージ アカウント間でコピーされます。 復元のターゲット ストレージ アカウントで AllowCrossTenantReplication プロパティが true に設定されていることを確認します。

  • ファイルとしてバックアップを復元するためのターゲット ストレージ アカウントにパブリック ネットワーク経由でアクセスできることを確認します。 ストレージ アカウントがプライベート エンドポイントを使用している場合は、復元操作を実行する前に 、そのパブリック ネットワーク アクセス設定を更新 します。

Azure PostgreSQL - フレキシブル サーバー バックアップをファイルとして復元する

注

復元操作は、次の 2 つの手順で行います。

  1. バックアップ コンテナーからストレージ コンテナーにバックアップを復元します。
  2. ストレージ コンテナーから新規または既存のフレキシブル サーバーにバックアップ ファイルを復元します。

Azure PostgreSQL-Flexible データベースを復元するには、次の手順に従います。

  1. [バックアップ コンテナー]>[Backup Instances]\(バックアップ インスタンス\) に移動します。 復元する PostgreSQL - フレキシブル サーバーを選択し、[復元] を選択 します。

    または、[バックアップ センター] に進み、[復元] を選択します。

  2. [復元ポイントを選択する] を使用して、復元する時点を選択します。 [期間]を選択すると、日付範囲を変更できます。

  3. [復元パラメータ] タブで、ターゲット ストレージ アカウントとコンテナーを選択します。[検証] を選択して、最終的な確認と復元の前に復元パラメータのアクセス許可を確認します。

  4. 検証が成功した場合は、[レビューと復元] を選択します。

  5. パラメーターの最終確認後、[ 復元 ] を選択して、選択した PostgreSQL - フレキシブル サーバー バックアップをターゲット ストレージ アカウントに復元します。

  6. 復元操作を送信し、トリガーされたジョブを [バックアップ ジョブ] で追跡します。

復元ジョブが正常に完了したら、ストレージ アカウント コンテナーに移動して、PostgreSQL - フレキシブル サーバーから復元されたデータベースをファイル (.sql ファイル) として表示します。 Azure Backup では、次のバックアップ ファイルも生成されます。

  • Database.sql file データベースごと: 特定のデータベースのデータとスキーマ情報が含まれます。

  • Roles.sql files インスタンス全体: サーバー レベルで存在するすべてのロール情報が含まれます。

  • Tablespace.sql file: テーブルスペース ファイル。

  • Schema.sql file: サーバー上のすべてのデータベースのスキーマ情報が含まれます。

    注

    スキーマは既に database.sql スクリプトの一部であるため、PostgreSQL - フレキシブル サーバーでこのスクリプトを実行しないことをお勧めします。

ストレージ コンテナーから新規または既存の PostgreSQL - フレキシブル サーバーにバックアップ ファイルを復元する

ストレージ コンテナーから新規または既存の PostgreSQL - フレキシブル サーバーにバックアップ ファイルを復元するには、次の手順に従います。

  1. 新しいターゲット フレキシブル サーバーで、必要なすべての 拡張機能が有効 になっていることを確認します。

  2. Azure portal の [サーバー パラメーター] セクションにアクセスし、それに応じて値を手動で更新することで、ソース PostgreSQL データベースのサーバー パラメーター値を Azure Database for PostgreSQL と照合します。 パラメーターの変更を保存し、Azure Database for PostgreSQL - フレキシブル サーバーを再起動して新しい構成を適用します。

  3. 新しいサーバーで Microsoft Entra 認証 が必要な場合は、それを有効にして、関連する Microsoft Entra 管理者を作成します。

  4. 復元用の新しいデータベースを作成します。

    注

    データベースの復元の前に、新しい空のデータベースを作成する必要があります。 ユーザー アカウントに CREATEDB アクセス許可があることを確認します。

    データベースを作成するには、 CREATE DATABASE Database_name コマンドを使用します。

  5. ターゲット管理者ユーザーとして database.sql file を使用してデータベースを復元します。 1.ターゲット データベースが作成されたら、次のコマンドを実行して、このデータベース内のデータを Azure ストレージ アカウントから (ダンプ ファイルから) 復元します。

    az storage blob download --container-name <container-name> --name <blob-name> --account-name <storage-account-name> --account-key <storage-account-key> --file - | pg_restore -h <postgres-server-url> -p <port> -U <username> -d <database-name> --no-owner -v –
    • --account-name: ターゲット ストレージ アカウントの名前。
    • --container-name: BLOB コンテナーの名前。
    • --blob-name: BLOB の名前。
    • --account-key: ストレージ アカウント キー。
    • -Fd: ディレクトリ形式
    • -j: ジョブの数。
    • -C: データベース自体を作成して、それに再接続するコマンドで出力を開始する

    または、バックアップ ファイルをダウンロードして復元を直接実行することもできます。

  6. 必要なロールと特権のみを復元し、 一般的なエラーを無視します。 コンプライアンス要件とデータ取得の復元をローカル管理者として実行する場合は、この手順をスキップします。

復元されたデータベースのロールとユーザーを復元する

コンテナー化されたバックアップは、主に、テストや監査などのコンプライアンス のニーズに応じて復元されます。 ローカル管理者としてサインインし、 database.sql ファイルを使用して復元できます。データを取得するために他のロールは必要ありません。

誤削除保護やディザスター リカバリーなどのその他の用途では、組織のニーズに従って必要なロールが作成されていることを確認します。 roles.sqlとdatabase.sqlの間の重複を避けます。

  • 同じフレキシブル サーバーを復元する: 役割の復元は必要ない場合があります。
  • 別のフレキシブル サーバーに復元する: roles.sql ファイルを使用して、必要なロールを再作成します。

roles.sqlから復元すると、新しいターゲット サーバーに対して一部のロールまたは属性が無効になる場合があります。

スーパーユーザー アクセス (オンプレミスまたは VM) を使用する環境では、すべてのコマンドをシームレスに実行できます。

フレキシブル サーバー シナリオの主な考慮事項

主な考慮事項を次に示します。

  • Superuser-Only 属性の削除: フレキシブル サーバーでは、スーパーユーザー特権はありません。 そのため、ロール ダンプから NOSUPERUSER や NOBYPASSRLS などの属性を削除します。
  • Service-Specific ユーザーの除外: フレキシブル サーバー サービス ( azure_su、 azure_pg_admin、 replication、 localadmin、 Entra Admin) に固有のユーザーを除外します。 管理者が新しいフレキシブル サーバーに追加されると、これらの特定のサービス ロールが自動的に再作成されます。

データベース オブジェクトを復元する前に、ロールを適切にダンプしてクリーンアップしてください。 このアクションを実行するには、ストレージ コンテナーから roles.sqlscript をダウンロードし、必要なすべてのログインを作成します。

  • 非 Entra ロールの作成: ローカル管理者アカウントを使用してロール作成スクリプトを実行します。
  • Microsoft Entra ロールの作成: Microsoft Entra ユーザーのロールを作成する必要がある場合は、Microsoft Entra 管理者アカウントを使用して必要なスクリプトを実行します。

次のスクリーンショットに示すように、ストレージ アカウントからロール スクリプトをダウンロードできます。

出力ファイルを移行すると、 roles.sql には、新しい環境では適用できない特定のロールと属性が含まれる場合があります。 次の点を考慮する必要があります。

  • スーパーユーザーのみが設定できる属性の削除: スーパーユーザー特権がない環境に移行する場合は、ロール ダンプから NOSUPERUSER や NOBYPASSRLS などの属性を削除します。
  • サービス固有ユーザーの除外: azure_superuser や azure_pg_adminなどの単一サーバー サービス ユーザーを除外します。 これらはサービスに固有であり、新しい環境で自動的に作成されます。

ロール ダンプをクリーンアップするには、次の sed コマンドを使用します。

sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql

このコマンドは,azure_superuser レプリケーションおよび azure_pg_admin レプリケーションで始まるazuresu,,行を含む行を削除し,ALTER ROLE ステートメントから NOSUPERUSER 属性と NOBYPASSRLS 属性を除去します。

次のステップ

Azure portal を使用して Azure PostgreSQL - フレキシブル サーバーのバックアップを管理します。