このページでは、AlloyDB for PostgreSQL データベースでデータを保護するために使用できるバックアップと復元の機能について説明します。
AlloyDB では、次の 2 つの方法でデータをバックアップして復元できます。
継続的なバックアップと復元は、デフォルトですべてのクラスタで有効になっています。これは、同じプロジェクトとリージョン内の別のクラスタの最近の状態に基づいて新しいクラスタを作成できる AlloyDB の機能です。
個別のバックアップは、クラスタのデータベースの完全なコピーを含むファイルベースのリソースです。AlloyDB は、オンデマンドで、または定義した定期的なスケジュールに従って、それらを作成します。これらのバックアップは、新しいクラスタに復元できます。
継続的なバックアップとリカバリ
AlloyDB では、マイクロ秒単位の粒度で、最近の履歴の任意の時点に既存のクラスタを復元できます。デフォルトでは、AlloyDB では過去 14 日までの任意の時点を選択できます。このウィンドウのサイズを 35 日間から 1 日間に変更するようにクラスタを構成できます。
継続的なバックアップと復元は、誤って大規模なデータが削除された後のクラスタの復元や、過去のある時点に基づいてクラスタの状態を迅速に再作成する必要があるその他の状況で特に役立ちます。
障害復旧の観点から、継続的なバックアップと復元により、AlloyDB の目標復旧時点（RPO）をゼロにできます。つまり、データが永続的に失われることなく、致命的なインシデントの直前の状態にクラスタを復元できます。
継続的なバックアップと復元を使用して、正常なクラスタの独立したクローンを作成し、そのすべてのデータを現在の時点からコピーすることもできます。
オンデマンド バックアップまたは自動バックアップ
AlloyDB では、バックアップは特定の時点のクラスタのデータのコピーを含むファイルベースのリソースです。
AlloyDB では、次の 3 つの方法でバックアップを作成できます。
AlloyDB は、この機能を無効にしない限り、継続的なバックアップと復元システムの一部として、毎日 1 つのバックアップを作成します。
継続バックアップは増分バックアップです。AlloyDB は、以前のバックアップと比較して変更されたデータのみを保存します。この方法では、バックアップ ファイルをできるだけ小さく保つため、バックアップ ストレージの費用を削減できます。これらのバックアップのサイズは、前回のバックアップ以降に書き込まれたデータの量などの要因によって異なります。完全な継続バックアップも定期的に作成されます。バックアップ サイズはクラスタ サイズに似ています。
オンデマンド バックアップは、Google Cloud CLI、 Google Cloud コンソール、または API を使用していつでも作成できます。
オンデマンド バックアップはフル バックアップです。各バックアップには、バックアップ オペレーションの開始時にクラスタのデータベースにあったすべてのデータが含まれます。
自動バックアップ スケジュールを有効にすると、AlloyDB は設定に従って追加のバックアップを定期的に作成します。
自動バックアップは、継続的バックアップと同様に増分バックアップです。35 日を超える保持期間を使用するように自動バックアップを構成すると、AlloyDB は必要な期間をカバーするために増分バックアップの複数のチェーンを保存する場合があります。
クラスタのデータベースと同様に、AlloyDB はデフォルトの Google マネージド暗号化または顧客管理の暗号鍵を使用してバックアップ データを暗号化します。
バックアップの作成要件
AlloyDB は、バックアップするクラスタについて次の点をチェックし、新しいバックアップの作成を準備します。
これらのチェックがすべて合格すると、AlloyDB は長時間実行オペレーションを開始してバックアップを作成します。
バックアップは効率的で独立している
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 プロジェクトが異なっていても構いません。
どちらの場合も、AlloyDB は新しいクラスタを作成し、バックアップされたデータをそのクラスタのストレージに読み込む長時間実行オペレーションを開始します。このオペレーションが完了したら、そのクラスタにプライマリ インスタンスを作成してデータにアクセスします。
詳細については、バックアップからの復元をご覧ください。
バックアップの保持と削除
AlloyDB が継続的なバックアップと復元を有効にするために作成するファイルのデフォルトの保持期間は 14 日間です。この期間は 1 ～ 35 日の任意の日数に調整できます。また、継続的なバックアップを無効にして、AlloyDB がこれらのファイルを保持しないようにすることもできます。
オンデマンド バックアップと自動バックアップの保持期間は最長 1 年です。クラスタで自動バックアップを有効にする場合は、保持期間を設定するか、デフォルトの期間（14 日間）を使用します。
プロジェクトのバックアップを表示すると、保持期間を過ぎたバックアップが表示されることがあります。期限切れのバックアップにはストレージ費用は発生しませんが、自動削除の対象となります。システムがバックアップを削除する前にバックアップを削除する必要がある場合は、バックアップを手動で削除できます。
次のステップ
クラスタを復元する方法を学習する。
オンデマンド バックアップを手動で作成する方法を学習する。
自動バックアップや継続バックアップなど、バックアップ プランを構成する方法を学習する。