Azure Backupは、物理(ディスクスナップショット)バックアップでAzure PostgreSQLのフレキシブルサーバーやエラスティッククラスターを保護することを可能にします。 本記事では、v2体験のサポート領域、シナリオ、構成、制限をまとめます。
Azure PostgreSQLのフレキシブルサーバーおよびエラスティッククラスターのヴォルトバックアップ(v2)でサポートされているリージョン
ヴォールトバックアップは、オーストリア東部、ベルギー中部、チリ中央部、インドネシア中央部、イスラエル北西部、マレーシア南部、マレーシア西部、メキシコ中央部、カタール中央部、南中部US 2、南東米国、南東部US 3、南東米国5、南西米国、西インドを除くすべての公開地域で利用可能です。
Azure PostgreSQLのフレキシブルサーバーおよびエラスティッククラスターのヴォルテッドバックアップ(v2)に対応したデータソースと設定
以下の表は、Azure PostgreSQLフレキシブルサーバーおよびエラスティッククラスターのヴォールトバックアップ(v2)に対応しているデータソースと構成を示しています。
| 品目 | Support |
|---|---|
| Azure Database for PostgreSQL - フレキシブル サーバー | サポートされている |
| Azure Database for PostgreSQL elastic cluster | サポートされている |
| PostgreSQLメジャーバージョン | PostgreSQL 15以降 |
| コンピューティング レベル | 汎用およびメモリ最適化 |
| ディスクの種類と最大サイズ | プレミアムSSD v1は最大32TBまで;プレミアムSSD v2は最大64TBまで |
| サーバーの役割 | プライマリサーバーのみ |
| サーバーまたはクラスタ上のカスタマーマネージドキー | サポートされている |
| ソースサーバーで高可用性が有効化されています | サポートされている |
| 仮想ネットワークまたはソースサーバーまたはクラスタ上のプライベートエンドポイント | Trusted Accessによるサポート |
| バックアップ金庫の場所 | データソースと同じ領域にいる必要があります |
| バックアップボールトサブスクリプション | 同じサブスクリプションでも異なるサブスクリプションでも、データソースと同じテナント内で設定しています |
| カスタマーマネージドキー暗号化によるバックアップボールト | サポートされている |
| バックアップボールトの不可変性(WORM) | Supported. 回復ポイントは不変にできるため、保持期間が切れる前に変更や削除ができません。 |
| ソフト削除、マルチユーザー認証、そしてボールトでのマルチファクター認証 | サポートされている |
| ユーザー指定のマネージド ID | データソースおよびバックアップボールトの権限付与に対応しています |
Azure PostgreSQLのフレキシブルサーバーおよびエラスティッククラスターのヴォルテッドバックアップ(v2)に対応したバックアップシナリオ
Azure PostgreSQLのフレキシブルサーバーおよびエラスティッククラスターのヴォールトバックアップ(v2)は、以下のバックアップシナリオをサポートしています:
- サーバーやクラスター全体がバックアップされています。 個別のデータベースのバックアップはサポートされていません。
- 最大8ノードまでのエラスティッククラスターもサポートされています。
- データソースの最初のバックアップは完全なバックアップであり、その後のすべてのバックアップは増分的です。 スナップショットチェーンが途切れている場合、Azure Backupは自動的に初期レプリケーションを再度実行します。
- 日次または週次のバックアップスケジュールをサポートしており、最低回復ポイント目標は1日です。
- 保持期間は7日から最大10年まで設定可能で、日次、週次、月次、年次の回復期間ごとに独立した期間があります。
- 保護設定後はオンデマンド(アドホック)バックアップもサポートされます。
- データソースごとに1つのバックアップインスタンスがサポートされています。 同じサーバーの複数保護はサポートされていないため、サーバーはv1スタックかv2スタックのいずれかで保護され、両方で保護されることはありません。
- バックアップインスタンスに関連付けられたバックアップポリシーは、保護設定後に変更可能です。
- 管理ディスクのスナップショットがボールトにコピーされた時点で、バックアップジョブは 成功 とマークされます。
- 復元ポイントのメタデータ(バックアップが取られたPostgreSQLバージョンを含む)は、各復元ポイントで確認できます。
- WORMの不変バックアップもサポートしています。 バックアップボールトで不可変性が有効かつロックされている場合、復元ポイントは設定された保持期間が満了する前に、管理者を含むどのユーザーも変更、上書き、削除できません。
Azure PostgreSQLのフレキシブルサーバーおよびエラスティッククラスターのヴォルテッドバックアップ(v2)に対応した復元シナリオ
Azure PostgreSQLのフレキシブルサーバーおよびエラスティッククラスターのヴォールトバックアップ(v2)は、以下のリストアシナリオをサポートしています:
- 復元は「 サーバーとして復元 」として別の場所へ行います。 復元がトリガーされる前に、ターゲットとなる柔軟なサーバーまたはエラスティッククラスターが作成される必要があります。
- ログされていないテーブル内のデータは保存されず、復元時に失われます。
- ターゲットは同じテナント内の別のサブスクリプションに存在することがあります。
- 地域横断復元もサポートしています。
- サポート終了のPostgreSQLバージョンで取得したバックアップからの復元操作は保証されません。
- 復元は、元のデータソースが削除された後でもサポートされています。
- 復元ジョブが「 成功 」と表示されるのは、回復ポイント全体が復元されたときだけです。
- Premium SSD v1サーバーで取得したリカバリーポイントは、Premium SSD v1のターゲットに復元されます。 Premium SSD v2サーバーで回復ポイントを取ると、Premium SSD v2のターゲットに復元されます。
復元のための目標要件
ターゲットとなる柔軟なサーバーまたはエラスティッククラスターは、復元作業開始前にAzure Backupが検証する以下のすべての条件を満たす必要があります。
- サーバーまたはクラスタは空でなければなりません。
- サーバーやクラスターはBurstableのコンピュート層にあってはなりません。
- バックアップが取られた際、ターゲットサーバーやクラスタはソースサーバーと同じPostgreSQLメジャーバージョンを使用しなければなりません。バージョンが一致しない場合、復元は失敗します。
- ターゲットサーバーまたはクラスタは、ソースサーバーと同じディスクサイズでなければなりません。 復旧は、目標ディスクのサイズが元のディスクサイズより小さい場合に失敗します。リカバリーポイントはターゲットディスクの容量が少なくて済みます。
- サーバーやクラスタは高可用性を設定してはいけません。
- サーバーやクラスタにはジオレプリカが設定されてはならず、またそのサーバー自体がジオレプリカであってはなりません。
- サーバーまたはクラスターはバックアップボールトと同じリージョンにある必要があります。
Azure PostgreSQL flexible server and elastic cluster vaulted backup (v2) の制限
v2の体験には以下の制限があります:
- アイテムレベルのバックアップと復元はサポートされていません。 個々のデータベース、テーブル、オブジェクトのバックアップや復元はできません。
- Burstable Compute tierはサポートされていません。 Burstableサーバーでのバックアップ設定はユーザーエラーで失敗します。 まずサーバーを汎用またはメモリ最適化にスケーリングしてください。
- PostgreSQL 14以前はサポートされていません。 これらのバージョンを使用するサーバーではバックアップ設定が失敗します。 バックアップを設定する前に 、サポートされているメジャーバージョンにアップグレード するか、v1でサーバーを保護し続ける必要があります。
- バックアップはプライマリサーバーのみでサポートされています。 読み取りレプリカやジオレプリカのバックアップを設定することはできません。 レプリカのバックアップを設定しようとすると、ユーザーエラーで操作が失敗します。
- 1日回収ポイント目標(RPO)はすべての状況で保証されているわけではありません。 初期バックアップとその後の初期レプリケーションはディスクの全内容を転送し、大規模サーバーやクラスタでは1日以上かかることがあります。 バックアップは、データ量が多いサーバーやPremium SSD v2を使用しているサーバーでは1日を超えることもあります。
- 保護されたアイテムをv1からv2に移動させるのも一つの方法です。 v1に戻るには、保護を停止し、v1スタックのバックアップを再設定してください。
- バックアップ設定は、計画されたジオフェイルオーバー後に新しいプライマリサーバーに自動的に適用されません。 既存のバックアップ構成は以前のプライマリサーバーに関連付けられたままであり、そのバックアップはフェイルオーバー後に失敗し始めます。 新しいプライマリサーバーを保護するために、そのサーバーでバックアップを設定してください。