このページでは、バックアップの概要、仕組み、一般的なユースケース、バックアップを作成して使用する際のベスト プラクティスについて説明します。バックアップの作成と管理を行う方法とバックアップから Filestore インスタンスを復元する方法については、障害復旧のためのデータのバックアップをご覧ください。
バックアップとは
Filestore バックアップは、バックアップ作成時点からのファイル共有のすべてのファイルデータとメタデータを含むファイル共有のコピーです。
ファイル共有のバックアップを作成した後、バックアップに影響を与えることなく、元のファイル共有を変更または削除できます。
バックアップを使用して、ファイル共有を新しい Filestore インスタンスに復元できます。また、ベーシック ティア インスタンスの場合は、既存のファイル共有のソースに復元できます。
バックアップは、作成時に指定したリージョン内に残るリージョン リソースです。Filestore インスタンスと同じリージョン、または別のリージョンにバックアップを作成して、データ損失のリスクを軽減できます。
バックアップはグローバル アドレスに対応しており、任意の リージョンにファイル共有を復元するために使用できますが、プロジェクト間で共有することはできません。
料金
ネットワーク転送料金は、リージョン間のネットワーク トラフィックに適用されます。詳細については、料金のページをご覧ください。
バックアップの作成
最初に作成するバックアップは、ファイル共有上のすべてのファイルデータとメタデータの完全なコピーです。以降の各バックアップでは、前回のバックアップ以降にデータに加えられた増分変更がすべてコピーされます。
バックアップ チェーン
同じインスタンス、リージョン、CMEK（使用されている場合）に関連付けられているバックアップのグループは、バックアップ チェーンと呼ばれます。
バックアップ チェーンは単一の Cloud Storage バケットとリージョンに存在し、ソース インスタンスの保存に使用されるリージョンの外部に配置できます。
すべてのサービスティアでは複数のバックアップ チェーンがサポートされるため、インスタンスのバックアップを複数のリージョンに保存できます。
バックアップが作成されるたびに、前回のバックアップで差分変更と増分変更の両方がスキャンされます。
差分変更: ファイルの編集、追加、削除など、共有内のファイルに加えられた変更が含まれます。
増分変更: バックアップ データが保存されているバケットのストレージに対する変更が含まれます。これには、チェーンで以前に参照されたデータの重複除去が含まれる場合があります。
バックアップを同じバックアップ チェーンに保存するたびに、前回のバックアップで差分変更と増分変更がスキャンされます。このような場合、完全なコピーは必要ありません。
ただし、インスタンスのデータを複数のバックアップ チェーンに保存することは、バックアップを交互の場所に保存することを意味します。
代替の場所に新しいバックアップを作成するたびに、バックアップの完全なコピーが再度生成されます。バックアップ チェーン間を交互に切り替えると、バックアップ create オペレーションのレイテンシ増加が予想されます。
以前のバックアップに含まれる未変更データは、新しいバックアップで参照されますが、コピーされません。古いバックアップが削除されると、その特異データが次の最新バックアップにコピーされ、すべての内部データ参照が自動的に更新されます。
内部的には、バックアップ チェーンの履歴はスナップショットを使用して追跡されます。スナップショットは、ソース インスタンスの容量を消費します。
バックアップの作成は瞬時に行われますが、バックアップが使用可能になる前にコピーされるデータ量に比例する時間を要します。この間に、バックアップは次の 3 つの状態を遷移します。
| 状態 | 所要時間 | 説明 |
|---|---|---|
| 作成 | 数秒 | ファイル共有の現在の状態をキャプチャする。ファイル共有データの新しい変更は、バックアップに含まれる場合と含まれない場合があります。バックアップが開始される前にインスタンスによって承認された安定した書き込みは追加されます。 |
| 最終処理中 | サイズに依存 | バックアップにデータをアップロードする。ファイル共有データの新しい変更は、バックアップに追加されません。 |
| 準備完了 | バックアップが削除されるまで | バックアップを使用する準備が完了しています。 |
作成後、ベーシック ティアのバックアップは自動的に圧縮され、コストが削減されます。 ゾーン、リージョン、エンタープライズのサービス階層でインスタンスのバックアップを作成している間、インスタンスのパフォーマンスが低下する場合があります。バックアップを作成しても、ベーシック ティア インスタンスの可用性やパフォーマンスには影響しません。
冗長データへの対処
デフォルトでは冗長データに対する料金が発生しないようにし、保存容量の使用を最小限に抑えるために、バックアップは増分バックアップとしています。基盤となる変更履歴の信頼性を確保するために、バックアップでインスタンスの完全なコピーが取得されることがあります。
詳細については、スナップショットとバックアップを比較するをご覧ください。
バックアップの削除
バックアップはプロジェクト レベルのリソースであり、ソース インスタンスのサブリソースではないため、独自の個別のストレージが必要です。そのため、バックアップのライフサイクルはソース インスタンスのライフサイクルには関連付けられません。ソースを削除しても、関連付けられているバックアップは削除されません。バックアップを削除する場合は、インスタンスではなくバックアップで削除オペレーションを明示的に実行する必要があります。
不要なバックアップは必ず削除してください。ソース インスタンスが削除されても、残りのバックアップには引き続き料金が発生します。
バックアップを削除すると、元に戻すことはできません。バックアップの削除が失敗すると、ステータスは invalid とマークされます。このような場合は、delete オペレーションを再試行します。
バックアップの整合性
Filestore バックアップには、NFSv3 と NFSv4.1 の整合性セマンティクスがあります。バックアップが開始される前に、Filestore インスタンスが安定したストレージに書き込まれたものと認識した書き込み、または後に確認済みの COMMIT が続く書き込みは、バックアップに追加されます。詳細については、NFSv3 RFC-1813 のセクション 3.3.7 またはサポートされているファイル システム プロトコルについてをご覧ください。
一般的なユースケース
以降のセクションでは、バックアップの一般的なユースケースについて説明します。
障害復旧用のデータのバックアップ
us-west1-c に Filestore インスタンスがあり、このリージョンに影響する障害からデータを保護する必要があるとします。このインスタンスのバックアップを定期的に遠隔のリージョン（たとえば、us-
east1）に作成するジョブのスケジュールを設定できます。us-west1-c に災害が発生した場合、以前のバックアップから別のロケーションに新しいインスタンスを作成できます。
不注意による変更を防ぐためのデータのバックアップ
Filestore データを意図しない変更から保護するには、インスタンスのバックアップを定期的に作成するジョブをスケジュールします。データを紛失した場合は、バックアップのリストを参照して、必要なファイルのバージョンを含むバックアップを特定できます。その後、バックアップから新しい Filestore インスタンスを作成して、元のインスタンスと同じクライアントにマウントし、ファイルをコピーできます。
ファイルをコピーする前に、2 つのマウント ポイントで Linux diff コマンドを使用して、元のインスタンスのデータとバックアップから復元したデータの差異を確認できます。データを復元したら、復元したインスタンスを削除し、新しいバックアップを作成して、将来の使用のためにデータの現在の状態を保持できます。
または、バックアップ データが元の Filestore インスタンスに直接復元されるインプレース復元を実行して、すべてのデータをバックアップのデータに置き換えることができます。バックアップしていないデータが失われるため、インプレース復元を行う前に最新データのバックアップを作成することをおすすめします。
開発およびテスト用クローンを作成する
本番環境のトラフィックを処理する Filestore インスタンスにデータベースが設定されているとします。データベースを入力として使用してテストを実施する場合は、テスト用の本番環境インスタンスのバックアップから新しい Filestore インスタンスを作成できます。このように、テストを実施しても、本番環境には影響が及びません。
同様に、本番環境に影響を与えることなく、バックアップを使用してオフライン分析と調査を行うことができます。
データの移行
Filestore インスタンスを作成したら、そのロケーションやサービス階層は変更できません。データを別のリージョンに移行するには、そのバックアップを作成し、そのバックアップを使用して新しい Filestore インスタンスを作成するか、既存のインスタンスに復元できます。
機能の制限事項
Filestore バックアップは、すべてのサービスティアで一般提供（GA）されています。
Filestore のバックアップは、Filestore マルチシェア機能と組み合わせることはできません。
次のセクションでは、パフォーマンス、ストレージ、容量、暗号化などに関するその他の機能の制限について詳しく説明します。
パフォーマンス
使用率の高いインスタンスでは、バックアップのアップロード中のパフォーマンスが最大 15% 低下する可能性があります。ベーシック ティア インスタンスのパフォーマンスは、バックアップ
createオペレーションの影響を受けません。インスタンスのデータを複数のバックアップ チェーンに保存すると、バックアップのパフォーマンスに影響します。バックアップ チェーンを交互に切り替えると、バックアップ
createオペレーションのレイテンシ増加が予想されます。インスタンス
restoreやインスタンスdeleteなどのインスタンス オペレーションは、バックアップcreateオペレーションが完了するまで遅延する可能性があります。場合によっては、
deleteオペレーションの完了に最長で 24 時間かかることがあります。
オペレーションの同時実行
同じソース インスタンスに関連付けられるバックアップ
deleteオペレーションは、一度に 1 つずつ実行する必要があります。同じバックアップ チェーン内での一括バックアップ
deleteオペレーションはサポートされていません。deleteオペレーションが保留となっている間、同じバックアップ チェーン内の新しいdeleteオペレーションは、RESOURCE_EXHAUSTEDエラーで返ります。これは、元のインスタンスが削除されたかどうかに関係なくそうなります。ソース インスタンスが削除されている場合は、FAILED_PRECONDITIONエラーが発生します。Filestore は、バックアップが個別のソース インスタンスを参照するときの、同時バックアップ
deleteオペレーションをサポートしています。たとえば、
Source1というラベルのインスタンスには、Backup1とBackup2で参照されるバックアップ データがあり、Source2には、Backup3とBackup4で参照されるバックアップ データがあるとします。Backup1とBackup2は並行して削除できませんが、Backup2とBackup3は並行して削除できます。同じバックアップ チェーン内で開始されたバックアップ
createとバックアップdeleteのオペレーションは同時に実行できます。新しいバックアップの作成をすでに開始している場合は、オペレーションが完了するまで待ってから、最新の既存のバックアップを削除する必要があります。これは、最新のバックアップに、バックアップcreateオペレーションを正常に完了するために必要な最も重要なデータが含まれているためです。最新のバックアップを削除しようとすると、FAILED_PRECONDITIONエラーが発生します。たとえば、
Source1にはBackup1とBackup2で構成されるバックアップ チェーンがあります。Backup3のcreateオペレーションを開始すると、createオペレーションが完了するまでBackup2を削除できません。オペレーションのレート制限の詳細については、バックアップのオペレーションのレート制限をご覧ください。
ストレージ
ベーシック インスタンスのバックアップは、同じサービスティアのソース インスタンス、既存のインスタンス、または新しいインスタンスに復元できます。新しいインスタンスを選択する場合は、ソース インスタンスの階層に関係なく、ベーシック HDD インスタンスかベーシック SSD インスタンスを選択できます。
ゾーン インスタンス、リージョン インスタンス、エンタープライズ インスタンスは、ソース インスタンスまたは既存のインスタンスに復元できません。新しいインスタンスにのみ復元できます。新しいインスタンスの階層は、ソース インスタンスの階層と一致している必要はありません。たとえば、リージョン インスタンスのバックアップをゾーン インスタンスに復元できます。新しいインスタンスのプロビジョニングされた容量は、移行元インスタンスのプロビジョニングされた容量以上である必要があります。
容量
ゾーン インスタンス、リージョン インスタンス、エンタープライズ インスタンス用に作成されたバックアップは、インスタンス容量を消費する可能性があります。この容量は、バックアップが作成されてからデータに加えられた変更のスコープによって異なります。具体的には、バックアップが作成されると、Filestore はファイルシステムの内部スナップショットを作成します。このスナップショットも、使用可能なインスタンス容量の一部を占有します。
また、スナップショット サイズは、最後のバックアップが作成されてから共有内のデータに加えられた変更のスコープにも関係します。このスナップショットは、次のバックアップが作成されてアップロードされるまで存在し続けます。
バックアップで参照されるすべてのデータは、キャプチャされた時点の状態のままで保持され、ファイル システムから容量を消費し続けます。たとえば、マウントされたファイル システムからデータを削除しても、そのアクション自体で空き容量が増えることはありません。代わりに、大量のデータを削除または上書きした後に新しいバックアップを作成します。
差分と増分変更の詳細、およびその処理方法については、バックアップの作成をご覧ください。
ワークロードに対する十分な容量を見積もるには、次のいずれかを検討してください。
頻繁に行われるデータ変更や「変更率が高い」ワークロードに対応するインスタンス容量を増やす。
頻繁にバックアップを作成します。最後のバックアップが古い場合、内部スナップショットでより多くの変更が蓄積され、インスタンス容量がより多く消費される可能性があります。
暗号化
CMEK を使用してバックアップ チェーンを暗号化する場合、次の制限が適用されます。
バックアップ チェーン全体が同じ CMEK を使用して暗号化されます。
CMEK を使用してバックアップを作成する場合、CMEK はターゲット バックアップと同じリージョンに存在する必要があります。
バックアップ チェーンをソース インスタンスとは別のリージョンに保存する場合は、ソース用とバックアップ チェーン用の別々の鍵を適用する必要がある場合があります。
- すべてのサービス階層では、複数のバックアップ チェーン、またはインスタンスのバックアップを複数のリージョンに保存できます。暗号化に CMEK を使用する場合は、CMEK 鍵は暗号化するリソースと同じリージョンに存在する必要があります。バックアップをソースとは別のリージョンに保存していて、CMEK がマルチリージョン鍵でない場合は、個別の CMEK 鍵を使用する必要があります。詳細については、CMEK の制限事項と最適な CMEK ロケーションの選択をご覧ください。
バックアップ チェーンが保存されている Cloud Storage バケットに単一の CMEK が適用されます（組み合わせや置換はできません）。
CMEK のサポートは、ベーシック ティアのバックアップでは使用できません。
詳細については、バックアップ チェーンの CMEK サポートをご覧ください。
プロトコル
- バックアップを復元する場合、新しいインスタンスはソース インスタンスと同じプロトコルを使用する必要があります。
ベスト プラクティス
以降のセクションでは、推奨されるベスト プラクティスについて説明します。
最適なバックアップ整合性を確保するため、ファイル共有を準備する
バックアップの品質は、大量の書き込みワークロード中に作成されたバックアップから復元するアプリケーションの能力によって決まります。ほとんどの場合、アプリケーションがファイル共有にデータを書き込んでいる間でも、優れた整合性を持つバックアップを作成できます。ただし、アプリケーションで厳密な整合性が求められる場合は、次のうち 1 つ以上を行うことをおすすめします。
- sync マウントを使用する。詳細については、nfs(5) の「同期マウント オプション」をご覧ください。または、
O_DIRECT|O_SYNCフラグを使用してファイルを開くこともできます。詳細については、open(2) をご覧ください。 - ファイル共有にデータを書き込むアプリケーションまたはオペレーティング システム プロセスを一時停止し、バックアップを開始する前にファイル共有に対する変更をフラッシュする。詳細については、fsync(2) をご覧ください。
- アプリケーションで複数の共有間の整合性が求められる場合は、すべてのアプリケーションに書き込む全インスタンスの全アプリケーションを一時停止し、すべてのファイル共有のバックアップを作成してから、アプリケーションを再開する。
- アプリケーション レベルの整合性が必要な場合は、バックアップを作成する前に、アプリケーションを停止して、ファイル共有のマウントを解除する。
既存のバックアップを新しいバックアップのベースラインとして使用して、バックアップの作成時間を短縮する
リージョン内のファイル共有の既存のバックアップは、ファイル共有の新しいバックアップを作成するためのベースラインとして使用され、バックアップの作成時間を短縮します。 そこで、次の手順を行うことをおすすめします。
ファイル共有の新しいバックアップを作成してから、そのファイル共有の以前のバックアップを削除します。
新しいバックアップが
Ready状態になるまで待ってから、同じファイル共有の後続のバックアップを作成します。
バックアップの作成時間を短縮するために、オフピーク時にバックアップのスケジュールを設定する
オフピーク時にバックアップを作成すると、バックアップの作成に要する時間が短縮されます。ファイル共有の定期的なバックアップのスケジュールを設定する場合は、可能な限りオフピーク時にスケジュール設定することをおすすめします。
バックアップ作成のピーク時間帯は、各営業日の終了時と、Filestore インスタンスが配置されているリージョンの午前 0 時です。早朝または営業時間中にバックアップを作成することをおすすめします。
効率を最大限高めるために、個別の Filestore インスタンスでデータを整理する
ファイル共有のデータが多いほど、バックアップのサイズが大きくなり、コストも増大します。バックアップが必要なデータのみをバックアップするには、次のように、データを別々のファイル共有に整理することをおすすめします。
- 書き込みパターンごと、またはバックアップ要件ごとに、異なるファイル共有に重要データを保存する。
- 1 つのファイル共有に類似のデータを保存することで、作成する必要のあるバックアップの数を減らす。
割り当て
基本 SSD サービス階層および基本 HDD サービス階層では、リージョンあたりのバックアップ数に対して割り当ての上限が存在します。
バックアップの割り当て上限は、ゾーン、リージョンとエンタープライズのサービス階層には適用されません。
詳細については、サービス階層と割り当てをご覧ください。
Filestore バックアップの使用を開始する
当該機能の使用を開始するには、障害復旧用のデータのバックアップをご覧ください。
次のステップ
- ファイル共有のバックアップおよび復元方法を学習する。
- Cloud Scheduler を使用してバックアップをスケジュールする方法を学習する。
- Google Cloud リージョンとゾーンについて学習する。
- バックアップの料金について学習する。