バックアップの概要

このページでは、バックアップの概要、仕組み、一般的なユースケース、バックアップを作成して使用する際のベスト プラクティスについて説明します。バックアップの作成と管理を行う方法とバックアップから Filestore インスタンスを復元する方法については、障害復旧のためのデータのバックアップをご覧ください。

バックアップとは

Filestore バックアップは、バックアップ作成時点からのファイル共有のすべてのファイルデータとメタデータを含むファイル共有のコピーです。

ファイル共有のバックアップを作成した後、元のファイル共有を変更または削除できます。バックアップには影響しません。

バックアップを使用して、ファイル共有を新しい Filestore インスタンスに復元できます。また、ベーシック ティア インスタンスの場合は、ソースまたは既存のファイル共有に復元できます。

バックアップは、作成時に指定したリージョン内に残るリージョン リソースです。Filestore インスタンスと同じリージョン、または別のリージョンにバックアップを作成することで、データ損失のリスクを軽減できます。

バックアップはグローバル アドレスに対応しており、任意の リージョンにファイル共有を復元するために使用できますが、プロジェクト間で共有することはできません。

バックアップの作成

最初に作成するバックアップは、ファイル共有上のすべてのファイルデータとメタデータの完全なコピーです。以降の各バックアップでは、前回のバックアップ以降にデータに加えられた増分変更がすべてコピーされます。

同じインスタンス、リージョン、CMEK（使用されている場合）に関連付けられたバックアップのグループは、バックアップ チェーンと呼ばれます。

バックアップ チェーンは、1 つの Cloud Storage バケットとリージョンに存在し、ソース インスタンスの保存に使用されるリージョン外に配置できます。

すべてのサービスティアでは複数のバックアップ チェーンがサポートされるため、インスタンスのバックアップを複数のリージョンに保存できます。

バックアップが作成されるたびに、前回のバックアップが差分と増分変更の両方についてスキャンされます。

  • 差分変更: ファイルの編集、追加、削除など、共有上のファイルに対する変更が含まれます。

  • 増分変更: バックアップ データが配置されているバケット内のストレージへの変更が含まれます。これには、以前にチェーンで参照されたデータの重複排除が含まれる場合があります。

バックアップを同じバックアップ チェーンに保存するたびに、前回のバックアップがスキャンされ、差分と増分変更が行われます。このような場合、完全なコピーは必要ありません。

ただし、インスタンスのデータを複数のバックアップ チェーンに保存すると、バックアップを保存して別の場所に保存することになります。

代替ロケーションに新しいバックアップを作成するたびに、バックアップの完全なコピーが再生成されます。バックアップ チェーン間を交互に切り替えると、バックアップ create オペレーションのレイテンシ増加が予想されます。

以前のバックアップに含まれる未変更データは、新しいバックアップで参照されますが、コピーされません。古いバックアップが削除されると、その特異データが次の最新バックアップにコピーされ、すべての内部データ参照が自動的に更新されます。

バックアップの作成は瞬時に行われますが、バックアップが使用可能になる前にコピーされるデータ量に比例する時間を要します。この間に、バックアップは次の 3 つの状態を遷移します。

状態 期間 説明
作成中 数秒 ファイル共有の現在の状態をキャプチャする。ファイル共有データの新しい変更は、バックアップに含まれる場合と含まれない場合があります。バックアップが開始される前にインスタンスによって承認された安定した書き込みは追加されます。
最終処理中 サイズに依存 バックアップにデータをアップロードする。ファイル共有データの新しい変更は、バックアップに追加されません。
Ready バックアップが削除されるまで バックアップを使用する準備が完了しています。

作成後、ベーシック ティアのバックアップは自動的に圧縮され、コストが削減されます。 ゾーン（以前は高スケール SSD）とエンタープライズのサービス階層でインスタンスのバックアップを作成している間、インスタンスのパフォーマンスが低下する場合があります。バックアップを作成しても、ベーシック ティア インスタンスの可用性やパフォーマンスには影響しません。

バックアップの削除

バックアップはプロジェクト レベルのリソースであり、ソース インスタンスのサブリソースではありません。独自の独立したストレージが必要です。そのため、バックアップのライフサイクルはソース インスタンスのライフサイクルには関連付けられません。ソースを削除しても、関連付けられているバックアップは削除されません。バックアップを削除する場合は、インスタンスではなくバックアップで削除オペレーションを明示的に実行する必要があります。

不要なバックアップがある場合は、必ず削除してください。ソース インスタンスが削除されても、残りのバックアップは引き続き料金が発生します。

バックアップの削除は永続的であり、元に戻すことはできません。

バックアップの整合性

Filestore バックアップには、NFSv3 整合性セマンティクスがあります。バックアップが開始される前に、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 インスタンスを作成する場合、ソース インスタンスの階層に関係なく、ベーシック HDD かベーシック SDD の階層を選択できます。

機能の制限事項

Filestore バックアップは、すべてのサービス階層で一般提供（GA）されています。

次の制限が適用されます。

  • Filestore のバックアップは、Filestore マルチシェア機能と組み合わせることはできません。

  • 料金が導入されると、関連する料金が適用されます。

  • ユーザーは、新しいバックアップを作成して、プレビューで作成したものに置き換える必要があります。プレビューで作成されたバックアップは削除される場合があります。プレビューで作成されたバックアップには、作成時に利用可能だった機能の動作が反映されています。新しい機能がリリースされても、既存のバックアップは更新されません。

以下のセクションでは、パフォーマンス、ストレージ、容量、暗号化に関連するその他の機能制限について詳しく説明します。

パフォーマンス

  • 同じファイル上にある多数のハードリンクに関わる数多くの変更が行われると（数万、数十万など）、パフォーマンスに影響する可能性があります。

  • 使用率の高いインスタンスでは、バックアップのアップロード中のパフォーマンスが最大 15% 低下する可能性があります。ベーシック ティア インスタンスのパフォーマンスは、バックアップ create オペレーションの影響を受けません。

  • インスタンスのデータを複数のバックアップ チェーンに保存すると、バックアップのパフォーマンスに影響します。バックアップ チェーンを交互に切り替えると、バックアップ create オペレーションのレイテンシ増加が予想されます。

  • インスタンス restore やインスタンス delete などのインスタンス オペレーションは、バックアップ create オペレーションが完了するまで遅延する可能性があります。

  • delete のオペレーションが完了するまでに、最長で 24 時間ほどかかることがあります。

オペレーションの同時実行

  • 同じソース インスタンスに関連付けられるバックアップ delete オペレーションは、一度に 1 つずつ実行する必要があります。

    同じバックアップ チェーン内での一括バックアップ delete オペレーションはサポートされていません。delete オペレーションが保留となっている間、同じバックアップ チェーン内の新しい delete オペレーションは、RESOURCE_EXHAUSTED エラーで返ります。これは、元のインスタンスが削除されたかどうかに関係なくそうなります。

    • ソース インスタンスが削除されている場合は、同様の FAILED_PRECONDITION エラーが発生します。

    • この制限は、基本 SSD と基本 HDD のすべてのサービスティアに適用されます。

    • Filestore では、バックアップが個別のソース インスタンスを参照するときの、同時バックアップ delete オペレーションをサポートしています。

      たとえば、Source1 というラベルのインスタンスには、Backup1 と Backup2 で参照されるバックアップ データがあり、Source2 には、Backup3 と Backup4 で参照されるバックアップ データがあるとします。Backup1 と Backup2 は並行して削除できませんが、Backup2 と Backup3 は並行して削除できます。

  • 同じバックアップ チェーン内で開始されたバックアップ create とバックアップ delete のオペレーションは同時に実行できます。最新のバックアップが削除されている間は、ユーザーはバックアップ create オペレーションを完了できません。

    • 最新のバックアップを削除している間にインスタンスの新しいバックアップを作成しようとすると、FAILED_PRECONDITION エラーが発生します。たとえば、Source1 に Backup1 と Backup2 で構成されるバックアップ チェーンがあり、ユーザーが Backup3 に対して create オペレーションを開始した場合、create オペレーションが完了するまで Backup2 を削除できません。これは、最新のバックアップに、バックアップ create オペレーションを正常に完了するために必要な最も重要なデータが含まれるためです。

  • オペレーションのレート制限の詳細については、バックアップのオペレーションのレート制限をご覧ください。

ストレージ

  • ソース インスタンスや既存のインスタンスへのバックアップの restore オペレーションは、エンタープライズ階層とゾーン階層のインスタンスに対しては、サポートされていません。これらのサービスティアのいずれかでインスタンスのバックアップを復元する場合は、新しいインスタンスを作成する必要があります。

  • restore、edit、delete などのバックアップ オペレーションは、プレビューで作成された一部のバックアップには使用できない場合があります。

  • エンタープライズ階層のインスタンスに RestoreInstance オペレーションが適用されると、ユーザーはオペレーションの前に以前のスナップショットと同じ名前のスナップショットを作成できなくなります。

  • バックアップの削除中やスナップショットの削除中にバックアップからインスタンスを復元しようとすると失敗します。

  • バックアップの削除に失敗した場合、ステータスは invalid とマークされます。このような場合は、delete オペレーションを再試行する必要があります。

容量

各バックアップはインスタンス容量を占有します。この容量は、前回のバックアップの作成後にデータに加えられた変更の範囲によって異なります。

具体的には、バックアップが作成されると、Filestore はファイル システムの内部スナップショットを作成します。これはスナップショットも利用可能なインスタンス容量の一部を占有します。

また、スナップショット サイズは、最後のバックアップが作成されてから共有内のデータに加えられた変更のスコープにも関係します。このスナップショットは、次のバックアップが作成、アップロードされるまで存在します。

バックアップで参照されるすべてのデータは、キャプチャされた時点の状態のままで保持され、ファイル システムから容量を消費し続けます。たとえば、マウントされたファイル システムからデータを削除しても、そのアクション自体で空き容量が増えることはありません。代わりに、大量のデータを削除または上書きした後に新しいバックアップを作成します。

差分と増分変更の詳細、およびその処理方法については、バックアップの作成をご覧ください。

ワークロードに対する十分な容量を見積もるには、次のいずれかを検討してください。

  • 頻繁に行われるデータ変更や「変更率が高い」ワークロードに対応するインスタンス容量を増やす。

暗号化

CMEK を使用してバックアップ チェーンを暗号化する場合は、次の制限が適用されます。

  • バックアップ チェーン全体が同じ CMEK を使用して暗号化されます。

  • CMEK は、暗号化されたリソースと同じリージョンに存在する必要があります。

  • ソース インスタンスとは別のリージョンにバックアップ チェーンを保存する場合、ソースとバックアップ チェーンに別々の鍵を適用する必要があります。

    • すべてのサービス階層では、複数のバックアップ チェーン、またはインスタンスのバックアップを複数のリージョンに保存できます。CMEK を暗号化に使用する場合、CMEK 鍵は暗号化するリソースと同じリージョンに存在する必要があります。ソースとは別のリージョンにバックアップを保存する場合、CMEK がマルチリージョン キーでない場合は、別の CMEK 鍵を使用する必要があります。詳細については、CMEK の制限と最適な CMEK のロケーションを選択するをご覧ください。

  • 単一の CMEK がバックアップ チェーンが保存される Cloud Storage バケットに適用され、結合や置換はできません。

  • CMEK のサポートは、ベーシック ティアのバックアップでは使用できません。

詳細については、バックアップ チェーンの CMEK のサポートをご覧ください。

おすすめの方法

以下のセクションでは、推奨されるベスト プラクティスについて説明します。

最適なバックアップ整合性を確保するため、ファイル共有を準備する

バックアップの品質は、大量の書き込みワークロード中に作成されたバックアップから復元するアプリケーションの能力によって決まります。ほとんどの場合、アプリケーションがファイル共有にデータを書き込んでいる間でも、優れた整合性を持つバックアップを作成できます。ただし、アプリケーションで厳密な整合性が求められる場合は、次のうち 1 つ以上を行うことをおすすめします。

  • sync マウントを使用する。詳細については、nfs(5) の「同期マウント オプション」をご覧ください。または、O_DIRECT|O_SYNC フラグを使用してファイルを開くこともできます。詳細については、open(2) をご覧ください。
  • ファイル共有にデータを書き込むアプリケーションまたはオペレーティング システム プロセスを一時停止し、バックアップを開始する前にファイル共有に対する変更をフラッシュする。詳細については、fsync(2) をご覧ください。
  • アプリケーションで複数の共有間の整合性が求められる場合は、すべてのアプリケーションに書き込む全インスタンスの全アプリケーションを一時停止し、すべてのファイル共有のバックアップを作成してから、アプリケーションを再開する。
  • アプリケーション レベルの整合性が必要な場合は、バックアップを作成する前に、アプリケーションを停止して、ファイル共有のマウントを解除する。

既存のバックアップを新しいバックアップのベースラインとして使用して、バックアップの作成時間を短縮する

リージョン内のファイル共有の既存のバックアップは、ファイル共有の新しいバックアップを作成するためのベースラインとして使用され、バックアップの作成時間を短縮します。 そこで、次の手順を行うことをおすすめします。

  • ファイル共有の新しいバックアップを作成してから、そのファイル共有の以前のバックアップを削除します。

  • 新しいバックアップが Ready 状態になるまで待ってから、同じファイル共有の後続のバックアップを作成します。

バックアップの作成時間を短縮するために、オフピーク時にバックアップのスケジュールを設定する

オフピーク時にバックアップを作成すると、バックアップの作成に要する時間が短縮されます。ファイル共有の定期的なバックアップのスケジュールを設定する場合は、可能な限りオフピーク時にスケジュール設定することをおすすめします。

バックアップ作成のピーク時間帯は、各営業日の終了時と、Filestore インスタンスが配置されているリージョンの午前 0 時です。早朝または営業時間中にバックアップを作成することをおすすめします。

効率を最大限高めるために、個別の Filestore インスタンスでデータを整理する

ファイル共有のデータが多いほど、バックアップのサイズが大きくなり、コストも増大します。バックアップが必要なデータのみをバックアップするには、次のように、データを別々のファイル共有に整理することをおすすめします。

  • 書き込みパターンごと、またはバックアップ要件ごとに、異なるファイル共有に重要データを保存する。
  • 1 つのファイル共有に類似のデータを保存することで、作成する必要のあるバックアップの数を減らす。

割り当て

基本 SSD サービス階層および基本 HDD サービス階層では、リージョンあたりのバックアップ数に対して割り当ての上限が存在します。

バックアップの割り当て上限は、ゾーンとエンタープライズのサービス階層には適用されません。

詳細については、サービス階層と割り当てをご覧ください。

Filestore バックアップの使用を開始する

当該機能の使用を開始するには、障害復旧用のデータのバックアップをご覧ください。

次のステップ