このページでは、Cloud SQL インスタンスのバックアップの仕組みについて説明します。プライマリ インスタンス上でバックアップを実行できます。
バックアップのスケジュールやオンデマンド バックアップの作成の詳細については、オンデマンド バックアップと自動バックアップの作成と管理をご覧ください。
バックアップからインスタンスにデータを復元する方法の概要については、インスタンスの復元の概要をご覧ください。
バックアップの機能
バックアップにより、失われたデータを Cloud SQL インスタンスに復元できます。また、インスタンスに問題がある場合は、バックアップを使用してインスタンスを上書きすることで以前の状態に戻すことができます。必要なデータを含むインスタンスを自動的にバックアップできます。バックアップはデータの損失や破損を防ぎます。
バックアップの費用
デフォルトでは、Cloud SQL はオンデマンド バックアップに加えて 7 件の自動バックアップを保持します。保持する自動バックアップの数を構成できます（1～365 の範囲）。バックアップ ストレージの料金は、他のタイプのインスタンスの料金よりも低額です。
保持できる自動バックアップ数は 7 件以上です。Cloud SQL では、インスタンスを停止または削除すると、インスタンスのバックアップは作成されません。インスタンスを削除した場合、データは 4 日間しか保持されません。インスタンスとそのデータを復元するには、4 日以内に、必要なすべてのインスタンス情報を添えて Google Cloud サポートにお問い合わせください。
詳しくは料金ページをご覧ください。
バックアップとエクスポート
バックアップは、保持ポリシーに従って Cloud SQL によって管理され、Cloud SQL インスタンスとは別に保存されます。Cloud SQL バックアップは、ライフサイクルを管理する Cloud Storage にアップロードされるエクスポートとは異なります。バックアップにはデータベース全体が含まれます。エクスポートでは特定のコンテンツを選択できます。
バックアップや復元のオペレーションを使用してデータベースを新しいバージョンにアップグレードすることはできません。バックアップから復元できるのは、同じデータベース バージョンのインスタンスに限られます。
新しいバージョンにアップグレードするには、データベースをエクスポートして新しい Cloud SQL インスタンスにインポートします。バックアップ サイズについて
Cloud SQL のバックアップは増分バックアップです。このバックアップには、前回のバックアップの作成後に変更されたデータのみが含まれます。最も古いバックアップはデータベースと同様のサイズですが、その後のバックアップのサイズはデータの変更の割合によって異なります。最も古いバックアップが削除されると、フル バックアップを維持するため、その次に古いバックアップのサイズが増加します。
バックアップの種類
Cloud SQL は、次の 2 種類のバックアップを実行します。
オンデマンド バックアップ
バックアップはいつでも作成できます。そのため、データベース上でリスクの高いオペレーションを実行しようとしている場合や、バックアップ時間枠まで待機することなくバックアップを作成することが必要な場合でも、不都合が生じることはありません。オンデマンド バックアップは、インスタンスで自動バックアップが有効であるかどうかにかかわらず、すべてのインスタンスで作成できます。
オンデマンド バックアップは、自動バックアップと異なり、自動的に削除されません。 明示的に削除するか、インスタンスが削除されるまで維持されます。オンデマンド バックアップは自動的に削除されないため、請求料金に長期間な影響を及ぼす可能性があります。
自動バックアップ
自動バックアップは、4 時間のバックアップ時間枠内に毎日行われます。バックアップは、バックアップ時間枠内に開始されます。可能な場合は、インスタンスのアクティビティが最も少ない時間帯にバックアップをスケジュールしてください。
自動バックアップはポイントインタイム リカバリのサポートに必要なため、削除しないことをおすすめします。
インスタンスが実行されているすべての日で、バックアップ時間枠内に自動バックアップが実行されます。インスタンスが停止すると、追加の自動バックアップが作成され、インスタンスが停止する前にすべての変更が保護されます。デフォルトでは、最新の 7 件のバックアップが保持されます。保持する自動バックアップの数を構成できますが、デフォルト（7）よりも少ない数を保持することはできません。
バックアップが保存される場所
バックアップ ロケーションには、次のものがあります。
- Cloud SQL が選択したデフォルトの場所（元のインスタンスの場所に基づく）。
- デフォルト ロケーションを使用しない場合に選択するカスタム ロケーション。
デフォルト バックアップ ロケーション
ストレージ ロケーションを指定しない場合、バックアップは Cloud SQL インスタンスのロケーションに最も近いマルチリージョン ロケーションに保存されます。たとえば、Cloud SQL インスタンスが us-central1 にある場合、デフォルトでは us マルチリージョンにバックアップが保存されます。ただし、australia-southeast1 のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンは asia です。
カスタム バックアップ ロケーション
Cloud SQL では、バックアップ データのカスタム ロケーションを選択できます。これは、バックアップの保管場所を特定の地理的境界内に限定する規制を組織が遵守しなければならない場合に便利です。組織に対してこのような要件がある場合は、リソース ロケーション制限の組織のポリシーが適用される可能性が高くなります。このポリシーでは、ポリシーに適合していない地理的位置を保管場所として使用しようとすると、[バックアップ] ページにアラートが表示されます。このアラートが表示された場合は、バックアップのロケーションをポリシーで許可されているロケーションに変更する必要があります。
バックアップのカスタム ロケーションを選択する場合は、次の点を考慮してください。
- コスト: インスタンス内の、あるクラスタは、他のクラスタよりも低コストのリージョンにある可能性があります。
- アプリケーション サーバーへの近接: バックアップは、できるだけ提供アプリケーションに近い場所に保管することをおすすめします。
- ストレージの利用率: バックアップのサイズが大きくなると、維持するために十分な保存容量が必要になります。ワークロードに応じて、サイズやディスク使用量の異なるクラスタを作成できます。これはクラスタの選択に影響することがあります。
有効なリージョン値の完全なリストについては、インスタンスのロケーションをご覧ください。マルチリージョン値の完全なリストについては、マルチリージョンのロケーションをご覧ください。
バックアップのロケーションの設定と、インスタンスに対して実行されたバックアップのロケーションの詳細については、バックアップのカスタム ロケーションを設定するとバックアップのロケーションを表示するをご覧ください。
自動バックアップの保持期間
自動バックアップの保持期間はデフォルト（7）以上に設定できます。
自動バックアップの保持期間の設定をご覧ください。
バックアップをエクスポートできますか？
いいえ、バックアップをエクスポートすることはできません。エクスポートできるのは、インスタンス データのみとなります。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 インスタンスのすべてのオペレーションを確認するには、 |
| オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 | オペレーションを開始したユーザーはユーザー インターフェースに表示されません。 ユーザーを特定するには、ログを表示してテキストでフィルタします。個人情報の監査ログが必要になる場合があります。関連するログファイルは次のとおりです。
|
| インスタンスを削除すると、その後インスタンスのバックアップは作成できません。 | インスタンスの完全削除後にデータを復元することはできません。ただし、インスタンスが復元されると、バックアップも復元されます。削除したインスタンスの復元について詳しくは、復元バックアップをご覧ください。 エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。 |
| 自動バックアップが長時間停止していて、キャンセルできない。 | データベースのサイズによっては、バックアップに時間がかかる可能性があります。 オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの |
| SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。 | SQL ダンプを復元する前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが、ターゲット データベース内に存在している必要があります。そうでない場合、復元オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。 SQL ダンプを復元する前に、データベース ユーザーを作成します。 |
| 自動バックアップの保持日数を 7 日から 30 日以上に増やしたい。 | 保持する自動バックアップ数を構成できますが、デフォルト値（7 件）未満の数は保持できません。自動バックアップは、構成された保持値に基づいて定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。 バックアップを無期限に保持する場合は、オンデマンド バックアップを作成します。オンデマンド バックアップは、自動バックアップと同じ方法では削除されません。オンデマンド バックアップは無期限に維持されます。つまり、削除されるか、所属するインスタンスが削除されるまで保持されます。このタイプのバックアップは自動的に削除されないため、課金に影響する可能性があります。 |
| 自動バックアップが失敗したときにメール通知を受信できない。 | Cloud SQL からバックアップのステータスの通知を受信するには、ログベースのアラートを構成します。 |
| Transact-SQL RESTORE コマンドや SQL Server Management Studio（SSMS）を使用してインスタンスを復元することはできません。 |
Cloud SQL は、SSMS を介したインスタンスの復元をサポートしていません。インスタンスを復元するには、gcloud sql import コマンドを実行します。 |