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

[アーティクル]
02/11/2024

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

重要

Azure Database for PostgreSQL - シングルサーバーは廃止パスにあります。 Azure Database for PostgreSQL - フレキシブルサーバーにアップグレードすることを強くお勧めします。 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 分前より後の時点に復元するには、次のトランザクションログのバックアップが作成されるのを待たなければならない可能性があります。

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

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

注意

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

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 Backup と Azure Database for PostgreSQL サーバーサービスでは、最大 10 年間バックアップを保持する Azure Database for PostgreSQL シングルサーバーインスタンス用のエンタープライズクラスの長期的なバックアップソリューションが構築されました。長期保有は、独立して使用することも、Azure Database for PostgreSQL シングルサーバーによって提供され、最大 35 日間のデータ保有を行える自動バックアップソリューションに加えて使用することもできます。自動バックアップは、特に最新のバックアップから復元する場合に、運用復旧に適した物理バックアップです。長期的なバックアップは、コンプライアンスのニーズを満たすのに役立ち、より細かく、ネイティブ pg_dumpを使用した論理バックアップとして取得されます。このソリューションには、長期保有に加えて、次の機能が用意されています:

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

長期的なバックアップの実行の詳細については、「攻略ガイド」を参照してください。
既知の [LTR の問題]。

次のステップ

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