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

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

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

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

バックアップの機能

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

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

バックアップの費用

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

インスタンスを停止または削除しても、Cloud SQL はインスタンスのバックアップを作成しません。インスタンスを削除すると、データは 4 日間保持されます。

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

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

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

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

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

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

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

バックアップの種類

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

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

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

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

自動バックアップ

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

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

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

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

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

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

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

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

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

バックアップのカスタム ロケーションの設定バックアップのロケーションの表示をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MySQL インスタンスでは、バックアップに FLUSH TABLES WITH READ LOCK フラグは使用されません。これは、バックアップ オペレーションによって書き込みなどのオペレーションが影響を受けないことを意味します。

通常、バックアップの作成は数秒で完了しますが、直近のバックアップ以降に大量のデータが書き込まれている場合は、さらに長くかかることがあります。

バックアップを作成しようとしたときに保留中のオペレーションがある場合、通常 Cloud SQL はバックアップを完了するための時間枠内に試行を数回繰り返します。インポート、エクスポート、更新(インスタンス メタデータの変更など)、インスタンスの再起動など、Cloud SQL インスタンスで長時間実行されるオペレーションは、バックアップを妨げるオペレーションとなります。

データの読み込みなど、長時間実行オペレーションの間は、一時的に自動バックアップを無効化できます。

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

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

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

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

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

トークンの仕組み

トラブルシューティング

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

特定の Cloud SQL インスタンスのすべてのオペレーションを確認するには、gcloud sql operations list コマンドを実行します。

オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 オペレーションを開始したユーザーはユーザー インターフェースに表示されません。

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

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • Cloud Audit Logs が有効で、表示に必要な権限がある場合は、cloudaudit.googleapis.com/activity を使用できる場合があります。
インスタンスの削除後にバックアップを実行できない。 Cloud SQL インスタンスの削除の猶予期間は 4 日間です。ただし、リードレプリカはすぐに削除されます。この間であれば、カスタマー サポートがインスタンスを再作成できます。インスタンスが再作成されると、バックアップも再作成されます。インスタンスの削除後にデータを復元することはできません。

エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。

自動バックアップが長時間停止していて、キャンセルできない。 データベースのサイズによっては、バックアップに時間がかかる可能性があります。

オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの force restart を依頼できます。

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

SQL ダンプを復元する前に、データベース ユーザーを作成します。

自動バックアップの保持日数を 7 日から 30 日以上に増やしたい。 保持されるバックアップは 7 つのみです。バックアップの保持には費用がかかり、ディスク容量が必要となるため、バックアップは定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。

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

自動バックアップが失敗したときにメール通知を受信できない。 バックアップの失敗は通知されません。

自動バックアップが失敗すると、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
    

次のステップ