このページでは、AlloyDB for PostgreSQL データベース内のデータを保護するために使用できるバックアップと復元の機能について説明します。
AlloyDB には、データをバックアップして復元する方法が 2 通りあります。
継続的なバックアップと復元は、すべてのクラスタでデフォルトで有効になっています。これは、同じプロジェクト内の同じリージョンにある別のクラスタの最新の状態に基づいて新しいクラスタを作成できる AlloyDB の機能です。
個別のバックアップは、クラスタのデータベースの完全なコピーを含むファイルベースのリソースです。AlloyDB はこれらのファイルを、オンデマンドで、またはユーザーが定義した定期的なスケジュールに従って作成します。これらのバックアップのいずれかを新しいクラスタに復元できます。
継続的なバックアップと復元
AlloyDB では、既存のクラスタを最近の履歴の任意の時点にマイクロ秒単位の粒度で復元できます。デフォルトでは、過去 14 日以内の任意の時点を選択できます。この期間の長さを最長 35 日から最短 1 日に変更するようクラスタを構成できます。
継続的なバックアップと復元は、誤って大量のデータが削除された後のクラスタの復元や、過去のある時点に基づいてクラスタの状態を迅速に再作成する必要があるような状況で特に役立ちます。
障害復旧の観点から見ると、継続的なバックアップと復元を使用すれば、AlloyDB の目標復旧時点（RPO）をゼロにすることができます。つまり、いずれのデータも完全に失うことなく、致命的なインシデントの直前の状態にクラスタを復元できます。
継続的なバックアップと復元を使用して、正常なクラスタの独立したクローンを作成し、そのすべてのデータを現在の時点からコピーすることもできます。
オンデマンド バックアップまたは自動バックアップ
AlloyDB におけるバックアップとは、特定の時点のクラスタのデータのコピーを含むファイルベースのリソースです。
AlloyDB では、以下の 3 通りの方法でバックアップを作成できます。
継続的なバックアップと復元機能を無効にしない限り、その仕組みの一部として、常に毎日 1 つのバックアップが作成されます。
継続的バックアップは増分バックアップです。つまり、前回のバックアップと比較して変更されたデータのみが保存されます。この方法では、バックアップ ファイルが可能な限り小さくなるため、バックアップ ストレージの費用を削減できます。これらのバックアップのサイズは、前回のバックアップ以降に書き込まれたデータの量などの要因によって左右されます。継続的フル バックアップも定期的に作成されます。このバックアップのサイズはクラスタサイズとほぼ同じです。
オンデマンド バックアップは、Google Cloud CLI、Google Cloud コンソール、または API を使用していつでも作成できます。
オンデマンド バックアップはフル バックアップです。各バックアップには、バックアップ オペレーションの開始時にクラスタのデータベースに存在していたすべてのデータが含まれます。
自動バックアップ スケジュールを有効にすると、設定に従って追加のバックアップが定期的に作成されます。
自動バックアップは、継続的バックアップと同様に増分バックアップです。保持期間を 35 日超にするように自動バックアップを構成すると、必要な期間をカバーするために増分バックアップの複数のチェーンが保存される場合があります。
クラスタのデータベースと同様に、AlloyDB のバックアップ データはデフォルトの Google 管理の暗号化または顧客管理の暗号鍵を使用して暗号化されます。
バックアップ作成の要件
新しいバックアップの作成を準備する際、バックアップするクラスタの以下の点がチェックされます。
これらのチェック項目がすべて合格している場合、バックアップを作成する長時間実行オペレーションが開始されます。
バックアップは効率的で独立している
AlloyDB データから作成されたバックアップは、AlloyDB のストレージ レイヤによって全面的に管理されます。つまり、バックアップと復元オペレーションは、クラスタデータの保存やクエリに使用されるリソースとは別のリソースによって実行されるため、AlloyDB クラスタの読み取りと書き込みのパフォーマンスには影響しません。
このストレージ リソースの分離は、バックアップが元のクラスタから独立して存在することも意味します。たとえソースクラスタがすでに削除されていても、そのバックアップから復元できます。
AlloyDB のストレージ レイヤがこれをどのように実現しているかについて詳しくは、AlloyDB for PostgreSQL の仕組み: データベース対応のインテリジェントなストレージをご覧ください。
オンデマンド バックアップのロケーション
オンデマンド バックアップの場合、AlloyDB のバックアップ ロケーションには次のものが含まれます。
- 元のクラスタのロケーションに基づいて AlloyDB が選択するデフォルト ロケーション。
- デフォルト ロケーションを使用しない場合にユーザーが指定するクロスリージョン ロケーション。
デフォルト バックアップのロケーション
ストレージ ロケーションを指定しない場合、バックアップは AlloyDB クラスタのロケーションに保存されます。たとえば、AlloyDB インスタンスが us-central1 (Iowa) にある場合、デフォルトでは us-central1 (Iowa) ロケーションにバックアップが保存されます。
クロスリージョン バックアップのロケーション
AlloyDB のバックアップ データ用にカスタムのクロスリージョン ロケーションを選択できます。これにより、バックアップを保存できるリージョンのグループが拡大します。これは、クラスタ リージョンが使用できなくなった場合でもバックアップの復元機能を維持するために役立ちます。
バックアップのクロスリージョン ロケーションを選択する際は、以下の点を考慮してください。
- 費用: 料金はリージョンによって異なる場合があります。
- アプリケーション サーバーへの近接: バックアップは、提供しているアプリケーションにできるだけ近い場所に保存することをおすすめします。
クラスタの復元
AlloyDB でクラスタを復元するには、元のクラスタの過去のある時点に存在するすべてのデータを格納する新しいクラスタを作成します。この時点を指定する 2 通りの方法は、AlloyDB がサポートする一般的な 2 種類のバックアップに対応しています。
クラスタの最近の状態の特定の時点に復元するには、新しいクラスタを作成するときにソースクラスタとタイムスタンプの両方を指定します。新しいクラスタはソースクラスタと同じリージョンに存在する必要がありますが、属するGoogle Cloud プロジェクトは異なっていてもかまいません。
バックアップからクラスタを復元するには、新しいクラスタを作成するときに復元元のバックアップを指定します。新しいクラスタはバックアップと同じリージョンに存在する必要がありますが、属する Google Cloud は異なっていてもかまいません。
どちらの場合も、新しいクラスタが作成された後、バックアップ データをそのクラスタのストレージに読み込む長時間実行オペレーションが開始されます。このオペレーションが完了したら、クラスタにプライマリ インスタンスを作成してデータにアクセスします。
クラスタの復元は同じリージョンで行われますが、オンデマンド バックアップはリージョンを越えて保存できます。バックアップと復元は、異なる Google Cloud プロジェクトおよび組織の間で行うことができます。
詳細については、バックアップからの復元をご覧ください。
バックアップの保持と削除
AlloyDB の継続的なバックアップと復元のために作成されるファイルのデフォルトの保持期間は 14 日です。この期間は 1～35 日の任意の日数に調整できます。また、継続的バックアップを無効にしてこれらのファイルが保持されないようにすることもできます。
オンデマンド バックアップと自動バックアップの保持期間は最長 1 年です。クラスタで自動バックアップを有効にする場合は、保持期間を設定するか、デフォルトの期間（14 日）を使用します。
プロジェクトのバックアップのリストを表示したとき、保持期間が過ぎたバックアップがリストに含まれていることがあります。期限切れのバックアップは、ストレージ費用は発生しませんが、自動削除の対象となります。バックアップが自動的に削除される前にバックアップを削除する必要がある場合は、バックアップを手動で削除できます。
次のステップ
クラスタを復元する方法を学習する。
オンデマンド バックアップを手動で作成する方法を学習する。
自動バックアップや継続的バックアップを含むバックアップ プランを構成する方法を学習する。
AlloyDB でのバックアップの詳細を確認する。