データのバックアップと復元の概要

AlloyDB for PostgreSQL データベースのデータを保護するには、いくつかの機能を使用してデータのバックアップと復元を行い、バックアップを管理します。バックアップからクラスタにデータを復元するには、バックアップからクラスタを復元するをご覧ください。

AlloyDB では、次の方法でデータをバックアップして復元できます。

  • 継続的なバックアップと復元は、すべてのクラスタでデフォルトで有効になっています。これは、ソースクラスタと同じリージョンにある別のクラスタの最新の状態に基づいて新しいクラスタを作成できる AlloyDB の機能です。このクラスタは別の Google Cloud プロジェクトに存在していてもかまいません。
  • 個別のバックアップは、クラスタのデータベースの完全なコピーを含むファイルベースのリソースです。AlloyDB はこれらのファイルを、オンデマンドで、またはユーザーが定義した定期的なスケジュールに従って作成します。これらのバックアップのいずれかを新しいクラスタに復元できます。

AlloyDB には、バックアップを管理する次のバックアップ サービスがあります。

  • 拡張バックアップ: バックアップは、Backup and DR サービスを使用する一元化されたバックアップ管理プロジェクトで管理および保存されます。このプロジェクトでは、Backup and DR サービス Backup Vault、保持期間の適用、詳細なスケジュール設定、モニタリングが提供されます。詳細については、Backup and DR の概要をご覧ください。
  • 標準バックアップ: バックアップは AlloyDB によって作成、管理、保存されます。

各バックアップ オプションとその機能の詳細については、バックアップ オプションをご覧ください。

バックアップの種類

AlloyDB は、AlloyDB クラスタのオンデマンド バックアップまたは自動バックアップを実行します。また、継続的なバックアップと復元を使用することもできます。クラスタを削除する前に、クラスタの最終的な手動バックアップを作成することもできます。

継続的なバックアップと復元

AlloyDB では、既存のクラスタを最近の履歴の任意の時点にマイクロ秒単位の粒度で復元できます。デフォルトでは、過去 14 日以内の任意の時点を選択できます。この期間の長さを最長 35 日から最短 1 日に変更するようクラスタを構成できます。

継続的なバックアップと復元は、誤って大量のデータが削除された後のクラスタの復元や、過去のある時点に基づいてクラスタの状態を迅速に再作成する必要があるような状況で特に役立ちます。

継続的なバックアップと復元を使用すれば、AlloyDB の目標復旧時点（RPO）をゼロにできます。つまり、いずれのデータも完全に失うことなく、致命的なインシデントの直前の状態にクラスタを復元できます。

継続的なバックアップと復元を使用して、正常なクラスタの独立したクローンを作成し、そのすべてのデータを現在の時点からコピーすることもできます。

オンデマンド バックアップまたは自動バックアップ

AlloyDB におけるバックアップとは、特定の時点のクラスタのデータのコピーを含むファイルベースのリソースです。

AlloyDB では、次の方法でバックアップを作成できます。

  • 継続的なバックアップと復元機能を無効にしない限り、その仕組みの一部として、常に毎日 1 つのバックアップが作成されます。継続的バックアップは増分バックアップです。つまり、前回のバックアップと比較して変更されたデータのみが保存されます。この方法では、バックアップ ファイルが可能な限り小さくなるため、バックアップ ストレージの費用を削減できます。これらのバックアップのサイズは、前回のバックアップ以降に書き込まれたデータの量などの要因によって左右されます。継続的フル バックアップも定期的に作成されます。このバックアップのサイズはクラスタサイズとほぼ同じです。
  • オンデマンド バックアップは、Google Cloud CLI、 Google Cloud コンソール、または Backup and DR API（拡張バックアップを使用している場合）を使用していつでも作成できます。オンデマンド バックアップはフル バックアップです。各バックアップには、バックアップ オペレーションの開始時にクラスタのデータベースに存在していたすべてのデータが含まれます。
  • AlloyDB 自動バックアップ スケジュールを有効にすると、設定に従って追加のバックアップが定期的に作成されます。自動バックアップは、継続的バックアップと同様に増分バックアップです。 保持期間を 35 日超にするように自動バックアップを構成すると、必要な期間をカバーするために増分バックアップの複数のチェーンが保存される場合があります。

クラスタのデータベースと同様に、AlloyDB のバックアップ データはデフォルトの Google 管理の暗号化または顧客管理の暗号鍵を使用して暗号化されます。バックアップを作成すると、その内容は不変になります。つまり、変更することはできません。

バックアップ オプション

AlloyDB には、クラスタのバックアップを管理する 2 つのバックアップ サービス オプション（標準バックアップと拡張バックアップ）があります。クラスタの要件とニーズに基づいて、標準バックアップ オプションまたは拡張バックアップ オプションを選択できます。クラスタで両方のバックアップ オプションを同時に使用することはできませんが、AlloyDB では必要に応じてこのバックアップ オプションを切り替えられます。

次のテーブルに、各バックアップ オプションで使用可能な機能の概要を示します。

機能

標準バックアップ ティア

（AlloyDB が管理）

拡張バックアップ ティア

（Backup and DR が管理）

不正な削除や変更から保護されたバックアップ

Backup Vault を介した変更不可のバックアップ

Backup Vault を介した変更不可で消去不可のバックアップ

自動バックアップの頻度

毎日（継続的なログアーカイブあり）（継続的なバックアップと復元）

1 時間ごと / 毎日 / 毎週（自動バックアップ）

時間単位、日単位、週単位、月単位、年単位

ソース プロジェクトの削除から保護されたバックアップ

–

✅

一元化されたバックアップ管理

–

✅

ソースクラスタの削除から保護されるバックアップ

✅

✅

ログを使用したポイントインタイム リカバリ（PITR）

✅

✅

クロスリージョンの復元

✅

–

オンデマンド バックアップの保持期間

最長 1 年間保持できます

最長 1 年間保持できます。保持期間の経過後に手動で削除することも、期限切れにすることもできます

標準バックアップ

AlloyDB の標準バックアップ機能は、すべてのクラスタでデフォルトで使用可能な組み込みのデータ保護機能です。このシステムは、継続的なバックアップとオンデマンド バックアップまたは自動バックアップという 2 つの主要なメカニズムを通じて、保護の基盤となるレイヤを提供します。

継続的なバックアップと復元は、デフォルトですべてのクラスタで有効になっています。ポイントインタイム リカバリ（PiTR）を使用すると、新しいクラスタを最近の履歴の任意の時点にマイクロ秒単位の粒度で復元できます。PiTR ウィンドウのデフォルトは 14 日ですが、1～35 日の範囲で構成できます。AlloyDB は、このシステムの一部として、毎日 1 つの増分バックアップを作成します。このバックアップには、前回のバックアップ以降に変更されたデータのみが保存されます。

オンデマンド バックアップまたは自動バックアップは、特定の時点のクラスタのデータの完全なコピーを含むファイルベースのリソースです。オンデマンド バックアップは、作成時のすべてのクラスタデータを含むフル バックアップです。自動バックアップは、ユーザー定義のスケジュールに従って作成される増分バックアップです。バックアップが作成されると、バックアップ データは変更不可になり、変更を防止できます。バックアップはデフォルトでクラスタと同じリージョンに保存されますが、オンデマンド バックアップ用にカスタムのクロスリージョン ロケーションを指定できます。

拡張バックアップ

AlloyDB の拡張バックアップ機能は、Backup and DR サービス（ Google Cloudの一元的なエンタープライズ クラスのバックアップ サービス）と統合されています。拡張バックアップは、一部のセグメントとエンタープライズ セグメント、規制の厳しいワークロードに最適です。また、ミッション クリティカルなアプリケーションをランサムウェアから保護します。拡張バックアップでは、標準バックアップ機能に加えて、次の機能を利用できます。

  • 変更不可のストレージ: バックアップは、Backup and DR で管理される Backup Vault に保存されます。
  • 保持の適用: ポリシーにより、バックアップの誤った削除や悪意のある削除を防ぎます。
  • 高度なスケジュール設定: バックアップの頻度と保持ルールを高度にカスタマイズできます。
  • 一元管理: AlloyDB、Cloud SQL、Compute Engine などの複数のGoogle Cloud ワークロードにわたって統一されたモニタリングとレポート。

バックアップの保持と削除

AlloyDB の継続的なバックアップと復元のために作成されるファイルのデフォルトの保持期間は 14 日です。この期間は 1～35 日の任意の日数に調整できます。また、継続的バックアップを無効にしてこれらのファイルが保持されないようにすることもできます。

オンデマンド バックアップと自動バックアップの保持期間は最長 1 年です。クラスタで自動バックアップを有効にする場合は、保持期間を設定するか、デフォルトの期間（14 日）を使用します。

プロジェクトのバックアップのリストを表示したとき、保持期間が過ぎたバックアップがリストに含まれていることがあります。期限切れのバックアップは、ストレージ費用は発生しませんが、自動削除の対象となります。バックアップが自動的に削除される前にバックアップを削除する必要がある場合は、バックアップを手動で削除できます。

バックアップの削除からの保護

バックアップは手動で削除できますが、AlloyDB には、アクティブに管理されているバックアップや依存関係のあるバックアップを誤って削除しないようにするための強力な保護機能が用意されています。

次の条件では、AlloyDB バックアップを削除できません。

  • アクティブなバックアップ プラン: アクティブな継続的または自動バックアップ プランで管理されている場合、バックアップを削除できません。このようなバックアップを削除するには、まずバックアップ プランを無効にするか、保持期間を短縮する必要があります。
  • 依存関係チェーン: 後続のバックアップが復元オペレーションで必要としている場合、バックアップを削除できません。たとえば、増分バックアップのチェーンでは、その前の増分バックアップを削除する前に、最新の増分バックアップを削除する必要があります。
  • 拡張バックアップは、適用される保持期間内は Backup and DR Backup Vault にあります。このコンプライアンス機能により、誤って削除されたり、悪意のある削除が行われたりすることを防止できます。この期間中は、誰もバックアップを削除できません。

これらの保護により、バックアップ履歴の整合性が確保され、クラスタを有効な任意の時点に復元できます。

バックアップ作成の要件

AlloyDB は、新しいバックアップを作成する準備として、クラスタの状態が Ready であることを確認してから、バックアップを作成する長時間実行オペレーションを開始します。

効率的で独立したバックアップ

AlloyDB データから作成されたバックアップは、AlloyDB のストレージ レイヤによって全面的に管理されます。つまり、バックアップと復元オペレーションは、クラスタデータの保存やクエリに使用されるリソースとは別のリソースによって実行されるため、AlloyDB クラスタの読み取りと書き込みのパフォーマンスには影響しません。

このストレージ リソースの分離は、バックアップが元のクラスタから独立して存在することも意味します。たとえソースクラスタがすでに削除されていても、そのバックアップから復元できます。

AlloyDB のストレージ レイヤが独立したバックアップをどのように実現しているかについて詳しくは、AlloyDB for PostgreSQL の仕組み: データベース対応のインテリジェントなストレージをご覧ください。

オンデマンド バックアップのロケーション

オンデマンド バックアップの場合、AlloyDB のバックアップ ロケーションには次のものが含まれます。

デフォルト バックアップのロケーション

ストレージ ロケーションを指定しない場合、バックアップは AlloyDB クラスタのロケーションに保存されます。たとえば、AlloyDB インスタンスが us-central1 (Iowa) にある場合、デフォルトでは us-central1 (Iowa) ロケーションにバックアップが保存されます。

クロスリージョン バックアップのロケーション

AlloyDB のバックアップ データ用にカスタムのクロスリージョン ロケーションを選択できます。これにより、バックアップを保存できるリージョンのグループが拡大します。これは、クラスタ リージョンが使用できなくなった場合でもバックアップの復元機能を維持するために役立ちます。

バックアップのクロスリージョン ロケーションを選択する際は、以下の点を考慮してください。

  • 費用: 料金はリージョンによって異なる場合があります。
  • アプリケーション サーバーへの近接: バックアップは、できるだけ提供アプリケーションに近い場所に保管することをおすすめします。

注: バックアップを保存するロケーションを変更しても、既存のバックアップは元のロケーションに残ります。

クラスタの復元

AlloyDB でクラスタを復元するには、元のクラスタの過去のある時点に存在するすべてのデータを格納する新しいクラスタを作成します。この時点を指定する 2 通りの方法は、AlloyDB がサポートする一般的な 2 種類のバックアップに対応しています。

  • クラスタの最近の状態の特定の時点に復元するには、新しいクラスタを作成するときにソースクラスタとタイムスタンプの両方を指定します。新しいクラスタはソースクラスタと同じリージョンに存在する必要がありますが、属するGoogle Cloud プロジェクトは異なっていてもかまいません。
  • バックアップからクラスタを復元するには、新しいクラスタを作成するときに復元元のバックアップを指定します。新しいクラスタはバックアップと同じリージョンに存在する必要がありますが、属する Google Cloud は異なっていてもかまいません。

どちらの場合も、新しいクラスタが作成された後、バックアップ データをそのクラスタのストレージに読み込む長時間実行オペレーションが開始されます。このオペレーションが完了したら、クラスタにプライマリ インスタンスを作成してデータにアクセスします。

クラスタの復元は同じリージョンで行われますが、オンデマンド バックアップはリージョンを越えて保存できます。バックアップと復元は、異なるGoogle Cloud プロジェクトおよび組織の間で行うことができます。

詳細については、バックアップから復元するをご覧ください。

次のステップ