Azure Database for PostgreSQL フレキシブル サーバーでのバックアップと復元

バックアップは、ビジネス継続性戦略の不可欠な部分です。 これは、不慮の破損や削除からデータを保護するのに役立ちます。

Azure Database for PostgreSQL では、サーバーの定期的なバックアップが自動的に実行されます。 その後、指定した保持期間内にポイントインタイム リカバリー (PITR) を実行できます。 通常、復元と復旧の全体的な時間は、データのサイズと実行する回復の量によって異なります。

Backup の概要

Azure Database for PostgreSQL は、データ ファイルのスナップショット バックアップを取得し、 リージョンに応じてゾーン冗長ストレージまたはローカル冗長ストレージに安全に格納します。 また、先書きログ (WAL) ファイルをアーカイブする準備ができたら、サーバーによってトランザクション ログもバックアップされます。 これらのバックアップを使用して、構成されたバックアップ保有期間内の任意の時点にサーバーを復元します。

既定のバックアップ保有期間は 7 日間ですが、期間を最大 35 日まで延長できます。 すべてのバックアップの保存データは、AES 256 ビット暗号化を使用して暗号化されます。

これらのバックアップ ファイルをエクスポートしたり、それらを使用して Azure Database for PostgreSQL フレキシブル サーバー インスタンスの外部にサーバーを作成したりすることはできません。 その目的のためには、PostgreSQL ツールの pg_dump と pg_restore/psql を使用できます。

バックアップ頻度

Azure Database for PostgreSQL フレキシブル サーバー インスタンスでのバックアップはスナップショット ベースです。 初回のスナップショット バックアップは、サーバーの作成直後にスケジュールされます。 スナップショット バックアップは、現在のところ、毎日 1 回作成されます。 前回のスナップショット バックアップの後にサーバー上のデータベースをこれ以上変更しない場合、システムはスナップショット バックアップを一時的に中断します。 サーバー上のデータベースを変更するとすぐに、システムは新しいスナップショットをすぐに取得して最新の変更をキャプチャします。 最初のスナップショットは完全バックアップであり、連続するスナップショットは差分バックアップです。

トランザクション ログのバックアップは、ワークロードや、WAL ファイルがいっぱいになり、アーカイブの準備ができるタイミングに応じて、さまざまな頻度で実行されます。 一般に、遅延 RPO (目標復旧ポイント) は最大 5 分です。

バックアップ冗長オプション

Azure Database for PostgreSQL には、計画されたイベントや計画外のイベントからデータを保護するために、バックアップの複数のコピーが格納されます。 このようなイベントには、一時的なハードウェアの障害、ネットワークの停止や停電、自然災害などが含まれます。 バックアップの冗長性により、障害が発生した場合でもデータベースが可用性と耐久性のターゲット値を満たすことができます。

Azure Database for PostgreSQL には、次の 3 つのオプションがあります。

• ゾーン冗長バックアップ ストレージ: Azure Database for PostgreSQLは、可用性ゾーンをサポートするリージョンに対してこのオプションを自動的に選択します。 ゾーン冗長バックアップ ストレージにバックアップを格納すると、サービスは、サーバーがホストされている可用性ゾーン内にデータのコピーを 3 つ保持します。 さらに、サービスは、保護を強化するためにデータを別の可用性ゾーンにレプリケートします。

  このオプションを使用すると、可用性ゾーン間でバックアップ データの可用性が提供され、データ所在地の要件を満たすために、国またはリージョン内へのデータのレプリケーションが制限されます。 バックアップオブジェクトは、1年間で少なくとも 99.9999999999%（12ナイン）の耐久性を提供します。

• ローカル冗長バックアップ ストレージ: Azure Database for PostgreSQLは、可用性ゾーンをまだサポートしていないリージョンに対して、このオプションを自動的に選択します。 バックアップをローカル冗長バックアップ ストレージに格納すると、サービスはバックアップの複数のコピーを同じデータセンターに格納します。

  このオプションは、サーバー ラックとドライブの障害からデータを保護するのに役立ちます。 これにより、バックアップ オブジェクトの年間 99.999999999% (9 が 11 個) 以上の持続性が実現されます。

  既定では、サービスは、同じゾーンの高可用性 (HA) または高可用性構成のないサーバーのバックアップ ストレージをローカル冗長に設定します。

• geo 冗長バックアップ ストレージ: このオプションは、サーバーの作成時に選択できます。 geo 冗長バックアップ ストレージにバックアップを格納すると、サーバーがホストされているリージョン内に格納されているデータの 3 つのコピーに加えて、サービスは geo ペアのリージョンにデータをレプリケートします。

  このオプションを使用すると、障害が発生した場合に別のリージョンのサーバーを復元できます。 さらにこれにより、バックアップ オブジェクトの年間 99.99999999999999% (9 が 16 個) 以上の持続性が実現されます。

  Geo 冗長性は、Azure のペアになっているリージョンのいずれかでホストされているサーバーでサポートされます。

他のバックアップ ストレージ オプションから geo 冗長バックアップ ストレージへの移行

バックアップ用 geo 冗長ストレージは、サーバーの作成時にのみ構成できます。 サーバーがプロビジョニングされると、バックアップ ストレージ冗長オプションを変更することはできません。

バックアップ保有期間

サーバーは、設定した保有期間に基づいてバックアップを保持します。 7 日間 (既定) から 35 日間までの保持期間を選択できます。 サーバーの作成時に保持期間を設定するか、後で変更します。 サーバーは、停止したサーバーに対してもバックアップを保持します。

バックアップ保有期間は、使用可能なバックアップからポイントインタイム リストア (PITR) を取得するための期間を決定します。 また、復元の観点から、バックアップ保有期間を復旧期間と見なすこともできます。

バックアップ ストレージには、バックアップ保有期間内に PITR を実行するために必要なすべてのバックアップが保持されます。 たとえば、バックアップ保有期間を 7 日に設定した場合、回復期間は過去 7 日間です。 このシナリオでは、バックアップ ストレージには、過去 7 日間にサーバーを復元および回復するために必要なすべてのデータとログが保持されます。

バックアップ ストレージのコスト

Azure Database for PostgreSQL では、プロビジョニングされたサーバー ストレージの最大 100% がバックアップ ストレージとして追加コストなしで提供されます。 1 か月あたりギガバイト単位で使用する追加のバックアップ ストレージに対して料金が発生します。

たとえば、250 ギビバイト (GiB) のストレージを備えたサーバーをプロビジョニングすると、追加料金なしで 250 GiB のバックアップ ストレージ容量が得られます。 1 日のバックアップ使用量が 25 GiB の場合、最大 10 日間の無料バックアップ ストレージを使用できます。 価格モデルで定義されている 250 GiB を超えるバックアップ ストレージ使用量に対して支払います。

geo 冗長バックアップを使用してサーバーを構成した場合、バックアップ データもAzureペアになっているリージョンにコピーされます。 そのため、バックアップ サイズはローカル バックアップ コピーのサイズの 2 倍になります。 課金は、( (2 x ローカル バックアップ サイズ) - プロビジョニングされたストレージ サイズ) x 価格 @ ギガバイト/月として計算されます。

Azure ポータルの [Backup Storage Used] メトリックを使用して、サーバーが使用するバックアップ ストレージを監視します。 使用済みバックアップ ストレージ メトリックは、サーバーに設定されているバックアップ保持期間に基づいて、保持されるすべてのデータベース バックアップとログ バックアップによって使用されたストレージの合計を表します。

ポイントインタイム リストア

Azure Database for PostgreSQL フレキシブル サーバー インスタンスでは、PITR を実行すると、ソース サーバーと同じリージョンに新しいサーバーが作成されますが、可用性ゾーンを選択できます。 価格レベル、コンピューティング世代、仮想コア数、ストレージ サイズ、バックアップの保持期間、およびバックアップ冗長オプションについては、ソース サーバーの構成を使用して作成されます。

物理データベース ファイルは、最初にスナップショット バックアップからサーバーのデータの場所に復元されます。 目的の時点より前に作成された適切なバックアップが自動的に選択され、復元されます。 その後、WAL ファイルを使用して復旧プロセスが開始されて、データベースが一貫性のある状態になります。

たとえば、バックアップが毎晩、午後 11 時に実行されているとします。 復元ポイントが 8 月 15 日午前 10 時の場合は、8 月 14 日の日次バックアップが復元されます。 データベースは、8 月 14 日午後 11 時 00 分から 8 月 15 日午前 10 時 00 分までのトランザクション ログ バックアップを使用して、8 月 15 日の午前 10 時まで復旧されます。

データベース サーバーを復元するには、次のいずれかを参照してください。

• 最新の復元ポイントの復元。
• カスタム復元ポイントの復元。
• 完全バックアップへの復元 (高速復元)。
• ペア リージョンの復元 (geo 復元)。

ポイントインタイム リストアは、次のようなシナリオで役立ちます。

• ユーザーがデータ、テーブル、またはデータベースを誤って削除する。
• アプリケーションの欠陥のため、正しいデータが不適切なデータで誤って上書きされる。
• テスト、開発、またはデータ検証のためにサーバーを複製する必要があります。

トランザクション ログの連続バックアップを使用すると、最後のトランザクションに復元できます。 次の復元オプションのいずれかを選択できます。

• 最新の復元ポイント (現在): これは、サーバーを最新の時点に復元する既定のオプションです。

• カスタム復元ポイント: このオプションを使うと、この Azure Database for PostgreSQL フレキシブル サーバー インスタンスに定義されている保持期間内の任意の時点を選択できます。 既定で、UTC の最新時刻が自動的に選択されます。 自動選択は、テスト目的で最後にコミットされたトランザクションに復元する場合に便利です。 任意で他の日時を選択できます。

• 高速復元ポイント: このオプションは、Azure Database for PostgreSQLフレキシブル サーバー インスタンスに対して定義された保持期間内に、可能な限り最速の時間でサーバーを復元します。 バックアップの一覧からタイムスタンプを直接選択することで、最速に復元できます。 この復元操作では、サーバーがプロビジョニングされ、スナップショットの完全バックアップが復元されます。 ログを復旧する必要がないため、高速になります。 復元操作を正常に完了するには、最も早い復元時点より後のバックアップ タイムスタンプを選択します。

最新の復元ポイント オプションとカスタム復元ポイント オプションを使用して復旧するために必要な時間は、前回のバックアップ以降に処理するトランザクション ログの量や、同じリージョンで同時に復旧されるデータベースの合計数などの要因によって異なります。 全体的な復旧時間は、通常、数分から数時間かかります。

仮想ネットワーク内でサーバーを構成する場合は、同じ仮想ネットワークまたは別の仮想ネットワークに復元できます。 ただし、パブリック アクセスには復元できません。 同様に、パブリック アクセスでサーバーを構成した場合、プライベート仮想ネットワーク アクセスへの復元はできません。

地理的に冗長化されたバックアップと復元

Azure portal の [コンピューティングとストレージ ] ウィンドウから geo 冗長バックアップを有効にするには、「 Azure Database for PostgreSQL の作成」を参照してください。

ジオ冗長バックアップを使用してサーバーを構成した後、ジオペア地域に復元できます。 詳細については、geo 冗長バックアップでサポートされているリージョンに関するページを参照してください。

geo 冗長バックアップを使用してサーバーを構成すると、バックアップ データとトランザクション ログが、ストレージ レプリケーションを介してペアになっているリージョンに非同期的にコピーされます。 サーバーの作成後、少なくとも 1 時間待ってから geo リストアを開始してください。 この待機時間により、バックアップ データの最初のセットをペアのリージョンにレプリケートできます。

その後、トランザクション ログと毎日のバックアップは、ペアになっているリージョンに非同期的にコピーされます。 データ転送では、最大 1 時間の延期期間が発生する可能性があります。 そのため、復元するときに見込まれる RPO は最大で 1 時間です。 復元できるのは、ペア リージョンで見つかる最新の使用可能なバックアップ データのみです。 現在、geo 冗長バックアップの PITR は利用できません。

サーバーの復旧にかかる推定時間の RTO (目標復旧時間) は、データベースのサイズ、データベースの最後のバックアップの時刻、最後に受け取ったバックアップ データまでの処理するべき WAL の量などの要因によって決まります。 全体的な復旧時間は、通常は数分から数時間かかります。

geo リストア中に、仮想ネットワーク設定を含むサーバー構成と、復元されたサーバーから geo 冗長バックアップを削除する機能を変更できます。 コンピューティング、ストレージ、または価格レベル (バースト可能、汎用、またはメモリ最適化) など、他のサーバー構成の変更は、geo リストア中はサポートされていません。

詳細については、ペア Azure リージョンに復元する (geo 復元) を参照してください。

復元とネットワーク

ポイントインタイム リストア

パブリック アクセス ネットワークを使用してソース サーバーを構成する場合は、パブリック アクセスにのみ復元できます。

プライベート アクセス仮想ネットワークを使用してソース サーバーを構成する場合は、同じ仮想ネットワークまたは別の仮想ネットワークに復元できます。 パブリックアクセスとプライベートアクセスをまたいでポイント・イン・タイム・リカバリーを実行することはできません。

geo リストア

パブリック アクセス ネットワークを使用してソース サーバーを構成する場合は、パブリック アクセスにのみ復元できます。 また、復元操作の完了後にファイアウォール規則を適用する必要があります。

プライベート アクセス仮想ネットワークを使用してソース サーバーを構成した場合、復元できるのは別の仮想ネットワークに限られます。これは、仮想ネットワークがリージョンをまたがることができないためです。 パブリック アクセスとプライベート アクセスをまたいで geo リストアを実行することはできません。

復元後のタスク

サーバーを復元した後、ユーザーとアプリケーションを再び利用可能な状態にするために、次の作業を実行します。

• 新しいサーバーが元のサーバーを置き換える場合は、クライアントとクライアント アプリケーションを新しいサーバーにリダイレクトします。 新しいサーバーを指すように、接続文字列のサーバー名を変更します。

• 元のサーバー上のすべての パラメーター の値は、新しいサーバーに自動的には適用されません。 新しいサーバーの要件に従って、新しいサーバー上のすべてのパラメーターを再構成してください。

• ユーザー接続に対して、適切なサーバー レベルのファイアウォール規則、プライベート エンドポイント、および仮想ネットワーク規則が設定されていることを確認します。 これらのルールは、元のサーバーからコピーされません。

• 必要に応じて、復元されたサーバーのコンピューティングをスケールアップまたはスケールダウンします。

• 適切なログインとデータベースレベルのアクセス許可が指定されていることを確認します。

• 必要に応じてアラートを構成します。

• 復元元のソース サーバーが高可用性で構成されていて、復元されたサーバーを高可用性で構成する場合は、 次の手順に従います。

• 復元元のソース サーバーが読み取りレプリカで構成されていて、復元されたサーバーで読み取りレプリカを構成する場合は、「 読み取りレプリカの作成」の手順に従います。

オンデマンド バックアップ

Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、スケジュールされたバックアップの一部として、すべてのデータベースを対象に、データベース インスタンス全体のストレージ ボリューム スナップショットを自動的に生成します。 さらに、必要に応じてオンデマンド バックアップを作成できます。 このオプションは、危険な可能性のある操作の準備や、通常のバックアップ スケジュール外の定期的な更新の実行などのシナリオに最適です。

スケジュールされた自動バックアップに加えて、オンデマンド バックアップを実行します。 バックアップの保持期間によって、これらのバックアップを保持する期間が決まります。 オンデマンド バックアップが不要になった場合は、いつでも削除できます。 オンデマンド バックアップを開始するには、バックアップするデータベース インスタンスを選択し、バックアップ名を指定します。 これらのバックアップは自動バックアップと共に格納されますが、ユーザーのみがオンデマンド バックアップを削除できます。 このサービスは、バックアップ保有期間の要件を満たすために、自動バックアップを管理および保持します。

詳細については、「 オンデマンド バックアップの実行」を参照してください。

制限事項

• バースト可能なサーバー コンピューティング レベルでは、オンデマンド バックアップ機能はサポートされていません。
• SSDv2 ストレージ層は、オンデマンド バックアップ機能をサポートしていません。
• フレキシブル サーバー インスタンスごとに最大 7 つのオンデマンド バックアップを実行できます。 バックアップの保持期間によって、これらのバックアップを保持する期間が決まります。

長期保存

Azure BackupおよびAzure Database for PostgreSQL サービスは、最大 10 年間バックアップを保持する、Azure Database for PostgreSQLフレキシブル サーバー インスタンス向けのエンタープライズ クラスの長期的なバックアップ ソリューションを提供します。 長期リテンション期間 (LTR) は、独立して使用することも、最大 35 日間のリテンション期間を提供する Azure Database for PostgreSQL によって提供される自動バックアップ ソリューションと共に使用することもできます。 自動バックアップは、特に最新のバックアップから復元する場合に、運用復旧に適した物理バックアップです。 長期バックアップは、コンプライアンス要件を満たすのに役立ち、よりきめ細かく、ネイティブの pg_dump を使用した論理バックアップとして取得されます。 このソリューションには、長期保有に加えて、次の機能が用意されています:

• 個々のデータベース レベルで、顧客がコントロールするスケジュールされたバックアップとオンデマンド バックアップ。
• すべての業務と作業の一元管理。
• バックアップは、個別のセキュリティ ドメインと障害ドメインに保存されます。 ソース サーバーまたはサブスクリプションが侵害された場合、Backupコンテナー (Azure Backup マネージド ストレージ アカウント) でバックアップは安全なままです。
• pg_dumpを使用すると、異なるデータベース バージョン間でデータを復元する柔軟性が向上します。
• Azure Backup コンテナーでは、不変性と論理的な削除 (プレビュー) 機能がサポートされ、データが保護されます。
• CMK が有効なサーバーでの LTR バックアップのサポート。

制限事項と考慮事項

• LTR バックアップをテストし、構成直後に復元して、ビジネス要件を満たしていることを確認します。
• LTR 復元は現在、ストレージ アカウントへの ファイルとして復元 としてのみ使用でき、サーバー としての復元 機能は今後予定されています。
• LTR では、フレキシブル サーバー インスタンス内のすべてのデータベースがバックアップされ、LTR 構成用に個々のデータベースを選択することはできません。
• LTR バックアップはレプリカではサポートされていませんが、プライマリ サーバーで実行できます。
• 長期保有 (LTR) バックアップでサポートされる最大データベース サイズは 1 TiB です。
• LTR バックアップは、毎週、毎月、または毎年スケジュールできます。 毎日のバックアップ スケジュールは現在サポートされていません。
• LTR バックアップでは、BYTEA の長さが 500 MB を超える行を含むテーブルはサポートされていません。
• Microsoft Entra ユーザーのロールを復元する場合は、Microsoft Entra認証が有効であること、および追加のユーザーを作成するためにMicrosoft Entra管理者としてサインインしていることを確認します。 通常のユーザーとして Entra ロールを作成しようとすると、エラーが発生します。

長期的なバックアップの実行の詳細については、 ハウツー ガイドを参照してください。

よく寄せられる質問

バックアップに関連する質問

• サーバーのバックアップは Azure でどのように処理されますか?

  既定では、Azure Database for PostgreSQLでは、既定の保有期間が 7 日間のサーバー全体 (作成されたすべてのデータベースを含む) の自動バックアップが有効になります。 自動バックアップには、データベースの毎日の増分スナップショットが含まれます。 ログ (WAL) ファイルは、Azure Blob Storage に継続的にアーカイブされます。

• 自動バックアップが長期間保有されるように構成できますか?

  No. 現在、Azure Database for PostgreSQL では、最大 35 日間のリテンション期間がサポートされています。 Azure Backupを使用して、長期保有期間の要件に手動バックアップを使用します。

• Azure Database for PostgreSQL フレキシブル サーバー インスタンスを手動でバックアップするにはどうすればよいですか?

  オンデマンド バックアップ機能を使用して、物理スナップショットを手動で取得できます。 PostgreSQL ツール pg_dumpを使用して論理バックアップを作成することもできます。 例については、「 ダンプと復元を使用した Azure Database for PostgreSQL データベースの移行」を参照してください。

• サーバーのバックアップ ウィンドウとは何ですか? それらをカスタマイズできますか?

  Azure によってバックアップの時間帯が管理され、ユーザーはカスタマイズできません。 初回の完全スナップショット バックアップは、サーバーの作成直後にスケジュールされます。 後続のスナップショット バックアップは、増分バックアップで 1 日に 1 回実行されます。

• バックアップは暗号化されますか?

  Yes. クエリの実行中に作成されるすべての Azure Database for PostgreSQL フレキシブル サーバー インスタンス データ、バックアップ、および一時ファイルは、AES (Advanced Encryption Standard) 256 ビット暗号化によって暗号化されます。 ストレージの暗号化は常にオンになっており、無効にすることはできません。

• サーバーの単一または少数のデータベースを復元できますか?

  1 つのデータベースまたはいくつかのデータベースまたはテーブルの復元は、直接サポートされていません。 ただし、サーバー全体を新しいサーバーに復元してから、新しいサーバーで不要なテーブルまたはデータベースを削除できます。

• バックアップの進行中はサーバーを使用できますか?

  Yes. バックアップは、スナップショットを使用するオンライン操作です。 スナップショット操作には数秒しかかからず、運用環境のワークロードには影響しないため、サーバーの高可用性を確保できます。

• サーバーのメンテナンス期間を設定するときに、バックアップの時間帯を考慮する必要がありますか?

  No. バックアップは管理サービスの一部として内部的にトリガーされ、メンテナンス期間には関係ありません。

• 自動バックアップはどこに格納され、その保持期間はどのように管理できますか?

  Azure Database for PostgreSQL フレキシブル サーバー インスタンスでは、サーバーのバックアップが自動的に作成され、保存場所に格納されます。

  • 複数のゾーンがサポートされているリージョンのゾーン冗長ストレージ。
  • 複数のゾーンをまだサポートしていないリージョンのローカル冗長ストレージ。
  • geo 冗長バックアップを構成する場合は、ペア Azure リージョン。

  これらのバックアップ ファイルは、Microsoftマネージド ストレージ アカウントに格納されているためエクスポートできません。 これらのファイルを復元するための読み取り専用アクセス権がありますが、ファイルを変更または削除することはできません。 バックアップ ファイルは、保持期間の後に自動的に削除されます。

  バックアップは、サーバーを特定の時点に復元するためにのみ使用できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、バックアップのリテンション期間を最大 35 日に構成できます。

• geo 冗長バックアップの使用時に、バックアップはどれほどの頻度でペア リージョンにコピーされますか?

  geo 冗長バックアップを使用してサーバーを構成すると、バックアップ データは geo 冗長ストレージ アカウントに格納されます。 ストレージ アカウントでは、プライマリ サーバーで毎日のバックアップが行われるときに、ペア リージョンにデータ ファイルがコピーされます。 WAL ファイルは、それらをアーカイブする準備が整ったときにバックアップされます。

  バックアップ データは、非同期に、連続的な方法でペア リージョンにコピーされます。 バックアップ データの受信については、最大 1 時間の延期期間が見込まれます。

• リモート リージョンで PITR を実行できますか?

  No. データは、リモート リージョンで使用できる最新のバックアップデータに復旧されます。

• HA が有効になっているサーバーではバックアップはどのように実行されますか?

  Azure Database for PostgreSQL フレキシブル サーバー インスタンス内のデータ ボリュームは、プライマリ サーバーからのマネージド ディスク増分スナップショットを使用してバックアップされます。 WAL バックアップは、プライマリ サーバーまたはスタンバイ サーバーから実行されます。

• サーバーでバックアップが実行されているのを確認するにはどうすればよいですか?

  バックアップを確認する最善の方法は、定期的なポイントインタイム リストアを実行し、バックアップが有効で復元可能であることを確認することです。 バックアップ操作またはファイルはエンド ユーザーに公開されません。

• バックアップの使用量はどこで確認できますか?

  Azure portal の [監視] で [メトリック] を選択します。 [使用済みバックアップ ストレージ] で、バックアップの合計使用量を監視できます。

• サーバーを削除した場合、バックアップはどうなりますか?

  サーバーを削除すると、そのサーバーに属するバックアップもすべて削除され、復旧できなくなります。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを使用できます。

• 停止したサーバーのバックアップはどのように保有されますか?

  停止したサーバーに対して、新しいバックアップは実行されません。 サービスは、サーバーが再起動されるまでサーバーを停止した時点で、(リテンション期間内に) 古いバックアップをすべて保持します。 その後、アクティブなサーバーのバックアップの保持は、そのバックアップ保持期間によって管理されます。

• バックアップの料金請求と支払いはどのように行われますか？

  Azure Database for PostgreSQL では、プロビジョニングされたサーバー ストレージの最大 100% がバックアップ ストレージとして追加コストなしで提供されます。 使用する追加のバックアップ ストレージの料金は、価格モデルで定義されているように、1 か月あたりギガバイト単位で課金されます。

  選択したバックアップ保持期間とバックアップ冗長オプションは、サーバー上のトランザクション アクティビティと共に、バックアップ ストレージと請求の合計に直接影響します。

• 停止中のサーバーにはどのように課金されますか？

  サーバー インスタンスが停止している間は、新しいバックアップは実行されません。 プロビジョニングされたストレージとバックアップ ストレージ (指定した保持期間内に保存されたバックアップ) に対して支払います。

  無料バックアップ ストレージは、プロビジョニングしたデータベースのサイズに制限されます。 バックアップ料金に従って、余分なバックアップ データに対して支払います。

• ゾーン冗長の高可用性でサーバーを構成しました。 2つのバックアップを取得しますか？その場合、2回課金されますか？

  No. HA サーバーまたは HA 以外のサーバーに関係なく、サービスはバックアップ コピーのセットを 1 つだけ保持します。 1 回だけ支払います。

復元に関連する質問

• サーバーを復元するにはどうすればよいですか?

  Azure では、すべてのサーバーでポイント・イン・タイム・リストアがサポートされています。 Azure ポータル、Azure CLI、API を使用して、最新の復元ポイントまたはカスタム復元ポイントに復元できます。

  pg_dumpなどのツールを使用して手動バックアップからサーバーを復元するには、最初にAzure Database for PostgreSQLフレキシブル サーバー インスタンスを作成してから、pg_restoreを使用してデータベースをサーバーに復元します。

• 同じリージョン内の別の可用性ゾーンに復元できますか?

  Yes. リージョンで複数の可用性ゾーンがサポートされている場合、バックアップはゾーン冗長ストレージ アカウントに格納されるので、別のゾーンに復元できます。

• ポイントインタイム リストアにはどのくらいの時間がかかりますか? 復元に長時間かかるのはなぜですか。

  スナップショットからのデータ復元操作は、データのサイズに依存しません。 ただし、ログ (再生するトランザクション アクティビティ) を適用する復旧プロセスのタイミングは、要求された日時の以前のバックアップと処理するログの数によって異なる場合があります。 この条件は、同じゾーン内での復元と、別のゾーンへのデータの復元の両方に適用されます。

• HA が有効になっているサーバーを復元した場合、復元サーバーは自動的に高可用性で構成されますか?

  No. サーバーは、単一インスタンスの Azure Database for PostgreSQL フレキシブル サーバー インスタンスとして復元されます。 復元が完了したら、必要に応じて、サーバーを高可用性で構成できます。

• 仮想ネットワーク内にサーバーを構成しました。 別の仮想ネットワークに復元できますか?

  Yes. 復元時に、復元先となる別の仮想ネットワークを選択してください。

• パブリック アクセス サーバーを仮想ネットワークに復元する (またはその逆) は可能ですか?

  No. 現在、Azure Database for PostgreSQL では、パブリック アクセスとプライベート アクセス間でのサーバーの復元はサポートされていません。

• 復元操作を追跡するにはどうすればいいですか?

  現在、復元操作を追跡する方法はありません。 アクティビティ ログを監視して、操作が進行中か、または完了しているかを確認できます。

関連コンテンツ

• 最新の復元ポイントの復元。
• カスタム復元ポイントの復元。
• 完全バックアップへの復元 (高速復元)。
• ペア リージョンの復元 (geo 復元)。