このページでは、バックアップの概要、仕組み、一般的なユースケース、バックアップを作成して使用する際のベスト プラクティスについて説明します。バックアップの作成と管理を行う方法とバックアップから Filestore インスタンスを復元する方法については、障害復旧のためのデータのバックアップをご覧ください。
バックアップとは
Filestore バックアップは、バックアップ作成時点からのファイル共有のすべてのファイルデータとメタデータを含むファイル共有のコピーです。
ファイル共有のバックアップを作成した後、バックアップに影響を与えることなく元のファイル共有を変更または削除できます。
バックアップを使用して、ファイル共有を新しい Filestore インスタンスに復元できます。また、ベーシック ティア インスタンスの場合は、ソースまたは既存のファイル共有に復元できます。
バックアップは、作成時に指定したリージョン内に残るリージョン リソースです。データ損失のリスクを軽減するために、Filestore インスタンスと同じリージョンまたは別のリージョンにバックアップを作成できます。
バックアップはグローバル アドレスに対応しており、任意の リージョンにファイル共有を復元するために使用できますが、プロジェクト間で共有することはできません。
ネットワーク転送料金は、リージョン間のネットワーク トラフィックに適用されます。詳細については、料金ページをご覧ください。
バックアップの作成
最初に作成するバックアップは、ファイル共有上のすべてのファイルデータとメタデータの完全なコピーです。以降の各バックアップでは、前回のバックアップ以降にデータに加えられた増分変更がすべてコピーされます。
同じインスタンス、リージョン、CMEK（使用されている場合）に関連付けられているバックアップのグループは、バックアップ チェーンと呼ばれます。
バックアップ チェーンは単一の Cloud Storage バケットとリージョンに存在し、ソース インスタンスの保存に使用されるリージョンの外部に配置できます。
すべてのサービスティアでは複数のバックアップ チェーンがサポートされるため、インスタンスのバックアップを複数のリージョンに保存できます。
バックアップが作成されるたびに、以前のバックアップがスキャンされ、差分変更と増分変更の両方が検出されます。
差分変更: 共有上のファイルに加えられた変更（ファイルの編集、追加、削除など）が含まれます。
増分変更: バックアップ データが配置されているバケット内のストレージの変更が含まれます。これには、チェーン内で以前に参照されたデータの重複除去が含まれる場合があります。
同じバックアップ チェーンにバックアップを保存するたびに、前回のバックアップがスキャンされ、差分と増分変更が検出されます。このような場合、完全なコピーは必要ありません。
ただし、インスタンスのデータを複数のバックアップ チェーンに保存すると、バックアップを交互に保存することになります。
交互のロケーションに新しいバックアップを作成するたびに、バックアップの完全なコピーが再度生成されます。バックアップ チェーン間を交互に切り替えると、バックアップ create オペレーションのレイテンシ増加が予想されます。
以前のバックアップに含まれる未変更データは、新しいバックアップで参照されますが、コピーされません。古いバックアップが削除されると、その特異データが次の最新バックアップにコピーされ、すべての内部データ参照が自動的に更新されます。
内部的には、バックアップ チェーンの履歴はスナップショットを使用して追跡されます。スナップショットはソース インスタンスの容量を使用します。
バックアップの作成は瞬時に行われますが、バックアップが使用可能になる前にコピーされるデータ量に比例する時間を要します。この間に、バックアップは次の 3 つの状態を遷移します。
| 州 | 所要時間 | 説明 |
|---|---|---|
| 作成 | 数秒 | ファイル共有の現在の状態をキャプチャする。ファイル共有データの新しい変更は、バックアップに含まれる場合と含まれない場合があります。バックアップが開始される前にインスタンスによって承認された安定した書き込みは追加されます。 |
| 最終処理中 | サイズに依存 | バックアップにデータをアップロードする。ファイル共有データの新しい変更は、バックアップに追加されません。 |
| Ready | バックアップが削除されるまで | バックアップを使用する準備が完了しています。 |
作成後、ベーシック ティアのバックアップは自動的に圧縮され、コストが削減されます。 ゾーン、リージョン、エンタープライズのサービス階層でインスタンスのバックアップを作成している間、インスタンスのパフォーマンスが低下する場合があります。バックアップを作成しても、ベーシック ティア インスタンスの可用性やパフォーマンスには影響しません。
冗長データへの対応
デフォルトでは冗長データに対する料金が発生しないようにし、保存容量の使用を最小限に抑えるために、バックアップは増分バックアップとしています。基盤となる変更履歴の信頼性を確保するために、バックアップでインスタンスの完全なコピーが取得されることがあります。
詳細については、スナップショットとバックアップの比較をご覧ください。
バックアップの削除
バックアップはプロジェクト レベルのリソースであり、ソース インスタンスのサブリソースではないため、独自のストレージが必要です。そのため、バックアップのライフサイクルはソース インスタンスのライフサイクルには関連付けられません。ソースを削除しても、関連付けられているバックアップは削除されません。バックアップを削除する場合は、インスタンスではなくバックアップで削除オペレーションを明示的に実行する必要があります。
不要なバックアップは必ず削除してください。ソース インスタンスが削除されても、残りのバックアップに対しては引き続き料金が発生します。
バックアップを削除すると、元に戻すことはできません。
バックアップの整合性
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 インスタンスを作成する場合、ソース インスタンスの階層に関係なく、ベーシック 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オペレーションはサポートされていません。これらのサービスティアのインスタンスのバックアップを復元する場合は、新しいインスタンスを作成する必要があります。新しいインスタンスは、ソース インスタンスのサービスティアと容量範囲と一致している必要があります。たとえば、ソースが低容量範囲のゾーンサービス階層を使用して作成された場合、新しいインスタンスは同じサービス階層と容量範囲を使用する必要があります。
以前の高スケール SSD サービス階層を使用してインスタンスを作成する必要がある場合は、Filestore API を使用してオペレーションを直接実行する必要があります。
レガシー エンタープライズ サービス階層を使用してインスタンスを作成する必要がある場合は、Filestore API を使用するか、[バックアップの復元] > [新しいインスタンス] からオペレーションを直接実行できます。
たとえば、10 TiB のインスタンス容量を持つリージョン リソースを作成する場合は、従来のエンタープライズ サービス階層を使用する必要があります。
restore、edit、deleteなどのバックアップ オペレーションは、プレビューで作成された一部のバックアップには使用できない場合があります。リージョンまたはエンタープライズ階層のインスタンスに RestoreInstance オペレーションが適用されると、ユーザーはオペレーションの前に以前のスナップショットと同じ名前のスナップショットを作成できなくなります。
バックアップの削除中やスナップショットの削除中にバックアップからインスタンスを復元しようとすると失敗します。
バックアップの削除が失敗した場合、ステータスは
invalidとマークされます。このような場合は、deleteオペレーションを再試行する必要があります。
容量
各バックアップはインスタンス容量を占有します。この容量は、最後のバックアップの作成以降にデータに加えられた変更のスコープによって異なります。
具体的には、バックアップの作成時に、Filestore はファイル システムの内部スナップショットを作成します。このスナップショットは、使用可能なインスタンス容量の一部も占有します。
また、スナップショット サイズは、最後のバックアップが作成されてから共有内のデータに加えられた変更のスコープにも関係します。このスナップショットは、次のバックアップが作成されてアップロードされるまで存在し続けます。
バックアップで参照されるすべてのデータは、キャプチャされた時点の状態のままで保持され、ファイル システムから容量を消費し続けます。たとえば、マウントされたファイル システムからデータを削除しても、そのアクション自体で空き容量が増えることはありません。代わりに、大量のデータを削除または上書きした後に新しいバックアップを作成します。
差分と増分変更の詳細、およびその処理方法については、バックアップの作成をご覧ください。
ワークロードに対する十分な容量を見積もるには、次のいずれかを検討してください。
- 頻繁に行われるデータ変更や「変更率が高い」ワークロードに対応するインスタンス容量を増やす。
暗号化
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 のリージョンとゾーンについて学習する。
- バックアップの料金について学習する。