このページでは、Cloud SQL インスタンスのバックアップの仕組みと、選択可能なバックアップ オプションについて説明します。バックアップからインスタンスにデータを復元する方法の概要については、インスタンスの復元の概要をご覧ください。
Cloud SQL では、インスタンスをオンデマンドでバックアップするか、バックアップ スケジュールを使用して自動でバックアップできます。Cloud SQL のバックアップは増分バックアップであり、失われたデータを Cloud SQL インスタンスに復元する場合に役立ちます。バックアップを使用することにより次のことが可能になります。
- インスタンスに問題が発生した場合に、インスタンスを以前の状態に復元できます。
- 別のリージョンまたはゾーンのバックアップを使用して新しいインスタンスを作成し、障害復旧（DR）を設定できます。
- バックアップを使用して複数のインスタンスを作成し、開発、テスト、移行に役立てられます。
Cloud SQL バックアップも、デフォルトで Google 管理の暗号鍵または顧客管理の暗号鍵（CMEK）を使用して暗号化されます。
このようなバックアップを保持するには、インスタンスのバックアップ保持設定を定義します。保持設定は、インスタンスの Cloud SQL エディションとバックアップ オプションによって異なります。また、インスタンスの削除後にバックアップを保持することにより、削除後にインスタンスを復元することもできます。
Cloud SQL には、バックアップを管理する 2 つのバックアップ サービス オプションがあります。
- 拡張バックアップ: バックアップは、Backup and DR サービスを利用する一元化されたバックアップ管理プロジェクトで管理および保存がされ、保持期間の適用、詳細なスケジュール設定、モニタリングができます。
- 標準バックアップ: バックアップは Cloud SQL インスタンスと同じプロジェクトで作成、管理、保存がされます。
各バックアップ オプションとその機能の詳細については、バックアップ オプションをご覧ください。
バックアップの種類
Cloud SQL は、Cloud SQL インスタンスのオンデマンド バックアップまたは自動バックアップを実行します。インスタンスを削除する前に、インスタンスの最終バックアップを作成することもできます。
オンデマンド バックアップ
オンデマンド バックアップは、いつでも作成できるバックアップです。データベース上でリスクの高いオペレーションを実行しようとしている場合や、バックアップの時間枠まで待たずにバックアップを作成したい場合に便利です。オンデマンド バックアップは、インスタンスで自動バックアップが有効かどうかにかかわらず、すべてのインスタンスで作成できます。
自動バックアップ
自動バックアップは、1 時間ごと、毎日、毎週、毎月などのスケジュールされた頻度で実行されます。スケジュールの頻度は、インスタンスのバックアップ オプションによって異なります。バックアップは、バックアップ時間枠内に開始されます。Cloud SQL では、できる限りインスタンスのアクティビティが少ない時間帯にバックアップをスケジュールすることをおすすめしています。
自動バックアップはポイントインタイム リカバリのサポートに必要なため、手動で削除しないことをおすすめします。
自動バックアップはバックアップ時間枠内でインスタンス実行中に、スケジュールの頻度に基づいて定期的に実行されます。インスタンスが停止すると、追加の自動バックアップが作成され、インスタンスが停止する前にすべての変更が保護されます。自動バックアップの保持は、インスタンスで選択したバックアップ オプションで構成されている保持ポリシーによって異なります。
最終バックアップ
最終バックアップでは、インスタンスを削除する前に Cloud SQL インスタンスのバックアップを作成できます。これはインスタンス削除後にインスタンス データを保持する場合に便利です。最終バックアップを使用して、後ほどインスタンスの作成や既存のインスタンスへの復元ができます。最終バックアップのアクセス方法および詳細の表示方法については、最終バックアップのリストを表示するをご覧ください。
デフォルトでは、Cloud SQL は最終バックアップを 30 日間保持します。ただし、Cloud SQL によるバックアップの保持期間はカスタマイズできます。標準バックアップの場合は 1 日から 365 日、拡張バックアップの場合は 1 日から 99 年の範囲で指定できます。この期間バックアップが利用可能であれば、いつでもバックアップからインスタンスを復元できます。最終バックアップは他のバックアップと同様に、保持日数に基づいて料金が発生します。
インスタンスの削除後もバックアップを保持する
保持されたバックアップとは、インスタンスの削除後に Cloud SQL によって保持されるバックアップのことです。これらのバックアップは、オンデマンド バックアップと、インスタンスが稼働中に作成された自動バックアップで構成されます。インスタンスを削除すると、これらのバックアップはインスタンスから独立し、プロジェクト レベルで保存されます。保持されたバックアップは、インスタンスの削除時に取得された最後のバックアップである最終バックアップとは異なります。
これらのバックアップの説明を更新すると、 Google Cloud プロジェクトでバックアップを簡単に管理できます。保持されたバックアップは、いつでも新規または既存の Cloud SQL インスタンスに復元できます。
このようなバックアップの場合、保持期間はバックアップのタイプによって決まり、インスタンスの削除後に変更することはできません。標準バックアップの場合、オンデマンド バックアップはバックアップを手動で削除するか、バックアップを含むプロジェクトを削除するまで、無期限に保持されます。拡張バックアップの場合、オンデマンド バックアップは選択した保持ルールに基づいて保持されます。自動バックアップは、インスタンスの削除後より 1 日 1 つのバックアップが段階的に削除されます。このローリング期間は削除前のインスタンスの保持設定に基づいて定義され、インスタンスで選択したバックアップ オプションに応じて、1 日から 99 年の範囲となります。たとえば、インスタンスの自動バックアップの保持設定が 7 に設定されている場合、最新の自動バックアップはインスタンスの削除から 7 日後に削除されます。
保持されたバックアップはいつでも手動で削除できます。ただし、保持されたバックアップを削除すると、削除されたバックアップは復元できません。
インスタンス名は Cloud SQL でインスタンスが削除された後に使用できるため、保持されたバックアップは instance_deletion_time というフィールドを使用して Google Cloud プロジェクトに保存されます。このフィールドを使用すると、特定のバックアップがライブ インスタンスに属しているか、削除されたインスタンスに属しているかを特定できます。バックアップを管理しやすいように、バックアップの説明を更新することもできます。
バックアップの復元
また、自動バックアップ ポリシーの一部として使用できる正常なバックアップがない場合は、Cloud SQL はすべてのアクティブなインスタンスに対して最後に実施された日次バックアップを少なくとも 1 つ保持しようと試みます。このバックアップを復元目的で使用するには、Google Cloud カスタマーケアにお問い合わせください。
バックアップとデータの完全性チェック
Cloud SQL はバックグラウンドでのデータベース完全性チェックを自動的に実行し、データの完全性の潜在的な問題を特定します。完全性チェックは、お客様が開始したバックアップのサンプリングの復元またはバックアップの復元を行うことで、オフライン プロセスとして行われます。
トランザクション ログの保持
トランザクション ログの保持期間は日単位です。Cloud SQL Enterprise Plus エディション インスタンスの場合、範囲は 1～35 日で、デフォルトでは 14 日です。Cloud SQL Enterprise エディションのインスタンスの場合は 1～7 日で、デフォルトでは 7 日となっています。Cloud SQL Enterprise Plus エディションと Cloud SQL Enterprise エディションのどちらのインスタンスの場合も、トランザクション ログの保持設定はバックアップの保持設定よりも短い必要があります。
レプリカのバックアップ
レプリカ インスタンスではバックアップを使用できません。レプリカ インスタンスはプライマリ インスタンスのコピーであるため、バックアップはプライマリ インスタンスで維持されます。フェイルオーバーまたは切り替えによりレプリカ インスタンスがスタンドアロン インスタンスに昇格すると、そのインスタンスでバックアップが有効になり、独自のバックアップ構成が必要になります。昇格したレプリカは、プライマリ インスタンスのバックアップ構成を継承せず、プライマリ インスタンスのバックアップにはアクセスできません。
バックアップ オプション
Cloud SQL には、インスタンスのバックアップを管理する 2 つのバックアップ サービス オプション（標準バックアップと拡張バックアップ）があります。インスタンスの要件とニーズに基づいて、標準バックアップ オプションまたは拡張バックアップ オプションを選択できます。インスタンスで両方のバックアップ オプションを同時に使用することはできませんが、Cloud SQL では必要に応じてこのバックアップ オプションを切り替えられます。
次の表は各バックアップ オプションで使用可能な機能の概要をまとめています。
| 機能 | 標準バックアップ | 拡張バックアップ |
|---|---|---|
| Backup Vault | - | ✔ |
| 保持ロックが適用された保持期間 | - | ✔ |
| プロジェクトの削除時のバックアップの保持 | - | ✔ |
| プロジェクト全体での一元的なバックアップ管理 | - | ✔ |
| バックアップの保持期間 | 1 年 | 無制限 |
| 自動バックアップのスケジュール | 毎日 | 毎時、毎日、毎週、毎月、毎年 |
| ログを使用したポイントインタイム リカバリ | ✔ | ✔ |
| リージョン間のバックアップと復元 | ✔ | - |
| オンデマンド バックアップ | ✔ | ✔ |
| マルチリージョンのバックアップ | ✔ | - |
| インスタンスの削除時の全バックアップの保持 | ✔ | ✔ |
| インスタンス削除時の最終バックアップ | ✔ | ✔ |
| CMEK のサポート | ✔ | - |
このバックアップ オプションの詳細については、標準バックアップと拡張バックアップをご覧ください。
拡張バックアップ
拡張バックアップでは、Backup and DR を使用して、さまざまなプロジェクトの Cloud SQL インスタンスの全バックアップを 1 つの一元化されたバックアップ プロジェクトで管理して保存できます。Backup and DR により、日々のバックアップ オペレーションの管理、モニタリング、レポートが 1 か所からできるようになります。バックアップは Backup Vault に保存されます。Backup Vault は Google マネージドの安全で隔離されたストレージ リソースであり、Backup and DR が管理します。また、バックアップ プランがバックアップと復元の設定を管理します。これにより、ソース プロジェクトから独立した、変更不可で消去不可のバックアップが可能になります。Backup and DR でのバックアップの仕組みの詳細については、Backup and DR の概要をご覧ください。
拡張バックアップでは、Backup and DR を使用して、Cloud SQL インスタンス全体でバックアップ プランと Backup Vault を管理する一元化されたバックアップ プロジェクトを作成します。これらのプランは複数のプロジェクトにリンクできます。
バックアップ プランを Cloud SQL インスタンスに適用すると、既存のバックアップと復元の設定がバックアップ プランにより上書きされます。バックアップと復元の設定を含むプランは一元化されたバックアップ プロジェクトに保存され、プランが Cloud SQL インスタンスでアクティブな状態のときに作成されたバックアップは、バックアップ プロジェクトの Backup Vault に保存されます。
Backup and DR は別の Google Cloud プロジェクトで管理されるため、ソース プロジェクトまたはワークロード プロジェクトが削除されてもバックアップは保護されます。ロールと責任は Backup and DR Admin によって管理され、Cloud SQL Admin のロールと責任とは異なります。
インスタンスの削除後にバックアップを保持するか、削除前にインスタンスの最終バックアップを作成できます。拡張バックアップの一環で作成されたすべてのバックアップは、インスタンスの稼働中または削除後にインスタンスの復元に使用できます。
バックアップの保持期間
拡張バックアップを使用すると、バックアップを Backup Vault に最大 99 年間保持できます。Backup Vault の最小適用保持期間は 1 日から 99 年の間です。
バックアップ ストレージ
バックアップは、Backup Vault と呼ばれる一元管理された場所に保存されます。Backup Vault は Backup and DR によって管理される安全で分離されたストレージです。Backup Vault では、バックアップを 1 日から 99 年間保持できます。詳細については、Backup Vault をご覧ください。
バックアップ費用
拡張バックアップでは、バックアップの費用は Backup Vault に保存されているバックアップの合計サイズに基づきます。このようなバックアップは、インスタンスに関連付けられたバックアップ プランのバックアップ構成に基づいて作成されます。合計費用は Backup and DR の料金に基づき、Backup and DR によって計算されます。
制限事項
拡張バックアップを使用する場合、次の制限が適用されます。
- Backup Vault と Cloud SQL インスタンスは同じリージョンに存在する必要があります。
- インスタンスに関連付けられているバックアップ プランを変更するには、既存のバックアップ プランの関連付けを削除してインスタンスを標準バックアップに変更したうえで、新しいバックアップ プランを関連付ける必要があります。
- 拡張バックアップを使用しているインスタンスの障害復旧（DR）レプリカを作成することはできません。
- インスタンスに障害復旧（DR）レプリカがあると、そのインスタンスで拡張バックアップを有効にすることはできません。
- バックアップ プランをレプリカ インスタンスに関連付けることはできません。
- インスタンスで拡張バックアップを使用している場合、インスタンスをレプリカに降格することはできません。
標準バックアップ
標準バックアップは Cloud SQL インスタンスで Cloud SQL によって管理されるバックアップです。Cloud SQL のバックアップは増分バックアップであり、前回のバックアップ以降に変更されたデータのみが含まれます。デフォルトでは、Cloud SQL はオンデマンド バックアップに加えて、各 Cloud SQL Enterprise エディション インスタンスに対しては 7 件の自動バックアップを保持し、各 Cloud SQL Enterprise Plus エディション インスタンスに対しては 15 件の自動バックアップを保持します。保持する自動バックアップの数を構成できます（1～365 の範囲）。
インスタンスの削除の一環で、インスタンスの削除時にすべてのバックアップを保持し、データの最終バックアップを作成できます。これにより、削除したインスタンスを再作成できます。ただし、バックアップを保持しない場合、またはインスタンスを削除する前に最終バックアップを作成しない場合、Cloud SQL によってすべてのインスタンス バックアップが自動的に削除されます。
バックアップの保持期間
オンデマンド バックアップは自動的には削除されません。手動で削除するか、インスタンスが削除されるまで保持されます。オンデマンド バックアップは自動的に削除されないため、長期的に請求料金に影響を及ぼす可能性があります。
自動バックアップを使用してインスタンスのバックアップ設定で保持期間をすることで、1～365 日間保持できます。トランザクション ログは日数でカウントされますが、自動バックアップは 1 日で完了するとは限りません。
オンデマンド バックアップと自動バックアップに関して、インスタンス削除後のバックアップの保持を有効にすると、自動バックアップの場合は 1～365 日、オンデマンド バックアップの場合は無期限という同じ保持設定が適用されます。詳細については、インスタンスの削除後のバックアップを保持するをご覧ください。
ログは継続的ではなく、1 日 1 回削除されます。ログの保持日数がバックアップ数と同じ場合、ログの保持期間が不足する可能性があります。たとえば、ログ保持期間を 7 日に設定し、保持するバックアップの数を 7 に設定すると、6～7 日分のログが保持されます。
バックアップの数はログ保持期間（日）よりも 1 以上大きい数に設定して、指定したログ保持期間が最低限網羅されるようにすることをおすすめします。
新しいインスタンスまたは既存のインスタンスで保持されたバックアップを有効にする方法については、保持されたバックアップを管理するをご覧ください。保持されたバックアップからインスタンスを復元する方法については、保持されたバックアップから復元するをご覧ください。
バックアップ ストレージ
シングルリージョン構成では、バックアップはリージョン内の異なるゾーン間で複製されます。マルチリージョン構成では、レイテンシを最小限に抑え、組織のポリシーまたはロケーション ベースの制限によるバックアップの失敗を回避するため、バックアップをインスタンスと同じリージョンに配置することをおすすめします。
バックアップは高可用性（HA）構成と非 HA 構成のどちらのインスタンスも同じロケーションに保存されます。HA 構成では、セカンダリ インスタンスへのフェイルオーバーまたは切り替えが発生した場合でも、インスタンスのバックアップにアクセスできます。
バックアップのロケーションは次のように定義できます。
- Cloud SQL が選択したデフォルトのロケーション（元のインスタンスの場所に基づく）。
- デフォルト ロケーションを使用しない場合に選択するカスタム ロケーション。
デフォルト バックアップ ロケーション
ストレージ ロケーションを指定しない場合、バックアップは Cloud SQL インスタンスのロケーションに最も近いマルチリージョン ロケーションに保存されます。たとえば、Cloud SQL インスタンスが us-central1 にある場合、デフォルトでは us マルチリージョンにバックアップが保存されます。ただし、australia-southeast1 のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンは asia です。
カスタム バックアップ ロケーション
Cloud SQL では、バックアップ データのカスタム ロケーションを選択できます。これは、バックアップの保管場所を特定の地理的境界内に限定する規制を組織が遵守しなければならない場合に便利です。組織に対してこのような要件がある場合は、リソース ロケーション制限の組織のポリシーが適用される可能性が高くなります。このポリシーでは、ポリシーに適合していない地理的位置を保管場所として使用しようとすると、[バックアップ] ページにアラートが表示されます。このアラートが表示された場合は、バックアップのロケーションをポリシーで許可されているロケーションに変更する必要があります。
バックアップのカスタム ロケーションを選択する場合は、次の点を考慮してください。
- コスト: インスタンス内の、あるクラスタは、他のクラスタよりも低コストのリージョンにある可能性があります。
- アプリケーション サーバーへの近接: バックアップは、できるだけ提供アプリケーションに近い場所に保管することをおすすめします。
- ストレージの利用率: バックアップのサイズが大きくなると、維持するために十分な保存容量が必要になります。ワークロードに応じて、サイズやディスク使用量の異なるクラスタを作成できます。これはクラスタの選択に影響することがあります。
有効なリージョン値の完全なリストについては、インスタンスのロケーションをご覧ください。マルチリージョン値の完全なリストについては、マルチリージョンのロケーションをご覧ください。
バックアップのロケーションの設定と、インスタンスに対して実行されたバックアップのロケーションの詳細については、バックアップのカスタム ロケーションを設定するとバックアップのロケーションを表示するをご覧ください。
バックアップのレート制限
Cloud SQL では、データディスクのバックアップ オペレーションのレートが制限されています。1 つのプロジェクトの 1 つのインスタンスで 50 分ごとに最大 5 つのバックアップ オペレーションが許可されます。バックアップ オペレーションが失敗した場合、この割り当てにカウントされません。上限に達するとオペレーションは失敗し、再試行が可能であることを示すエラー メッセージが表示されます。
では、Cloud SQL がバックアップのレート制限をどのように実行しているのか見てみましょう。
Cloud SQL は、バケットからのトークンを使用して、一度に実行可能なバックアップ オペレーションの数を決定します。各インスタンスにはバケットがあります。バケット内でバックアップ オペレーションに使用可能なトークンは最大 5 つです。10 分ごとに新しいトークンがバケットに追加されます。バケットがいっぱいの場合、トークンはオーバーフローします。
バックアップ オペレーションのたびに、バケットからトークンが付与されます。オペレーションが成功すると、バケットからトークンが削除されます。失敗した場合、トークンがバケットに返されます。次の図は、この仕組みを示しています。
バックアップとエクスポート
バックアップは、保持ポリシーに従って Cloud SQL によって管理され、Cloud SQL インスタンスとは別に保存されます。Cloud SQL バックアップは、ライフサイクルを管理する Cloud Storage にアップロードされるエクスポートとは異なります。バックアップにはインスタンスのディスク全体が含まれます。エクスポートでは特定のコンテンツを選択できます。
バックアップや復元のオペレーションを使用してデータベースを新しいバージョンにアップグレードすることはできません。バックアップから復元できるのは、バックアップ作成時と同じデータベース バージョンのインスタンスに限られます。
新しいバージョンにアップグレードするには、Database Migration Service を使用するか、データベースを新しい Cloud SQL インスタンスにエクスポートしてからインポートすることをおすすめします。バックアップ費用
デフォルトでは、Cloud SQL はオンデマンド バックアップに加えて、各 Cloud SQL Enterprise エディション インスタンスに対しては 7 件の自動バックアップを保持し、各 Cloud SQL Enterprise Plus エディション インスタンスに対しては 15 件の自動バックアップを保持します。保持する自動バックアップの数を構成できます（1～365 の範囲）。バックアップ ストレージの料金は、他のタイプのインスタンスの料金よりも低額です。
バックアップに関する料金の詳細については、料金ページをご覧ください。
バックアップ サイズ
Cloud SQL バックアップは最初のバックアップを除きすべての増分バックアップとなります。バックアップには、前回のバックアップの作成後に変更されたデータのみが含まれます。最も古いバックアップはデータベースと同様のサイズですが、その後のバックアップのサイズはデータを変更した割合によって異なります。最も古いバックアップが削除されると、その次に古いバックアップのサイズが増加してフル バックアップになり、バックアップ間の差分を埋めるように調整されます。以降の各増分バックアップも、新しいフル バックアップに合わせて更新されます。
個々のバックアップのサイズを確認できます。バックアップ サイズは各バックアップの請求対象となるサイズを表しています。
トラブルシューティング
| 問題 | トラブルシューティング |
|---|---|
| 現在のオペレーションのステータスを確認できない。 | Google Cloud コンソールでは、オペレーションの完了時に成功または失敗のみが表示されます。警告やその他の情報を表示するように設計されていません。 特定の Cloud SQL インスタンスのすべてのオペレーションを確認するには、 |
| オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 | オペレーションを開始したユーザーはユーザー インターフェースに表示されません。 ユーザーを特定するには、ログを表示してテキストでフィルタします。個人情報の監査ログが必要になる場合があります。関連するログファイルは次のとおりです。
|
| インスタンスを削除すると、その後インスタンスのバックアップを作成できない。 | データの最終バックアップを作成せずにインスタンスを削除すると、データを復元できなくなります。ただし、インスタンスを復元すると、Cloud SQL はバックアップも復元します。削除したインスタンスの復元について詳しくは、バックアップの復元をご覧ください。 エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。 |
| 自動バックアップが長時間停止していて、キャンセルできない。 | データベースのサイズによっては、バックアップに時間がかかる可能性があります。 オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの |
| SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。 | SQL ダンプを復元する前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが、ターゲット データベース内に存在している必要があります。そうでない場合、復元オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。 SQL ダンプを復元する前に、データベース ユーザーを作成します。 |
| 自動バックアップの保持日数を 7 日から 30 日以上に増やしたい。 | 保持する自動バックアップの数を構成できます（1～365 件の範囲）。自動バックアップは、構成された保持値に基づいて定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。 バックアップを無期限に保持する場合は、オンデマンド バックアップを作成します。オンデマンド バックアップは、自動バックアップと同じ方法では削除されません。オンデマンド バックアップは無期限に維持されます。つまり、削除されるか、所属するインスタンスが削除されるまで保持されます。このタイプのバックアップは自動的に削除されないため、課金に影響する可能性があります。 |
| 自動バックアップが失敗したときにメール通知を受信できない。 | Cloud SQL からバックアップのステータスの通知が届くようにするには、ログベースのアラートを構成します。 |