Azure Database for PostgreSQL (単一サーバー) でのバックアップと復元

適用対象: Azure Database for PostgreSQL - 単一サーバー

Azure Database for PostgreSQL は、サーバーのバックアップを自動的に作成し、ユーザーが構成したローカル冗長または geo 冗長ストレージに保存します。 バックアップを使用すると、サーバーを特定の時点に復元できます。 不慮の破損または削除からデータを保護するバックアップと復元は、ビジネス継続性戦略の最も重要な部分です。

バックアップ

Azure Database for PostgreSQL では、データ ファイルとトランザクション ログのバックアップが作成されます。 サポートされている最大ストレージ サイズに応じて、完全バックアップと差分バックアップ (最大 4 TB のストレージ サーバー) またはスナップショット バックアップ (最大 16 TB のストレージ サーバー) を使用します。 これらのバックアップを使用すると、サーバーを、バックアップの構成済みリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 これは、必要に応じて、最大 35 日に設定できます。 すべてのバックアップが、AES 256 ビット暗号化を使用して暗号化されます。

これらのバックアップ ファイルをエクスポートすることはできません。 バックアップは、Azure Database for PostgreSQL の復元操作にのみ使用できます。 pg_dump を使用して、データベースをコピーできます。

バックアップ頻度

最大 4 TB のストレージを持つサーバー

最大 4 TB の最大ストレージをサポートするサーバーでは、完全バックアップは毎週 1 回実行されます。 差分バックアップは 1 日に 2 回実行されます。 トランザクション ログ バックアップは 5 分ごとに実行されます。

最大 16 TB のストレージを持つサーバー

Azure リージョンのサブセットでは、新しくプロビジョニングされたすべてのサーバーで最大 16 TB のストレージがサポートされます。 これらの大規模なストレージ サーバー上のバックアップは、スナップショット ベースです。 初回の完全スナップショット バックアップは、サーバーの作成直後にスケジュールされます。 最初の完全スナップショット バックアップは、サーバーのベース バックアップとして保持されます。 以降のスナップショット バックアップでは、差分バックアップのみが行われます。 差分スナップショット バックアップは、固定のスケジュールでは実行されません。 1 日に差分スナップショット バックアップが複数回実行されますが、保持されるバックアップは 3 つだけです。 トランザクション ログ バックアップは 5 分ごとに実行されます。

注意

自動バックアップは、最大 4 TB のストレージ構成で構成されたレプリカ サーバーに対して実行されます。

バックアップ保有期間

バックアップは、サーバーのバックアップ保有期間の設定に基づいて保持されます。 7 日間から 35 日間までの保有期間を選択できます。 既定の保有期間は 7 日です。 Azure portal または Azure CLI を使用してバックアップ構成を更新することで、サーバーの作成中またはその後で保有期間を設定することができます。

バックアップのリテンション期間によって、現在からどのくらい遡ってポイントインタイム リストアを取得できるかが管理されます。ポイントインタイム リストアは使用可能なバックアップに基づいているためです。 バックアップの保有期間は、復元の観点から回復期間として扱うこともできます。 バックアップ保有期間内の特定の時点に復旧するために必要なすべてのバックアップは、バックアップ ストレージに保持されます。 たとえば、バックアップの保有期間が 7 日間に設定されている場合、回復期間は過去 7 日間と見なされます。 このシナリオでは、過去 7 日間のサーバーを復元するために必要なすべてのバックアップが保持されます。 バックアップ保有期間が 7 日間である場合:

  • 最大 4 TB のストレージを持つサーバーでは、最大 2 件までのデータベースの完全バックアップ、すべての差分バックアップ、およびデータベースの最初の完全バックアップからのトランザクション ログ バックアップが保持されます。
  • 最大 16 TB のストレージを持つサーバーでは、完全なデータベース スナップショット、すべての差分スナップショット、および過去 8 日間のトランザクション ログ バックアップが保持されます。

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

Azure Database for PostgreSQL では、汎用レベルとメモリ最適化レベルで、ローカル冗長バックアップ ストレージまたは geo 冗長バックアップ ストレージのいずれかを柔軟に選択できます。 geo 冗長バックアップ ストレージにバックアップが格納されると、ペアのリージョンに追加のバックアップ コピーがレプリケートされます。 これにより、地域災害の発生時に、より適切な保護が提供され、お使いのサーバーを復元することができます。 Basic レベルでは、ローカル冗長バックアップ ストレージのみが提供されます。

重要

バックアップに対してローカル冗長ストレージまたは geo 冗長ストレージを構成できるのは、サーバーの作成時だけです。 一度サーバーがプロビジョニングされると、バックアップ ストレージ冗長オプションを変更することはできません。

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

Azure Database for PostgreSQL は、プロビジョニングされているサーバー ストレージの 100% までをバックアップ ストレージとして追加コストなしで提供します。 バックアップ ストレージを追加で使用した場合は、1 か月ごとに GB 単位で請求されます。 たとえば、サーバーを 250 GB のストレージでプロビジョニングした場合は、サーバーのバックアップに 250 GB の追加のストレージを追加コストなしで利用できます。 250 GB を超えてバックアップに使用されているストレージについては、価格モデルに従って請求されます。

Azure portal で使用可能な Azure Monitor の使用されたバックアップ ストレージ メトリックを使用して、サーバーによって使用されるバックアップ ストレージを監視できます。 このバックアップ ストレージの使用量のメトリックは、サーバーに設定されているバックアップ保持間に基づいて保持されているすべてのデータベースの完全バックアップ、差分バックアップ、ログ バックアップによって使用されるストレージの合計を表します。 バックアップの頻度はサービスによって管理され、前に説明されています。 サーバーで大量のトランザクション アクティビティが発生すると、データベースの合計サイズに関係なく、バックアップ ストレージの使用量が増加する可能性があります。 geo 冗長ストレージの場合、バックアップ ストレージの使用量は、ローカル冗長ストレージの 2 倍になります。

バックアップ ストレージ コストを制御する主な方法は、適切なバックアップ保有期間を設定し、目的の回復目標を達成するための適切なバックアップ冗長オプションを選択することです。 7 日間から 35 日間までの保持期間を選択できます。 汎用サーバーとメモリ最適化サーバーでは、バックアップに geo 冗長ストレージを使用することを選択できます。

復元

Azure Database for PostgreSQL で復元を実行すると、元のサーバーのバックアップから新しいサーバーが作成されます。

使用できる復元には 2 つの種類があります。

  • ポイントインタイム リストアは、いずれのバックアップ冗長オプションでも使用でき、元のサーバーと同じリージョンに新しいサーバーが作成されます。
  • geo リストアは、サーバーを geo 冗長ストレージ用に構成した場合にのみ使用でき、ご利用のサーバーを別のリージョンに復元できます。

復旧の推定所要時間は、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅、同じリージョン内で同時に復旧するデータベースの合計数など、複数の要因によって異なります。 復旧時間は、最後のデータ バックアップ時期と、実行する必要がある復旧の量によって異なります。 通常は 12 時間もかかりません。

注意

ソース PostgreSQL サーバーがカスタマー マネージド キーで暗号化されている場合、追加の考慮事項についてはこちらのドキュメントを参照してください。

注意

削除した PostgreSQL サーバーを復元する場合、こちらの手順に従います。

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

バックアップ冗長オプションに関係なく、バックアップのリテンション期間内の任意の時点への復元を実行できます。 新しいサーバーは、元のサーバーと同じ Azure リージョンに作成されます。 価格レベル、コンピューティング世代、仮想コア数、ストレージ サイズ、バックアップのリテンション期間、およびバックアップ冗長オプションについては、元のサーバーの構成を使用して作成されます。

ポイントインタイム リストアは複数のシナリオで役に立ちます。 たとえば、ユーザーが誤ってデータを削除したとき、重要なテーブルやデータベースを削除したとき、またはアプリケーションの不具合が原因で、適切なデータが不適切なデータで誤って上書きされた場合などです。

現時点から遡って 5 分前より後の時点に復元するには、次のトランザクション ログのバックアップが作成されるのを待たなければならない可能性があります。

削除されたテーブルを復元する場合、

  1. ポイントインタイムの手法でソース サーバーを復元します。
  2. 復元されたサーバーから pg_dump を利用してテーブルをダンプします。
  3. 元のサーバーでソース テーブルの名前を変更します。
  4. 元のサーバーで psql コマンド ラインを使用してテーブルをインポートします。
  5. 必要に応じて、復元されたサーバーを削除できます。

注意

同じサーバーに対して複数の復元を同時に行うことは推奨されません。

geo リストア

geo 冗長バックアップ用にサーバーを構成した場合は、サービスを使用できる別の Azure リージョンにサーバーを復元できます。 最大 4 TB のストレージをサポートするサーバーは、geo ペアリージョンに、または 最大 16 TB のストレージをサポートする任意のリージョンに、復元することができます。 最大 16 TB のストレージをサポートするサーバーでは、16 TB のサーバーをサポートするリージョンにも、geo バックアップを復元できます。 サポートされているリージョンの一覧については、Azure Database for PostgreSQL の価格レベルに関するページをご確認ください。

geo リストアは、サーバーがホストされているリージョンでのインシデントが原因でサーバーが利用できない場合の既定の復旧オプションです。 リージョン内の大規模なインシデントにより、データベース アプリケーションが使用できなくなった場合、geo 冗長バックアップから他の任意のリージョン内のサーバーに、サーバーを復元できます。 バックアップが取得される時刻と、別のリージョンにそのバックアップがレプリケートされる時刻には時間差があります。 この時間差は最大 1 時間なので、障害が発生した場合、最大 1 時間分のデータが損失する可能性があります。

geo リストア中に変更できるサーバー構成は、コンピューティング世代、仮想コア、バックアップの保有期間、バックアップ冗長オプションなどです。 価格レベル (Basic、汎用、またはメモリ最適化) とストレージのサイズはいずれも変更できません。

注意

ソース サーバーでインフラストラクチャ二重暗号化が使用されている場合、サーバーの復元については、利用できるリージョンなど、制限があります。 詳細については、インフラストラクチャ二重暗号化に関するページを参照してください。

復元後のタスクの実行

いずれかの復旧メカニズムで復元した後、ユーザーとアプリケーションを元に戻して実行するには、次のタスクを実行する必要があります。

  • 復元されたサーバーにアクセスするには、元のサーバーとは名前が異なるため、接続文字列で、サーバー名を復元されたサーバー名に、ユーザー名を username@new-restored-server-name に変更してください。
  • 元のサーバーを新しいサーバーで置き換える場合は、クライアントとクライアント アプリケーションを新しいサーバーにリダイレクトする。
  • ユーザーが接続できるように、適切なサーバー レベルのファイアウォールと VNet ルールが適用されていることを確認します。 これらのルールは配信元のサーバーからはコピーされません。
  • 適切なログインとデータベース レベルのアクセス許可が適切に指定されていることを確認する
  • 必要に応じて、アラートを構成する

次のステップ

  • Azure portal を使用して復元する方法について学習します。
  • Azure CLI を使用して復元する方法について学習します。
  • ビジネス継続性の詳細については、ビジネス継続性の概要に関するページを参照してください。