Cloud SQL バックアップについて

このページでは、Cloud SQL インスタンスのバックアップの仕組みについて説明します。プライマリ インスタンス上でバックアップを実行できます。

バックアップのスケジュールやオンデマンド バックアップの作成の詳細については、オンデマンド バックアップと自動バックアップの作成と管理をご覧ください。

バックアップからインスタンスにデータを復元する方法の概要については、インスタンスの復元の概要をご覧ください。

バックアップの機能

バックアップにより、失われたデータを Cloud SQL インスタンスに復元できます。また、インスタンスに問題がある場合は、バックアップを使用してインスタンスを上書きすることで以前の状態に戻すことができます。必要なデータを含むインスタンスを自動的にバックアップできます。バックアップはデータの損失や破損を防ぎます。

クローン作成やレプリカ作成などの一部のオペレーションでも、自動バックアップとトランザクション ロギングを有効にする必要があります。

バックアップの費用

デフォルトでは、Cloud SQL は各インスタンスに対して、オンデマンド バックアップに加えて 7 つの自動バックアップを保持します。保持する自動バックアップの数を構成できます（1～365 の範囲）。バックアップ ストレージの料金は、他のタイプのインスタンスの料金よりも低額です。

Cloud SQL では、インスタンスを停止または削除すると、インスタンスのバックアップは作成されません。インスタンスを削除した場合、データは 4 日間しか保持されません。インスタンスとそのデータを復元するには、4 日以内に、必要なすべてのインスタンス情報を添えて Google Cloud サポートにお問い合わせください。

詳しくは料金ページをご覧ください。

バックアップとエクスポート

バックアップは、保持ポリシーに従って Cloud SQL によって管理され、Cloud SQL インスタンスとは別に保存されます。Cloud SQL バックアップは、ライフサイクルを管理する Cloud Storage にアップロードされるエクスポートとは異なります。バックアップにはデータベース全体が含まれます。エクスポートでは特定のコンテンツを選択できます。

バックアップや復元のオペレーションを使用してデータベースを新しいバージョンにアップグレードすることはできません。バックアップから復元できるのは、同じデータベース バージョンのインスタンスに限られます。

新しいバージョンにアップグレードするには、Database Migration Service を使用するか、データベースを新しい Cloud SQL インスタンスにエクスポートしてからインポートすることを検討してください。

バックアップ サイズについて

Cloud SQL のバックアップは増分バックアップです。このバックアップには、前回のバックアップの作成後に変更されたデータのみが含まれます。最も古いバックアップはデータベースと同様のサイズですが、その後のバックアップのサイズはデータの変更の割合によって異なります。最も古いバックアップが削除されると、フル バックアップを維持するため、その次に古いバックアップのサイズが増加します。

バックアップの種類

Cloud SQL は、次の 2 種類のバックアップを実行します。

オンデマンド バックアップ

バックアップはいつでも作成できます。そのため、データベース上でリスクの高いオペレーションを実行しようとしている場合や、バックアップ時間枠まで待機することなくバックアップを作成することが必要な場合でも、不都合が生じることはありません。オンデマンド バックアップは、インスタンスで自動バックアップが有効であるかどうかにかかわらず、すべてのインスタンスで作成できます。

オンデマンド バックアップは、自動バックアップと異なり、自動的に削除されません。 明示的に削除するか、インスタンスが削除されるまで維持されます。オンデマンド バックアップは自動的に削除されないため、請求料金に長期間な影響を及ぼす可能性があります。

自動バックアップ

自動バックアップは、4 時間のバックアップ時間枠内に毎日行われます。バックアップは、バックアップ時間枠内に開始されます。可能な場合は、インスタンスのアクティビティが最も少ない時間帯にバックアップをスケジュールしてください。

自動バックアップはポイントインタイム リカバリのサポートに必要なため、削除しないことをおすすめします。

インスタンスが実行されているすべての日で、バックアップ時間枠内に自動バックアップが実行されます。インスタンスが停止すると、追加の自動バックアップが作成され、インスタンスが停止する前にすべての変更が保護されます。デフォルトでは、最新の 7 件のバックアップが保持されます。保持する自動バックアップの数を構成できます（1～365 の範囲）。バックアップとトランザクションのログの保持期間の値はデフォルト設定から変更できます。詳細。

バックアップが保存される場所

バックアップ ロケーションには、次のものがあります。

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

ストレージ ロケーションを指定しない場合、バックアップは Cloud SQL インスタンスのロケーションに最も近いマルチリージョン ロケーションに保存されます。たとえば、Cloud SQL インスタンスが us-central1 にある場合、デフォルトでは us マルチリージョンにバックアップが保存されます。ただし、australia-southeast1 のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンは asia です。

カスタム バックアップ ロケーション

Cloud SQL では、バックアップ データのカスタム ロケーションを選択できます。これは、バックアップの保管場所を特定の地理的境界内に限定する規制を組織が遵守しなければならない場合に便利です。組織に対してこのような要件がある場合は、リソース ロケーション制限の組織のポリシーが適用される可能性が高くなります。このポリシーでは、ポリシーに適合していない地理的位置を保管場所として使用しようとすると、[バックアップ] ページにアラートが表示されます。このアラートが表示された場合は、バックアップのロケーションをポリシーで許可されているロケーションに変更する必要があります。

バックアップのカスタム ロケーションを選択する場合は、次の点を考慮してください。

  • コスト: インスタンス内の、あるクラスタは、他のクラスタよりも低コストのリージョンにある可能性があります。
  • アプリケーション サーバーへの近接: バックアップは、できるだけ提供アプリケーションに近い場所に保管することをおすすめします。
  • ストレージの利用率: バックアップのサイズが大きくなると、維持するために十分な保存容量が必要になります。ワークロードに応じて、サイズやディスク使用量の異なるクラスタを作成できます。これはクラスタの選択に影響することがあります。

有効なリージョン値の完全なリストについては、インスタンスのロケーションをご覧ください。マルチリージョン値の完全なリストについては、マルチリージョンのロケーションをご覧ください。

バックアップのロケーションの設定と、インスタンスに対して実行されたバックアップのロケーションの詳細については、バックアップのカスタム ロケーションを設定するとバックアップのロケーションを表示するをご覧ください。

自動バックアップとトランザクション ログの保持

自動バックアップは Cloud SQL インスタンスの復元に使用されます。自動バックアップとトランザクション ログはポイントインタイム リカバリに使用されます。

保持期間を構成することによって、自動バックアップは最長 1 年間保持できますが、オンデマンド バックアップは、バックアップを削除するか、インスタンスが削除されるまで維持されます。

トランザクション ログは日数でカウントされますが、自動バックアップは 1 日で完了するとは限りません。これらの保持設定には別の単位が使用されます。自動バックアップの保持期間は 1～365 で設定できます。

トランザクション ログの保持期間は日単位です。Cloud SQL Enterprise Plus エディションのインスタンスの範囲は 1～35（デフォルト: 15）で、Cloud SQL Enterprise エディションのインスタンスの範囲は 1～7（デフォルト: 7）です。Cloud SQL Enterprise Plus エディション インスタンスの場合、トランザクション ログの保持設定をバックアップの保持設定よりも小さくする必要があります。

テスト インスタンスの場合、ログとバックアップは速く削除されるため、下限の設定は有用です。トランザクション ログの場合、下限を設定すると、ディスクサイズがそれほど大きくなりません。自動バックアップの保持期間に高い値を設定すると、さらに前の状態を復元できるようになります。

ログは継続的ではなく、1 日 1 回削除されます。ログの保持日数がバックアップ数と同じ場合、ログの保持期間が不足する可能性があります。たとえば、ログ保持期間を 7 日に設定し、保持するバックアップの数を 7 に設定すると、6～7 日分のログが保持されます。

バックアップの数は、保持するログの日数より 1 以上大きい数に設定することをおすすめします。

データベースに対する書き込みが多いと、大量のトランザクション ログが生成され、かなりのディスク容量を消費する可能性があります。ストレージの自動増量が有効になっているインスタンスでは、ディスクが増大する原因になります。インスタンスのストレージ サイズは、トランザクション ログの保持を考慮して調整することをおすすめします。

自動バックアップの保持期間の設定をご覧ください。

トランザクション ログ保持の設定をご覧ください。

バックアップをエクスポートできますか？

いいえ、バックアップをエクスポートすることはできません。エクスポートできるのは、インスタンス データのみとなります。Cloud SQL からのデータのエクスポートをご覧ください。

特別なバックアップ ユーザーについて

Cloud SQL は、各インスタンスに特別なデータベース ユーザーである cloudsqladmin を作成し、このユーザーのためにインスタンス固有の一意のパスワードを生成します。 Cloud SQL は、cloudsqladmin ユーザーとしてログインし、自動バックアップを実行します。

バックアップのインスタンス オペレーションへの影響

書き込みなどのオペレーションがバックアップ オペレーションの影響を受けることはありません。

バックアップのレート制限

Cloud SQL では、データディスクのバックアップ オペレーションのレートが制限されています。1 つのプロジェクトの 1 つのインスタンスで 50 分ごとに最大 5 つのバックアップ オペレーションが許可されます。バックアップ オペレーションが失敗した場合、この割り当てにカウントされません。上限に達するとオペレーションは失敗し、再試行が可能であることを示すエラー メッセージが表示されます。

では、Cloud SQL がバックアップのレート制限をどのように実行しているのか見てみましょう。

Cloud SQL は、バケットからのトークンを使用して、一度に実行可能なバックアップ オペレーションの数を決定します。各インスタンスにはバケットがあります。バケット内でバックアップ オペレーションに使用可能なトークンは最大 5 つです。10 分ごとに新しいトークンがバケットに追加されます。バケットがいっぱいの場合、トークンはオーバーフローします。

バックアップ オペレーションのたびに、バケットからトークンが付与されます。オペレーションが成功すると、バケットからトークンが削除されます。失敗した場合、トークンがバケットに返されます。次の図は、この仕組みを示しています。

トークンの仕組み

バックアップとデータの整合性チェック

Cloud SQL は、バックグラウンドでのデータベース整合性チェックを自動的に実行し、データの整合性の潜在的な問題を特定します。これらのチェックは、お客様が開始したバックアップのサンプリングの復元またはバックアップの復元を行うことで、オフライン プロセスとして行われます。

バックアップの復元

インスタンスが削除されると、Cloud SQL はすべてのバックアップを削除します。インスタンスが誤って削除されるのを防ぐため、Cloud SQL はインスタンスのバックアップを 4 日間保持します。削除されたインスタンスを復元するには、4 日以内に Google Cloud カスタマーケアにご連絡ください。

Cloud SQL は、すべてのアクティブなインスタンスに対して最後に実施された正常な日次バックアップを少なくとも 1 つ保持します。そのため、使用できる正常なバックアップがない場合は、Google Cloud カスタマーケアにお問い合わせいただくと、日次バックアップを使用してインスタンスを復旧できます。

ログに記録されていないテーブル

ログに記録されていないテーブルは、バックアップの復元中に自動的にワイプされます。

トラブルシューティング

問題 トラブルシューティング
現在のオペレーションのステータスを確認できない。 Google Cloud Console では、オペレーションの完了時に成功または失敗のみが表示されます。警告やその他の情報を表示するように設計されていません。

特定の Cloud SQL インスタンスのすべてのオペレーションを確認するには、gcloud sql operations list コマンドを実行します。
オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 オペレーションを開始したユーザーはユーザー インターフェースに表示されません。

ユーザーを特定するには、ログを表示してテキストでフィルタします。個人情報の監査ログが必要になる場合があります。関連するログファイルは次のとおりです。

  • cloudsql.googleapis.com/postgres.log
  • Cloud Audit Logs が有効で、表示に必要な権限がある場合は、cloudaudit.googleapis.com/activity を使用できる場合があります。
インスタンスを削除すると、その後インスタンスのバックアップは作成できません。

インスタンスの完全削除後にデータを復元することはできません。ただし、インスタンスが復元されると、バックアップも復元されます。削除したインスタンスの復元について詳しくは、復元バックアップをご覧ください。

エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。
自動バックアップが長時間停止していて、キャンセルできない。 データベースのサイズによっては、バックアップに時間がかかる可能性があります。

オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの force restart を依頼できます。
SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。 SQL ダンプを復元する前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが、ターゲット データベース内に存在している必要があります。そうでない場合、復元オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。

SQL ダンプを復元する前に、データベース ユーザーを作成します。
自動バックアップの保持日数を 7 日から 30 日以上に増やしたい。 保持する自動バックアップの数を構成できます（1～365 件の範囲）。自動バックアップは、構成された保持値に基づいて定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。

バックアップを無期限に保持する場合は、オンデマンド バックアップを作成します。オンデマンド バックアップは、自動バックアップと同じ方法では削除されません。オンデマンド バックアップは無期限に維持されます。つまり、削除されるか、所属するインスタンスが削除されるまで保持されます。このタイプのバックアップは自動的に削除されないため、課金に影響する可能性があります。
自動バックアップが失敗したときにメール通知を受信できない。 バックアップの失敗は通知されません。

自動バックアップが失敗すると、Cloud SQL インスタンスの Details ページに Operation error メッセージが表示されます。

バックアップのステータスは、REST API または gcloud コマンドで確認できます。たとえば、最初にインスタンスのバックアップ リストを取得してから、特定のバックアップをその ID で指定します。


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
インスタンスがエラー状態とバックアップ復元状態の間でループしているため、インスタンスが繰り返し失敗する。復元後にデータベースに接続して使用しようとすると失敗する。
  • オープン接続が多すぎる可能性があります。接続数が多すぎる原因として、切断された接続をクリーンアップする autovacuum 設定が存在しないために接続の途中でエラーが発生していることが考えられます。
  • カスタムコードで数回エラーが起きても停止しない再試行ロジックが使用されているため、ループが発生している可能性があります。
  • トラフィックが多すぎる可能性があります。接続プーリングなどの接続のベスト プラクティスを使用します。

次の方法をお試しください。

  1. データベースが autovacuum を使用する設定になっていることを確認します。
  2. カスタムコードに接続再試行ロジックが設定されているかを確認します。
  3. データベースが復旧するまでトラフィックを減らし、復旧後に徐々にトラフィックを増やします。
バックアップ / 復元オペレーションを実行したときにデータの欠落が見つかることがあります。 テーブルがログに記録されずに作成されました。次に例を示します。

CREATE UNLOGGED TABLE ...

これらのテーブルはバックアップからの復元には含まれません。

  • ログに記録されていないテーブルの内容は、HA インスタンスのフェイルオーバー後に保持されません。
  • ログに記録されていないテーブルは、Postgres のクラッシュ後に保持されません。
  • ログに記録されないテーブルはリードレプリカに複製されません。
  • ログに記録されていないテーブルは、バックアップの復元中に自動的にワイプされます。

解決策としては、バックアップを使用してテーブルを復元する場合に、ログに記録されていないテーブルを使用しないことです。すでにログに記録されていないテーブルがあるデータベースから復元する場合は、データベースをファイルにダンプし、これらのテーブルのダンプ済みファイルを ALTER TABLE から SET LOGGED に変更した後にデータを再読み込みできます。

次のステップ