バックアップの概要

このページでは、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 種類のバックアップを実行します。

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

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

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

オンデマンド バックアップ オペレーションのステータスを表示するには:

  1. オペレーション ID を取得するには、gcloud sql operations list コマンドを使用します。
  2. オペレーションのステータスを取得するには、gcloud sql operations describe コマンドを使用します。
または
  1. オペレーション ID を取得するには、REST operations.list API 呼び出しを使用します。
  2. オペレーションのステータスを取得するには、REST operations.get API 呼び出しを使用します。

自動バックアップ

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

バックアップ時間枠内に、インスタンスが実行されているすべての日に自動バックアップが実行されます。インスタンスが停止すると、追加の自動バックアップが作成され、インスタンスが停止する前にすべての変更が保護されます。デフォルトでは、最新の 7 件のバックアップが保持されます。保持する自動バックアップの数を構成できます(1~365 の範囲)。

インスタンスが 36 時間以上停止されている場合、自動バックアップは停止します。バックアップとトランザクションのログの保持期間の値はデフォルト設定から変更できます。詳細

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

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

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

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

単一のリージョンを指定し、そのリージョンが停止している場合、インスタンスがダウンしている間はバックアップを復元できません。

バックアップが複数のリージョンに保存され、ソース インスタンスを含むリージョンが停止した場合は、バックアップを別のリージョンの新規または既存のインスタンスに復元できます。復元する対象として選択したバックアップは、停止していないリージョンに存在する必要があります。プロジェクト内のすべてのバックアップのリストを取得するには、停止時にバックアップのリストを表示するをご覧ください。別のインスタンスにバックアップを復元するには、別のインスタンスへの復元をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

トラブルシューティング

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
現在のオペレーションのステータスを確認できない。 ユーザー インターフェースには成功または失敗のみが表示されます。 詳細については、これらのデータベース コマンドをご覧ください。
オペレーションの開始元が見つからない。 ユーザー インターフェースにはオペレーションを開始したユーザーは表示されません。 監査ロギングを使用して確認します。
自動バックアップ中のディスク容量が不足する。 インスタンスがハードディスクの容量の上限に達しました。 ファイル システムのサイズと割り当てを確認します
インスタンスの削除後にバックアップを実行できない。 インスタンスが削除されました。 エクスポートから再作成するか、猶予期間内であればカスタマー サポートにお問い合わせください。
自動バックアップが停止している可能性がある。 バックアップ時間はデータベースのサイズと相関しています。 オペレーションをキャンセルする必要がある場合は、カスタマー サポートお問い合わせください
復元に失敗した。 ダンプファイルに、まだ存在していないデータベース ユーザーが含まれている可能性があります。 復元する前にデータベース ユーザーを作成します
このインスタンスに対するオペレーションが無効。 コピー先インスタンスのサイズがコピー元よりも小さくなります。 宛先インスタンスのサイズを増やします
自動バックアップを保持する日数を増やす。 保持される自動バックアップは 7 つのみです。 手動バックアップを管理します
バックアップ失敗時の不明なエラー。 バックアップがタイムアウトした可能性があります。 これらのフラグを確認します。
バックアップの失敗について通知されない。 バックアップ失敗の通知はサポートされていません。 バックアップのステータスを確認するには、REST API または gcloud コマンドを使用します。
インスタンスがエラー状態とバックアップ復元状態の間でループし、停止する トラフィックが多すぎるか、オープン接続が多すぎます。 autovacuum 設定と再試行ロジックを確認します
バックアップにデータがない。 ログに記録されていないテーブルはバックアップから復元されません。 ログに記録されていないテーブルについては、こちらの注意事項をご覧ください。

現在のオペレーションのステータスを確認できない

Google Cloud Console でオペレーションのステータスを確認することはできません。

次のような問題が考えられます

Google Cloud Console では、完了時に成功または失敗のみが表示され、警告は返されません。

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

データベースに接続し、SHOW WARNINGS を実行します。


オペレーションの開始元が見つからない

オンデマンド バックアップ オペレーションを開始したユーザーを確認する場合。

次のような問題が考えられます

Google Cloud Console のインスタンス オペレーション ページには、オペレーションを開始したユーザーは表示されません。

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

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

  • cloudsql.googleapis.com/postgres.log
  • Cloud Audit Logs が有効になっている場合は、cloudaudit.googleapis.com/activity も使用できます。


自動バックアップ中のディスク容量が不足する

エラー メッセージ [ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written. が表示されます。

次のような問題が考えられます

インスタンスが自動バックアップ中にハードリミットに達しました。一時ファイルは、バックアップ中に使用可能なディスク容量を超える可能性があります。

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

ディスクに空きがあること、ディスク割り当てが不足していないことを確認します。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。


インスタンスの削除後にバックアップを実行できない

インスタンスを削除した後はバックアップを実行できません。

次のような問題が考えられます

インスタンスが削除されました。

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

  • Cloud SQL インスタンスの削除の猶予期間は 4 日間です。この間、カスタマー サポートがインスタンスを再作成できます。インスタンスを削除した後は、データを復元できません。
  • エクスポートを行った場合は、新しいインスタンスを作成してからインポートを実行して、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。

自動バックアップが停止している

自動バックアップが長時間停止していて、キャンセルできません。

次のような問題が考えられます

データベースのサイズによっては、バックアップに時間がかかる可能性があります。

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

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


バックアップからの復元が失敗した

SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。

次のような問題が考えられます

SQL ダンプを復元する前に、オブジェクトを所有しているか、またはダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが存在する必要があります。 そうでない場合、復元で、元の所有権や権限でのオブジェクトの再作成に失敗します。

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

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


このインスタンスに対するオペレーションが無効

instances.restoreBackup に対する API 呼び出しからのエラー メッセージ HTTP Error 400: This operation isn't valid for this instance が表示されます。

次のような問題が考えられます

バックアップ サイズ(XX GB)がストレージ サイズ(YY GB)より小さいインスタンスには、バックアップから復元できません。

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

ターゲット インスタンスを編集して、ストレージ サイズを増やします。


インスタンスがエラー状態とバックアップ復元状態の間でループし、停止する

インスタンスがエラー状態とバックアップ復元状態の間でループすることで、インスタンスが繰り返し失敗します。復元後にデータベースに接続して使用しようとすると失敗します。

次のような問題が考えられます

  • オープン接続が多すぎる可能性があります。接続数が多すぎる原因として、切断された接続をクリーンアップする autovacuum 設定が存在しないために接続の途中でエラーが発生していることが考えられます。
  • 数回エラーが起きても停止しない再試行ロジックがカスタムコードに使用されているために、ループが発生している可能性があります。
  • トラフィックが多すぎる可能性があります。接続プーリングなどの接続のベスト プラクティスを使用してください。

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

  1. データベースが autovacuum を使用する設定になっていることを確認します。
  2. カスタムコードに接続再試行ロジックが設定されているかを確認します。
  3. データベースが復旧するまでトラフィックを減らしてから、徐々にトラフィックを増やします。

バックアップにデータがない

バックアップ / 復元オペレーションを実行したときにデータの欠落が見つかることがあります。

次のような問題が考えられます

テーブルがログに記録されずに作成されました。例:

CREATE UNLOGGED TABLE ...

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

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

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

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


自動バックアップを保持する日数を増やす

自動バックアップを保持できる日数を 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 --project=PROJECT_ID backups list --instance=INSTANCE_ID
gcloud sql --project=PROJECT_ID backups describe BACKUP-ID --instance=INSTANCE_ID

次のステップ