Azure Database for PostgreSQL (フレキシブル サーバー) でのバックアップと復元
適用対象: 
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 つのオプションがあります。
ゾーン冗長バックアップ ストレージ: 可用性ゾーンをサポートしているリージョンには、このオプションが自動的に選択されます。 バックアップがゾーン冗長バックアップ ストレージに保存されている場合、複数のコピーが同じ可用性ゾーン内に保存されるだけでなく、同じリージョン内の別の可用性ゾーンにもレプリケートされます。
このオプションにより、可用性ゾーン全体でバックアップ データを使用でき、データのレプリケーションを国/リージョン内に制限して、データ所在地要件を満たします。 このオプションによって、バックアップ オブジェクトの年間 99.9999999999% (9 が 12 個) 以上の持続性が実現されます。
ローカル冗長バックアップ ストレージ: 可用性ゾーンがまだサポートされていないリージョンには、このオプションが自動的に選択されます。 バックアップがローカル冗長バックアップ ストレージに格納されると、バックアップの複数のコピーが、同じデータセンター内に格納されます。
このオプションは、サーバー ラックとドライブの障害からデータを保護するのに役立ちます。 これにより、バックアップ オブジェクトの年間 99.999999999% (9 が 11 個) 以上の持続性が実現されます。
既定では、同一ゾーンの高可用性 (HA) を使用しているサーバー、または高可用性構成のないサーバーのバックアップ ストレージは、ローカル冗長に設定されます。
geo 冗長バックアップ ストレージ: このオプションは、サーバーの作成時に選択できます。 バックアップが geo 冗長バックアップ ストレージに格納されると、サーバーがホストされているリージョンに 3 つのデータのコピーが格納されるのに加えて、その geo ペア リージョンにもデータがレプリケートされます。
このオプションを使用すると、障害が発生した場合に別のリージョンのサーバーを復元できます。 さらにこれにより、バックアップ オブジェクトの年間 99.99999999999999% (9 が 16 個) 以上の持続性が実現されます。
Geo 冗長性は、Azure のペアになっているリージョンのいずれかでホストされているサーバーでサポートされます。
他のバックアップ ストレージ オプションから geo 冗長バックアップ ストレージへの移行
バックアップ用 geo 冗長ストレージは、サーバーの作成時にのみ構成できます。 サーバーがプロビジョニングされると、バックアップ ストレージ冗長オプションを変更することはできません。
バックアップ保有期間
バックアップは、サーバーに設定した保持期間に基づいて保持されます。 7 日間 (既定) から 35 日間までの保持期間を選択できます。 サーバーの作成時に保持期間を設定することも、後で変更することもできます。 停止したサーバーでもバックアップは保持されます。
バックアップ保有期間は、利用可能なバックアップを使用して ポイントインタイム リストア を取得できる期間を制御します。 バックアップ保持期間は、復元の観点から回復期間として扱うこともできます。
バックアップの保持期間内のポイントインタイム リストアの実行に必要なすべてのバックアップは、バックアップ ストレージに保持されます。 たとえば、バックアップの保持期間が 7 日間に設定されている場合、回復期間は過去 7 日間になります。 このシナリオでは、過去 7 日間のサーバーを復元および復旧するために必要なすべてのデータとログが保持されます。
バックアップ ストレージのコスト
Azure Database for PostgreSQL フレキシブル サーバーは、プロビジョニングされたサーバー ストレージの最大 100% をバックアップ ストレージとして追加コストなしで提供します。 使用する追加のバックアップ ストレージは、1 か月ごとにギガバイト単位で請求されます。
たとえば、サーバーを 250 ギビバイト (GiB) のストレージでプロビジョニングした場合は、250 GiB のバックアップ ストレージ容量を追加料金なしで利用できます。 毎日のバックアップ使用量が 25 GiB の場合は、最大 10 日間の無料バックアップ ストレージを使用できます。 250 GiB を超えるバックアップ ストレージの使用は、価格モデルに定義されているとおりに課金されます。
geo 冗長バックアップを使用してサーバーを構成した場合は、バックアップ データも Azure ペア リージョンにコピーされます。 そのため、バックアップ サイズはローカル バックアップ コピーのサイズの 2 倍になります。 課金は、 ( (2 x ローカル バックアップ サイズ) - プロビジョニングされたストレージ サイズ ) x 1 か月あたりの価格 @ ギガバイトとして計算されます。
Azure portal で 使用済みバックアップ ストレージ メトリックを使用して、サーバーによって使用されるバックアップ ストレージを監視できます。 使用済みバックアップ ストレージ メトリックは、サーバーに設定されているバックアップ保持期間に基づいて、保持されるすべてのデータベース バックアップとログ バックアップによって使用されたストレージの合計を表します。
注意
データベースのサイズとは無関係に、サーバーで大量のトランザクション アクティビティが発生すると多くの WAL ファイルが生成されます。 ファイルが増えると、バックアップ ストレージが増加します。
ポイントインタイム リストア
Azure Database for PostgreSQL フレキシブル サーバーでは、ポイントインタイム リストアを実行すると、ソース サーバーと同じリージョンに新しいサーバーが作成されますが、ユーザーは可用性ゾーンを選択できます。 価格レベル、コンピューティング世代、仮想コア数、ストレージ サイズ、バックアップの保持期間、およびバックアップ冗長オプションについては、ソース サーバーの構成を使用して作成されます。 また、仮想ネットワークやファイアウォール設定などのタグと設定は、ソース サーバーから継承されます。
物理データベース ファイルは、最初にスナップショット バックアップからサーバーのデータの場所に復元されます。 目的の時点より前に作成された適切なバックアップが自動的に選択され、復元されます。 その後、WAL ファイルを使用して復旧プロセスが開始されて、データベースが一貫性のある状態になります。
たとえば、バックアップが毎晩、午後 11 時に実行されているとします。 復元ポイントが 8 月 15 日午前 10 時の場合は、8 月 14 日の日次バックアップが復元されます。 データベースは、8 月 15 日午前 10 時までは、8 月 14 日午後 11 時から 8 月 15 日午前 10 時までのトランザクション ログのバックアップを使用して復旧されます。
データベース サーバーを復元するには、こちらの手順を参照してください。
重要
Azure Database for PostgreSQL フレキシブル サーバーでの復元操作では常に、ユーザーが指定した名前で新しいデータベース サーバーが作成されます。 既存のデータベース サーバーは上書きされません。
ポイントインタイム リストアは、次のようなシナリオで役立ちます。
- ユーザーがデータ、テーブル、またはデータベースを誤って削除する。
- アプリケーションの欠陥のため、正しいデータが不適切なデータで誤って上書きされる。
- テスト、開発、またはデータ検証のためにサーバーを複製する必要があります。
トランザクション ログの継続的バックアップを使うと、最後のトランザクションに復元できます。 次の復元オプションのいずれかを選択できます。
最新の復元ポイント (現在): これは既定のオプションであり、サーバーを最新の時点に復元できます。
カスタム復元ポイント: このオプションを使うと、この Azure Database for PostgreSQL フレキシブル サーバー インスタンスに定義されている保持期間内の任意の時点を選択できます。 既定で、UTC の最新時刻が自動的に選択されます。 自動選択は、テスト目的で最後にコミットされたトランザクションに復元する場合に便利です。 任意で他の日時を選択できます。
高速復元ポイント: このオプションを使うと、ユーザーは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに対して定義された保持期間内で、可能な限り速くサーバーを復元できます。 バックアップの一覧からタイムスタンプを直接選択することで、最速に復元できます。 この復元操作では、サーバーがプロビジョニングされ、スナップショットの完全バックアップが復元されるだけで、ログの復旧が不要になり、高速になります。 バックアップ タイムスタンプを選択することをお勧めします。バックアップ タイムスタンプは、復元操作が正常に完了した時点の最も古い復元ポイントよりも大きくなります。
最新の復元ポイント オプションとカスタム復元ポイント オプションを使用して復旧するために必要な時間は、前回のバックアップ以降に処理するトランザクション ログの量や、同じリージョンで同時に復旧されるデータベースの合計数などの要因によって異なります。通常、全体的な復旧時間は数分から数時間かかります。
仮想ネットワーク内でサーバーを構成する場合は、同じ仮想ネットワークまたは別の仮想ネットワークに復元できます。 ただし、パブリック アクセスには復元できません。 同様に、パブリック アクセスでサーバーを構成した場合、プライベート仮想ネットワーク アクセスへの復元はできません。
重要
削除されたサーバーを復元することはできません。 サーバーを削除した場合は、削除された Azure Database for PostgreSQL フレキシブル サーバーの復元に関する記事のガイダンスに従って復元できます。 Azure リソース ロックを使用すると、サーバーが誤って削除されるのを防ぐことができます。
geo 冗長バックアップと復元
geo 冗長バックアップを有効にするには、Azure portal の [コンピューティングとストレージ] ウィンドウから行います。クイックスタート ガイドを参照してください。
重要
geo 冗長バックアップの構成は、サーバーの作成時にのみ行うことができます。
geo 冗長バックアップを使用してサーバーを構成した後、 geo ペアリージョンに復元できます。 詳細については、geo 冗長バックアップでサポートされているリージョンに関するページを参照してください。
サーバーが geo 冗長バックアップで構成されている場合、バックアップ データとトランザクション ログは、ストレージ レプリケーションを使用してペア リージョンに非同期的にコピーされます。 サーバーの作成後、少なくとも 1 時間待ってから geo リストアを開始してください。 これにより、バックアップ データの最初のセットをペアのリージョンにレプリケートできます。
その後、トランザクション ログと毎日のバックアップは、ペアになっているリージョンに非同期的にコピーされます。 データ転送では、最大 1 時間の延期期間が発生する可能性があります。 そのため、復元するときに見込まれる RPO は最大で 1 時間です。 復元できるのは、ペア リージョンで見つかる最新の使用可能なバックアップ データのみです。 現時点では、geo 冗長バックアップのポイントインタイム リストアは使用できません。
サーバーの復旧にかかる推定時間 (目標復旧時間、RTO) は、データベースのサイズ、データベースの最終バックアップ時刻、最後に受信されたバックアップ データに至るまでに処理する WAL の量などの要因によって異なります。 全体的な復旧時間は、通常は数分から数時間かかります。
geo リストア中に変更できるサーバー構成には、仮想ネットワーク設定や、復元されるサーバーから geo 冗長バックアップを削除する機能が含まれます。 geo リストアの間に、コンピューティング、ストレージ、価格レベル (バースト可能、General Purpose、メモリ最適化) などの他のサーバー構成を変更することはできません。
geo リストアの実行の詳細については、攻略ガイドを参照してください。
重要
プライマリ リージョンがダウンすると、プライマリ リージョンでストレージをプロビジョニングできないため、対応する geo ペア リージョン内に geo 冗長サーバーを作成することができません。 geo ペア リージョンで geo 冗長サーバーをプロビジョニングする前に、プライマリ リージョンが稼働するまで待機する必要があります。
プライマリ リージョンがダウンしていても、ソース サーバーを geo ペア リージョンに geo リストアすることはできます。 geo リストアの実行の詳細については、攻略ガイドを参照してください。 任意のリージョンに DR を構成する必要があるか、プライマリ リージョンが geo 冗長バックアップをサポートしていない場合、ディザスター リカバリー (DR) 戦略として geo レプリカを使用する必要があります
復元とネットワーク
ポイントインタイム リストア
ソース サーバーがパブリック アクセス ネットワークを使用して構成されている場合は、パブリック アクセスにのみ復元できます。
ソース サーバーがプライベート アクセス仮想ネットワークで構成されている場合は、同じ仮想ネットワークまたは別の仮想ネットワークに復元できます。 パブリック アクセスとプライベート アクセスをまたいでポイントインタイム リストアを実行することはできません。
geo リストア
ソース サーバーがパブリック アクセス ネットワークを使用して構成されている場合は、パブリック アクセスにのみ復元できます。 ソース サーバーの既存のファイアウォール規則は、復元されたサーバーにコピーされます。 プライベート エンドポイントは引き継がれません。 復元操作が完了したら、引き継がれたファイアウォール規則を調整する必要があるかどうかを確認し、必要なプライベート エンドポイントを作成します。
ソース サーバーがプライベート アクセス仮想ネットワークを使用して構成されている場合は、仮想ネットワークがリージョンをまたがることはできないため、別の仮想ネットワークにのみ復元できます。 パブリック アクセスとプライベート アクセスをまたいで geo リストアを実行することはできません。
復元後のタスク
サーバーを復元した後、次のタスクを実行して、ユーザーとアプリケーションを元に戻して稼働させることができます。
元のサーバーを新しいサーバーで置き換える場合は、クライアントとクライアント アプリケーションを新しいサーバーにリダイレクトする。 新しいサーバーを指すように、接続文字列のサーバー名を変更します。
ユーザー接続に対して、適切なサーバー レベルのファイアウォール、プライベート エンドポイント、仮想ネットワーク規則が適用されていることを確認します。 "パブリック アクセス" ネットワークでは、規則は元のサーバーからコピーされますが、それらは復元された環境で必要なものではない場合があります。 そのため、要件に応じて調整してください。 プライベート エンドポイントは引き継がれません。 復元されたサーバーに必要なプライベート エンドポイントを作成します。 "プライベート アクセス" 仮想ネットワークでは、復元によって、ネットワーク インフラストラクチャ成果物はソースから復元されたサーバー ネットワークにコピーされません。 VNET、サブネット、またはネットワーク セキュリティ グループの構成に関連するものはすべて、復元後のタスクとして処理する必要があります。
必要に応じて、復元されたサーバーのコンピューティングをスケールアップまたはスケールダウンします。
適切なログインとデータベースレベルのアクセス許可が指定されていることを確認します。
必要に応じてアラートを構成します。
復元元のソース サーバーが高可用性で構成されており、かつ復元されたサーバーを高可用性で構成する場合は、こちらの手順に従うことができます。
復元元のソース サーバーが読み取りレプリカで構成されていた場合に、復元されたサーバーで読み取りレプリカを構成したいときは、こちらの手順に従って行うことができます。
長期保有 (プレビュー)
Azure Backup サービスと Azure Database for PostgreSQL フレキシブル サーバー サービスでは、最大 10 年間バックアップを保持する Azure Database for PostgreSQL フレキシブル サーバー インスタンス用のエンタープライズ クラスの長期的なバックアップ ソリューションが構築されています。 長期保有は、独立して使うことも、Azure Database for PostgreSQL フレキシブル サーバーによって提供される自動バックアップ ソリューションに加えて使うこともでき、最大 35 日間のデータ保持が提供されます。 自動バックアップは、特に最新のバックアップから復元する場合に、運用復旧に適した物理バックアップです。 長期的なバックアップは、コンプライアンスのニーズを満たすのに役立ち、より細かく、ネイティブ pg_dumpを使用した論理バックアップとして取得されます。 このソリューションには、長期保有に加えて、次の機能が用意されています:
- 個々のデータベース レベルで、顧客がコントロールするスケジュールされたバックアップとオンデマンド バックアップ。
- すべての操作とジョブの一元的な監視。
- バックアップは、個別のセキュリティ ドメインと障害ドメインに保存されます。 ソース サーバーまたはサブスクリプションが侵害された場合、Backupコンテナー (Azure Backup マネージド ストレージ アカウント) でバックアップは安全なままです。
- pg_dumpを使用すると、異なるデータベース バージョン間でデータを復元する柔軟性が向上します。
- Azure Backup コンテナーでは、不変性と論理的な削除 (プレビュー) フィーチャーがサポートされ、データが保護されます。
- CMK が有効なサーバーでの LTR バックアップのサポート
制限と考慮事項
- プレビューでは、LTR 復元は現在、ストレージ アカウントへの RestoreasFiles として使用できます。 RestoreasServer 機能は、今後追加される予定です。
- プレビューでは、すべてのデータベースに対する LTR バックアップを実行でき、将来的には単一 DB のバックアップのサポートが追加される予定です。
- 現在、LTR バックアップは geo レプリカではサポートされていません。 ただし、プライマリ サーバーから LTR バックアップを実行できます。
長期バックアップの実行について詳しくは、攻略ガイドをご覧ください。
よく寄せられる質問
バックアップに関連する質問
サーバーのバックアップは Azure でどのように処理されますか?
Azure Database for PostgreSQL フレキシブル サーバーではサーバー全体 (作成されたすべてのデータベースを含む) の自動バックアップが既定で有効になり、既定の保持期間は 7 日です。 自動バックアップには、データベースの毎日の増分スナップショットが含まれます。 ログ (WAL) ファイルは、Azure Blob Storage に継続的にアーカイブされます。
自動バックアップが長期間保有されるように構成できますか?
いいえ。 現在、Azure Database for PostgreSQL フレキシブル サーバーでは最大 35 日間のデータ保持がサポートされています。 手動バックアップを長期保有の要件に使用できます。
Azure Database for PostgreSQL フレキシブル サーバー インスタンスを手動でバックアップするにはどうすればよいですか?
手動でのバックアップは、PostgreSQL ツール pg_dump を使用して行うことができます。 例については、ダンプと復元を使用した Azure Database for PostgreSQL フレキシブル サーバー データベースの移行に関する記事をご覧ください。
Azure Database for PostgreSQL フレキシブル サーバーを Blob Storage にバックアップする場合は、技術コミュニティのブログの「Azure Database for PostgreSQL を Blob Storage にバックアップする」をご覧ください。
サーバーのバックアップ ウィンドウとは何ですか? それらをカスタマイズできますか?
Azure によってバックアップの時間帯が管理され、ユーザーはカスタマイズできません。 初回の完全スナップショット バックアップは、サーバーの作成直後にスケジュールされます。 後続のスナップショット バックアップは、増分バックアップで 1 日に 1 回実行されます。
バックアップは暗号化されますか?
はい。 Azure Database for PostgreSQL フレキシブル サーバーのすべてのデータ、バックアップ、クエリの実行中に作成される一時ファイルは、AES 256 ビット暗号化を使って暗号化されます。 ストレージの暗号化は常にオンになっており、無効にすることはできません。
サーバーの単一または少数のデータベースを復元できますか?
単一または少数のデータベースやテーブルの復元は直接サポートされていません。 ただし、サーバー全体を新しいサーバーに復元してから、テーブルまたはデータベースを抽出して、新しいサーバーにインポートできます。
バックアップの進行中はサーバーを使用できますか?
はい。 バックアップは、スナップショットを使用するオンライン操作です。 スナップショット操作には数秒しかかからず、運用環境のワークロードには影響しないため、サーバーの高可用性を確保できます。
サーバーのメンテナンス期間を設定するときに、バックアップの時間帯を考慮する必要がありますか?
いいえ。 バックアップは管理サービスの一部として内部的にトリガーされ、メンテナンス期間には関係ありません。
自動バックアップはどこに格納され、その保持期間はどのように管理できますか?
Azure Database for PostgreSQL フレキシブル サーバーは、サーバーのバックアップを自動的に作成して、それらを次の場所に格納します。
- 複数のゾーンがサポートされているリージョンのゾーン冗長ストレージ。
- 複数のゾーンをまだサポートしていないリージョンのローカル冗長ストレージ。
- geo 冗長バックアップを構成する場合は、ペアのリージョン。
これらのバックアップ ファイルをエクスポートすることはできません。
バックアップは、サーバーを特定の時点に復元するためにのみ使用できます。 バックアップの既定の保持期間は 7 日間です。 必要に応じて、バックアップのリテンション期間を最大 35 日に構成できます。
geo 冗長バックアップの使用時に、バックアップはどれほどの頻度でペア リージョンにコピーされますか?
geo 冗長バックアップを使用してサーバーが構成されている場合、バックアップ データは geo 冗長ストレージ アカウントに格納されます。 ストレージ アカウントでは、プライマリ サーバーで毎日のバックアップが行われるときに、ペア リージョンにデータ ファイルがコピーされます。 WAL ファイルは、それらをアーカイブする準備が整ったときにバックアップされます。
バックアップ データは、非同期に、連続的な方法でペア リージョンにコピーされます。 バックアップ データの受信については、最大 1 時間の延期期間が見込まれます。
リモート リージョンで PITR を実行できますか?
いいえ。 データは、リモート リージョンで使用できる最新のバックアップデータに復旧されます。
HA が有効になっているサーバーではバックアップはどのように実行されますか?
Azure Database for PostgreSQL フレキシブル サーバーのデータ ボリュームは、プライマリ サーバーからマネージド ディスクの増分スナップショットを使ってバックアップされます。 WAL バックアップは、プライマリ サーバーまたはスタンバイ サーバーから実行されます。
サーバーでバックアップが実行されているのを確認するにはどうすればよいですか?
バックアップを確認する最善の方法は、定期的なポイントインタイム リストアを実行し、バックアップが有効で復元可能であることを確認することです。 バックアップ操作またはファイルは、エンド ユーザーには公開されません。
バックアップの使用量はどこで確認できますか?
Azure portal の [監視] で [メトリック] を選択します。 [使用済みバックアップ ストレージ] で、バックアップの合計使用量を監視できます。
サーバーを削除した場合、バックアップはどうなりますか?
サーバーを削除すると、そのサーバーに属するバックアップもすべて削除され、復旧できなくなります。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを使用できます。
停止したサーバーのバックアップはどのように保有されますか?
停止したサーバーに対して、新しいバックアップは実行されません。 サーバーを停止した時点でのすべての古いバックアップ (保持期間内のもの) は、サーバーが再起動されるまで保持されます。 その後、アクティブなサーバーのバックアップの保持は、そのバックアップ保持期間によって管理されます。
バックアップの課金と請求はどのように行われますか?
Azure Database for PostgreSQL フレキシブル サーバーは、プロビジョニングされたサーバー ストレージの最大 100% をバックアップ ストレージとして追加コストなしで提供します。 使用するバックアップ ストレージを増やすと、価格モデルで定義されているように、1 か月ごとにギガバイト単位で請求されます。
選択したバックアップ保持期間とバックアップ冗長オプションは、サーバー上のトランザクション アクティビティと共に、バックアップ ストレージと請求の合計に直接影響します。
停止しているサーバーについては、どのように請求されますか?
サーバー インスタンスが停止している間は、新しいバックアップは実行されません。 プロビジョニングされたストレージとバックアップ ストレージ (指定した保有期間内に格納されたバックアップ) に対して課金されます。
無料バックアップ ストレージは、プロビジョニングしたデータベースのサイズに制限されます。 超えたバックアップ データは、バックアップ価格に従って課金されます。
ゾーン冗長の高可用性でサーバーを構成しました。 2 つのバックアップが取得されるので、2 回課金されますか?
いいえ。 HA か非 HA サーバーかに関係なく、1 セットのバックアップ コピーのみが保持されます。 1 回だけ課金されます。
復元に関連する質問
サーバーを復元するにはどうすればよいですか?
Azure では、すべてのサーバーでポイントインタイム リストアがサポートされています。 ユーザーは、Azure portal、Azure CLI、および API を使用して、最新の復元ポイントまたはカスタムの復元ポイントに復元できます。
pg_dump などのツールを使って行った手動バックアップからサーバーを復元するには、最初に Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成し、次に pg_restore を使ってデータベースをサーバーに復元します。
同じリージョン内の別の可用性ゾーンに復元できますか?
はい。 リージョンで複数の可用性ゾーンがサポートされている場合、バックアップはゾーン冗長ストレージ アカウントに格納されるので、別のゾーンに復元できます。
ポイントインタイム リストアにはどのくらいの時間がかかりますか? 復元に長時間かかるのはなぜですか。
スナップショットからのデータ復元操作は、データのサイズに依存しません。 ただしログ (再生するトランザクション アクティビティ) を適用する復旧プロセスのタイミングは、要求された日付/時刻の前のバックアップと処理するログの量によって異なる可能性があります。 これは、同じゾーン内の復元と別のゾーンへの復元のどちらにも当てはまります。
HA が有効になっているサーバーを復元した場合、復元サーバーは自動的に高可用性で構成されますか?
いいえ。 サーバーは、単一インスタンスの Azure Database for PostgreSQL フレキシブル サーバー インスタンスとして復元されます。 復元が完了したら、必要に応じて、サーバーを高可用性で構成できます。
仮想ネットワーク内にサーバーを構成しました。 別の仮想ネットワークに復元できますか?
はい。 復元時に、復元先となる別の仮想ネットワークを選択してください。
パブリック アクセス サーバーを仮想ネットワークに復元する (またはその逆) は可能ですか?
いいえ。 現在、パブリック アクセスとプライベート アクセスをまたがる Azure Database for PostgreSQL フレキシブル サーバーの復元はサポートされていません。
復元操作を追跡するにはどうすればいいですか?
現在、復元操作を追跡する方法はありません。 アクティビティ ログを監視して、操作が進行中か、または完了しているかを確認できます。