スナップショットリポジトリの登録

このガイドでは、スナップショットリポジトリの登録方法を示します。スナップショットリポジトリは、スナップショットのためのクラスタ外のストレージ場所です。スナップショットを取得または復元する前に、リポジトリを登録する必要があります。

このガイドでは、次のことを学びます:

  • スナップショットリポジトリを登録する
  • リポジトリが機能していることを確認する
  • 不要なファイルを削除するためにリポジトリをクリーンアップする

前提条件

  • Kibanaのスナップショットと復元機能を使用するには、次の権限が必要です:
  • スナップショットリポジトリを登録するには、クラスタのグローバルメタデータが書き込み可能である必要があります。書き込みアクセスを妨げるクラスタブロックがないことを確認してください。

考慮事項

スナップショットリポジトリを登録する際には、次の点に留意してください:

  • 各スナップショットリポジトリは別々で独立しています。Elasticsearchはリポジトリ間でデータを共有しません。
  • クラスタは特定のスナップショットリポジトリバケットを一度だけ登録する必要があります。同じスナップショットリポジトリを複数のクラスタで登録する場合、1つのクラスタのみがリポジトリへの書き込みアクセスを持つべきです。他のクラスタでは、リポジトリを読み取り専用として登録します。
    これにより、複数のクラスタが同時にリポジトリに書き込むことを防ぎ、リポジトリの内容が破損するのを防ぎます。また、Elasticsearchがリポジトリの内容をキャッシュするのを防ぎ、他のクラスタによって行われた変更がすぐに可視化されることを意味します。
  • Elasticsearchを新しいバージョンにアップグレードする際、アップグレード前に使用していた同じリポジトリを引き続き使用できます。リポジトリが複数のクラスタによってアクセスされる場合、すべてのクラスタが同じバージョンである必要があります。特定のバージョンのElasticsearchによってリポジトリが変更された場合、古いバージョンでアクセスすると正しく動作しない可能性があります。ただし、アップグレード前に取得したスナップショットを、アップグレード前のバージョンを実行しているクラスタに復元することで、失敗したアップグレードから回復することができます。たとえアップグレード中または後にさらにスナップショットを取得していてもです。

スナップショットリポジトリの管理

スナップショットリポジトリを登録および管理する方法は2つあります:

Kibanaでリポジトリを管理するには、メインメニューに移動し、スタック
管理
スナップショットと復元
リポジトリをクリックします。スナップショットリポジトリを登録するには、リポジトリを登録をクリックします。

スナップショットリポジトリ作成APIを使用してリポジトリを登録することもできます。

スナップショットリポジトリの種類

サポートされているスナップショットリポジトリの種類は、デプロイメントの種類に基づいて異なります:

Elasticsearchサービスリポジトリの種類

Elasticsearchサービスデプロイメントは、found-snapshotsリポジトリを自動的に登録します。Elasticsearchサービスはこのリポジトリとcloud-snapshot-policyを使用して、クラスタの定期的なスナップショットを取得します。また、found-snapshotsリポジトリを使用して独自のSLMポリシーを作成したり、検索可能なスナップショットを保存したりすることもできます。 

  2. Elasticsearchサービスデプロイメントは、次のリポジトリの種類もサポートしています:  
  4. -  [Azure](https://www.elastic.co/guide/en/cloud/current/ec-azure-snapshotting.html)  
  5. -  [Google Cloud Storage](https://www.elastic.co/guide/en/cloud/current/ec-gcs-snapshotting.html)  
  6. -  [AWS S3](https://www.elastic.co/guide/en/cloud/current/ec-aws-custom-repository.html)  
  7. -  [ソース専用](/read/elasticsearch-8-15/d2f6a2fb91f56c62.md)
  10. ### 自己管理リポジトリの種類
  12. 独自のElasticsearchクラスタを管理している場合、次の組み込みスナップショットリポジトリの種類を使用できます:  
  14. -  [Azure](/read/elasticsearch-8-15/d888d8b822a8a1ce.md)  
  15. -  [Google Cloud Storage](/read/elasticsearch-8-15/dfd43ab9354680ac.md)  
  16. -  [AWS S3](/read/elasticsearch-8-15/094325de711979fa.md)  
  17. -  [共有ファイルシステム](/read/elasticsearch-8-15/42b9d9b87a4241d0.md)  
  18. -  [読み取り専用URL](/read/elasticsearch-8-15/e140b4739f315eab.md)  
  19. -  [ソース専用](/read/elasticsearch-8-15/d2f6a2fb91f56c62.md)
  21. [](#snapshots-repository-plugins)他のリポジトリの種類は公式プラグインを通じて利用可能です:  
  23. -  [Hadoop分散ファイルシステム(HDFS)](https://www.elastic.co/guide/en/elasticsearch/plugins/8.15/repository-hdfs.html)
  25. これらのリポジトリの種類とともに、代替ストレージ実装を使用することもできますが、代替実装が完全に互換性がある必要があります。たとえば、[MinIO](https://minio.io)はAWS S3 APIの代替実装を提供し、`````s3`````リポジトリタイプとともにMinIOを使用できます。  
  27. 一部のストレージシステムは、これらのリポジトリの種類と互換性があると主張していますが、その動作を完全にエミュレートしていない場合があります。Elasticsearchは完全な互換性を要求します。特に、代替実装は同じAPIエンドポイントのセットをサポートし、失敗時に同じエラーを返し、複数のノードによって同時にアクセスされても同等の一貫性保証とパフォーマンスを提供する必要があります。互換性のないエラーコード、一貫性またはパフォーマンスは、エラー、一貫性の失敗、パフォーマンスの問題が通常はまれで再現が難しいため、特に追跡が難しい場合があります。  
  29. [リポジトリ分析](/read/elasticsearch-8-15/8c7630461481c6c0.md) APIを使用して、ストレージシステムの適合性を基本的にチェックできます。このAPIが正常に完了しない場合、またはパフォーマンスが悪いことを示す場合、ストレージシステムは完全に互換性がないため、スナップショットリポジトリとしての使用には適していません。互換性の問題を解決するために、ストレージシステムのサプライヤーと協力する必要があります。
  32. ## リポジトリの確認
  34. スナップショットリポジトリを登録すると、Elasticsearchは自動的にリポジトリがすべてのマスターノードおよびデータノードで利用可能で機能していることを確認します。  
  36. この確認を無効にするには、[スナップショットリポジトリ作成API](/read/elasticsearch-8-15/dc3b4a817e87b963.md)の`````verify`````クエリパラメータを`````false`````に設定します。Kibanaではリポジトリの確認を無効にすることはできません。
  39. #### Python
  41. ``````python
  42. resp = client.snapshot.create_repository(
  43.    name="my_unverified_backup",
  44.    verify=False,
  45.    repository={
  46.    "type": "fs",
  47.    "settings": {
  48.    "location": "my_unverified_backup_location"
  49.    }
  50.    },
  51. )
  52. print(resp)
  53. `

Ruby

  1. response = client.snapshot.create_repository(
  2.   repository: 'my_unverified_backup',
  3.   verify: false,
  4.   body: {
  5.    type: 'fs',
  6.    settings: {
  7.    location: 'my_unverified_backup_location'
  8.    }
  9.   }
  10. )
  11. puts response

Js

  1. const response = await client.snapshot.createRepository({
  2.   name: "my_unverified_backup",
  3.   verify: "false",
  4.   repository: {
  5.    type: "fs",
  6.    settings: {
  7.    location: "my_unverified_backup_location",
  8.    },
  9.   },
  10. });
  11. console.log(response);

コンソール

  1. PUT _snapshot/my_unverified_backup?verify=false
  2. {
  3.   "type": "fs",
  4.   "settings": {
  5.    "location": "my_unverified_backup_location"
  6.   }
  7. }

必要に応じて、リポジトリ確認チェックを手動で実行できます。Kibanaでリポジトリを確認するには、リポジトリリストページに移動し、リポジトリの名前をクリックします。次に、リポジトリを確認をクリックします。また、スナップショットリポジトリ確認APIを使用することもできます。

Python

  1. resp = client.snapshot.verify_repository(
  2.    name="my_unverified_backup",
  3. )
  4. print(resp)

Ruby

  1. response = client.snapshot.verify_repository(
  2.   repository: 'my_unverified_backup'
  3. )
  4. puts response

Js

  1. const response = await client.snapshot.verifyRepository({
  2.   name: "my_unverified_backup",
  3. });
  4. console.log(response);

コンソール

  1. POST _snapshot/my_unverified_backup/_verify

成功した場合、リクエストはリポジトリを確認するために使用されたノードのリストを返します。確認に失敗した場合、リクエストはエラーを返します。

リポジトリ分析APIを使用して、リポジトリをより徹底的にテストできます。

リポジトリのクリーンアップ

リポジトリは、時間の経過とともに、既存のスナップショットによって参照されていないデータを蓄積することがあります。これは、スナップショット機能がスナップショット作成中の障害シナリオにおいて提供するデータ安全性保証と、スナップショット作成プロセスの分散型の性質によるものです。この参照されていないデータは、スナップショットリポジトリのパフォーマンスや安全性に悪影響を与えることはありませんが、必要以上のストレージ使用を引き起こします。この参照されていないデータを削除するには、リポジトリに対してクリーンアップ操作を実行できます。これにより、リポジトリの内容の完全な会計がトリガーされ、参照されていないデータが削除されます。

Kibanaでリポジトリのクリーンアップ操作を実行するには、リポジトリリストページに移動し、リポジトリの名前をクリックします。次に、リポジトリをクリーンアップをクリックします。

スナップショットリポジトリクリーンアップAPIを使用することもできます。

Python

  1. resp = client.snapshot.cleanup_repository(
  2.    name="my_repository",
  3. )
  4. print(resp)

Ruby

  1. response = client.snapshot.cleanup_repository(
  2.   repository: 'my_repository'
  3. )
  4. puts response

Js

  1. const response = await client.snapshot.cleanupRepository({
  2.   name: "my_repository",
  3. });
  4. console.log(response);

コンソール

  1. POST _snapshot/my_repository/_cleanup

APIは次のように返します:

コンソール-結果

  1. {
  2.   "results": {
  3.    "deleted_bytes": 20,
  4.    "deleted_blobs": 5
  5.   }
  6. }

具体的なリポジトリ実装に応じて、表示される空きバイト数や削除されたブロブの数は、近似値または正確な結果のいずれかになります。削除されたブロブの数がゼロ以外の値である場合、参照されていないブロブが見つかり、その後クリーンアップされたことを示します。

このエンドポイントによって実行されるクリーンアップ操作のほとんどは、リポジトリからスナップショットを削除する際に自動的に実行されます。スナップショットを定期的に削除する場合、ほとんどの場合、この機能を使用してもほとんどまたはわずかなスペースの節約は得られず、それに応じて呼び出しの頻度を下げるべきです。

リポジトリのバックアップ

リポジトリの独立したバックアップを作成したい場合があります。たとえば、後でリポジトリを現在の状態で再作成するために使用できるその内容のアーカイブコピーを持つためです。

バックアップを取得している間、Elasticsearchがリポジトリに書き込まないようにする必要があります。これを行うには、すべてのクラスタでリポジトリを登録解除するか、readonly: trueで登録します。バックアップ中にElasticsearchがリポジトリにデータを書き込むと、バックアップの内容が一貫性がない可能性があり、将来的にデータを回復できない可能性があります。

また、リポジトリがサポートしている場合、基盤となるファイルシステムの原子的なスナップショットを取得し、そのファイルシステムスナップショットのバックアップを取得することもできます。ファイルシステムスナップショットは原子的に取得されることが非常に重要です。

このセクションで説明した方法以外で取得されたリポジトリのバックアップに依存しないでください。リポジトリの内容のコピーを作成するために別の方法を使用すると、結果として得られるコピーがデータの一貫性のないビューをキャプチャする可能性があります。そのようなコピーからリポジトリを復元すると、エラーが報告されるか、成功してもデータの一部が失われる可能性があります。

個々のノードのファイルシステムスナップショットをバックアップメカニズムとして使用しないでください。クラスタの内容を別のリポジトリにコピーするために、Elasticsearchのスナップショットと復元機能を使用する必要があります。その後、必要に応じて、このリポジトリのファイルシステムスナップショットを取得できます。

バックアップからリポジトリを復元する際は、リポジトリの内容が完全に復元されるまで、Elasticsearchにリポジトリを登録してはいけません。リポジトリがElasticsearchに登録されている間にその内容を変更すると、リポジトリが読み取れなくなったり、内容の一部が静かに失われたりする可能性があります。