バックアップの概要

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

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

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

バックアップの機能

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

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

バックアップの費用

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

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

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

バックアップは、保持ポリシーに従って 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 インスタンスで長時間実行されるオペレーションは、バックアップを妨げるオペレーションとなります。

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

トラブルシューティング

問題 トラブルシューティング
現在のオペレーションのステータスを確認できない。 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 つまでです。バックアップの保持には費用がかかり、ディスク容量が必要となるため、バックアップは定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。

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

バックアップが失敗し、Unknown error メッセージが表示される。 バックアップ オペレーションがタイムアウトした可能性があります。

バックアップの作成に影響するフラグは checkpoint_timeoutcheckpoint_completion_target の 2 つです。バックアップの開始時に slow チェックポイントが実行されます。この処理には、checkpoint_completion_targetcheckpoint_timeout を掛けた時間がかかります。

例: 900 sec * 0.9 sec = 810 sec = 13.5 min

このため、タイムアウトが発生します。この場合は、checkpoint_completion_target の値を減らすことで問題が解決されます。

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

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

次のステップ