Elastic Certified Engineer Exam対策 – Snapshot, Restore & SLM

このブログの目的
Snapshot, Restore & SLM 概要
Snapshot Repository
Snapshot
Restore
Searchable Snapshot <Enterpriseライセンス専用>
Snapshot Lifecycle Management (SLM)
実践問題
Elastic社が提供する無料Hands-on Trainingで理解を深めよう
試験対策ポイント

このブログの目的

Elastic Certified Engineer Examでは、SnapshotによるバックアップとRestoreによる復元、さらにSearchable SnapshotやSnapshot Lifecycle Management（SLM）に関する基本操作を理解していることが求められます。本記事では、これらの機能について、Repositoryの作成からSnapshotの取得・Restore・SLMによる自動化までを、実際にAPIを実行しながら学習します。

当記事が対象とする試験の範囲は以下となります。

Cluster Management – Backup and restore a cluster and/or specific indices
Cluster Management – Configure a snapshot to be searchable
Cluster Management – Automate snapshots with Snapshot Lifecycle Management

試験情報は以下サイトで確認可能です。
https://www.elastic.co/training/elastic-certified-engineer-exam

Snapshot, Restore & SLM 概要

Snapshot 概要

Snapshotは、ElasticsearchのIndexやData Streamのデータをバックアップするための機能です。障害発生時の復旧だけでなく、別環境へのデータ移行や検証環境の作成など、さまざまな場面で利用されます。

Snapshotはローカルディスクへ直接保存するのではなく、あらかじめ登録したSnapshot Repositoryへ保存します。RepositoryにはShared File SystemやAmazon S3などを利用でき、1つのRepositoryに複数のSnapshotを保存できます。

取得したSnapshotは必要に応じてRestoreを実行してデータを復元できます。また、Searchable Snapshotを利用すると、Snapshotを復元することなく検索対象として利用することも可能です。さらに、Snapshot Lifecycle Management（SLM）を利用すれば、Snapshotの取得や古いSnapshotの削除を自動化できます。

Restore 概要

Restoreは、SnapshotからIndexやData Streamを復元する機能です。誤ってデータを削除した場合や障害発生時の復旧だけでなく、別環境へデータを移行する場合にも利用されます。

Restoreでは、Snapshotに含まれるすべてのデータを復元するだけでなく、特定のIndexのみを選択して復元することも可能です。また、復元時にはIndex名の変更など、一部の設定を変更しながらRestoreを実行できます。

Snapshot Lifecycle Management (SLM) 概要

Snapshot Lifecycle Management（SLM）は、Snapshotの取得や保持を自動化する機能です。あらかじめPolicyを作成しておくことで、指定したスケジュールに従ってSnapshotを定期的に取得し、保持期間を過ぎた古いSnapshotを自動的に削除できます。

手動でSnapshotを管理する場合に比べ、取得漏れや不要なSnapshotの蓄積を防げるため、バックアップ運用の負荷を軽減できます。また、定期的なSnapshot取得を自動化することで、障害発生時にも比較的新しいデータから復旧しやすくなります。

試験では、SLMの基本的な役割やPolicyの作成方法、Snapshotの自動取得とRetention（保持期間）による自動削除の仕組みを理解しておくことが重要です。

Snapshot Repository

Snapshot Repositoryとは

Snapshot Repositoryは、Snapshotを保存するための保存先です。Snapshotを取得する前に、あらかじめRepositoryをElasticsearchへ登録しておく必要があります。

Repositoryには、Shared File SystemやAmazon S3、Azure Blob Storage、Google Cloud Storageなどを利用できます。取得したSnapshotはRepository内に保存され、1つのRepositoryに複数のSnapshotを保持できます。

Snapshotの取得やRestore、Searchable Snapshot、SLMは、いずれもRepositoryを利用して動作します。そのため、Snapshot関連機能を利用するための最初の設定がRepositoryの作成です。

Snapshot Repositoryの作成

Snapshotを取得するには、事前にSnapshot Repositoryを作成しておく必要があります。Self-managed環境でShared File Systemを利用する場合は、Elasticsearchの設定ファイルにpath.repoを定義し、Snapshotの保存先ディレクトリを指定します。path.repoを変更した場合は、Elasticsearchの再起動が必要です。

path.repoの設定後、Repositoryを登録します。以下の例では、my_repositoryという名前のRepositoryを作成し、/var/tmp/snapshotsを保存先として登録しています。

PUT _snapshot/my_repository
{
  "type": "fs",
  "settings": {
    "location": "/var/tmp/snapshots"
  }
}

正常に作成されると、次のようなレスポンスが返されます。

typeにはRepositoryの種類を指定します。Shared File Systemを利用する場合はfsを指定し、locationにはpath.repoで許可したディレクトリを指定します。

Self-managed環境におけるtypeに指定できる値は、以下の通りです。当資料では ”fs” を使用します。

type	説明
azure	Azure Blob StorageへSnapshotを保存します。
gcs	Google Cloud StorageへSnapshotを保存します。
s3	Amazon S3へSnapshotを保存します。
fs	Shared File System（NFSなどの共有ファイルシステム）にSnapshotを保存します。
url	読み取り専用（Read-only）のRepositoryです。既存のRepositoryを参照してRestoreを行う場合などに利用します(※)。
source	Source-only Repositoryです。Indexのソースデータのみを保存し、ストレージ容量を削減できます。検索には利用できず、Restore後に再インデックスが必要となる用途向けです。

※ type : url
既存のSnapshotを読み取り専用（Read-only）で利用するためのRepositoryです。新しいSnapshotは作成できず、既に存在するSnapshotからRestoreを実行する用途で利用します。例えば、本番環境で取得したSnapshotをHTTPサーバーや共有ファイルシステムで公開し、検証環境ではurl Repositoryとして登録することで、誤ってSnapshotを更新・削除することなく、安全にRestoreできます。file、http、https、ftpなどのURLを利用できます。

Elastic Docs > Deploy and manage > Backup, high availability, and resilience tools > Snapshot and restore > Manage snapshot repositories
https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore/manage-snapshot-repositories

Elastic API Docs > Snapshot and restore > Create or update a snapshot repository
https://www.elastic.co/docs/api/doc/elasticsearch/v8/operation/operation-snapshot-create-repository

Snapshot Repositoryの確認

Repositoryを作成したら、正しく登録されていることを確認します。Repositoryの確認には、Snapshot Get Repository APIを使用します。

GET _snapshot

特定のRepositoryのみを確認する場合は、Repository名を指定します。

GET _snapshot/my_repository

また、Kibanaでは [ Stack Management > Snapshot and Restore > Repositories ] から登録済みRepositoryを確認できます。GUIからRepository名や種類を一覧で確認できるため、設定内容を手軽に確認したい場合に便利です。

Snapshot Repositoryの削除

不要になったSnapshot Repositoryは、Delete Repository APIを使用して削除できます。

DELETE _snapshot/my_repository

正常に削除されると、次のようなレスポンスが返されます。

Snapshot

Snapshotの取得

Snapshot Repositoryを作成したら、Snapshot Create APIを使用してSnapshotを取得します。SnapshotはCluster全体だけでなく、必要なIndexやData Streamを指定して取得することもできます。試験では、特定のIndexを対象にSnapshotを取得する基本的な操作を理解しておくことが重要です。

以下の例では、my_repositoryにsnapshot_01という名前のSnapshotを作成し、blogs Indexをバックアップしています。

PUT _snapshot/my_repository/snapshot_01
{
  "indices": "blogs"
}

正常にリクエストが受け付けられると、次のようなレスポンスが返されます。

ここで注意したいのは、Snapshot Create APIはデフォルトで非同期に実行される点です。そのため、accepted: trueはSnapshotの取得要求が受け付けられたことを示しているだけであり、この時点ではSnapshotの作成は完了していません。Snapshotが正常に作成されたかどうかは、次節で説明するSnapshot Get APIで確認します。

Snapshot取得時には、indices以外にもさまざまなオプションを指定できます。試験で押さえておきたい主なオプションは次のとおりです。

オプション	説明
indices	Snapshotの対象となるIndexまたはData Streamを指定します。省略した場合はすべてが対象となります。
include_global_state	Cluster StateやFeature StateをSnapshotへ含めるかどうかを指定します。デフォルトは`true`です。
wait_for_completion	`true`を指定するとSnapshotの作成完了まで待機してからレスポンスを返します。デフォルトは`false`です。

特にinclude_global_stateは重要なオプションです。デフォルトではtrueとなっているため、indicesにblogsのみを指定した場合でも、KibanaやSecurityなどのFeature StateがSnapshotへ含まれます。その結果、Snapshotの内容を確認すると.kibana_*や.security-*などのシステムIndexも表示されます。これは正常な動作です。

一方、アプリケーションのIndexのみをSnapshotしたい場合は、include_global_stateをfalseに指定します。

PUT _snapshot/my_repository/snapshot_02
{
  "indices": "blogs",
  "include_global_state": false
}

GET _snapshot/my_repository/snapshot_02

include_global_stateにfalseを設定している為、indicesにはblogsしか含まれていません。

また、Snapshotの作成完了まで待機したい場合は、wait_for_completion=trueを指定します。

PUT _snapshot/my_repository/snapshot_03?wait_for_completion=true
{
  "indices": "blogs"
}

この場合は、Snapshotの作成が完了してからレスポンスが返されるため、上図の通り、すぐに実行結果を確認できます。ただし、Snapshotの取得に時間がかかる場合は、その分APIの応答時間も長くなります。

Snapshotの確認

前節では、Snapshot Create APIを使用してSnapshotを取得する方法を説明しました。本節では、作成したSnapshotの内容や状態を確認する方法を学習します。Snapshotの確認には、Snapshot Get APIを使用します。

Repository内のすべてのSnapshotを確認する場合は、次のコマンドを実行します。

GET _snapshot/my_repository/_all

以下、レスポンス内容。前節で作成した「snapshot_01」「snapshot_02」「snapshot_03」の情報が取得されています。

{
  "snapshots": [
    {
      "snapshot": "snapshot_01",
      "uuid": "u-q9GAKhTt-ijirDk3dtpg",
      "repository": "my_repository",
      "version_id": 8512000,
      "version": "8.15.0-8.15.5",
      "indices": [
        ".apm-custom-link",
        ".kibana_ingest_8.15.5_001",
        ".security-7",
        ".kibana_8.15.5_001",
        ".kibana_alerting_cases_8.15.5_001",
        ".security-profile-8",
        ".kibana_analytics_8.15.5_001",
        ".kibana_task_manager_8.15.5_001",
        ".kibana_security_solution_8.15.5_001",
        ".apm-agent-configuration",
        ".kibana_security_session_1",
        "blogs"
      ],
      "data_streams": [],
      "include_global_state": true,
      "state": "SUCCESS",
      "start_time": "2026-07-16T06:56:37.918Z",
      "start_time_in_millis": 1784184997918,
      "end_time": "2026-07-16T06:56:38.319Z",
      "end_time_in_millis": 1784184998319,
      "duration_in_millis": 401,
      "failures": [],
      "shards": {
        "total": 12,
        "failed": 0,
        "successful": 12
      },
      "feature_states": [
        {
          "feature_name": "kibana",
          "indices": [
            ".kibana_security_solution_8.15.5_001",
            ".apm-custom-link",
            ".kibana_8.15.5_001",
            ".apm-agent-configuration",
            ".kibana_task_manager_8.15.5_001",
            ".kibana_security_session_1",
            ".kibana_alerting_cases_8.15.5_001",
            ".kibana_ingest_8.15.5_001",
            ".kibana_analytics_8.15.5_001"
          ]
        },
        {
          "feature_name": "security",
          "indices": [
            ".security-7",
            ".security-profile-8"
          ]
        }
      ]
    },
    {
      "snapshot": "snapshot_02",
      "uuid": "uq3n8oFORQWAn5BBJOrIhA",
      "repository": "my_repository",
      "version_id": 8512000,
      "version": "8.15.0-8.15.5",
      "indices": [
        "blogs"
      ],
      "data_streams": [],
      "include_global_state": false,
      "state": "SUCCESS",
      "start_time": "2026-07-16T06:58:58.623Z",
      "start_time_in_millis": 1784185138623,
      "end_time": "2026-07-16T06:58:58.823Z",
      "end_time_in_millis": 1784185138823,
      "duration_in_millis": 200,
      "failures": [],
      "shards": {
        "total": 1,
        "failed": 0,
        "successful": 1
      },
      "feature_states": []
    },
    {
      "snapshot": "snapshot_03",
      "uuid": "qbPyLlGORP-SS-7SVxDr8g",
      "repository": "my_repository",
      "version_id": 8512000,
      "version": "8.15.0-8.15.5",
      "indices": [
        ".apm-custom-link",
        ".kibana_ingest_8.15.5_001",
        ".security-7",
        ".kibana_8.15.5_001",
        ".kibana_alerting_cases_8.15.5_001",
        ".security-profile-8",
        ".kibana_analytics_8.15.5_001",
        ".kibana_task_manager_8.15.5_001",
        ".kibana_security_solution_8.15.5_001",
        ".apm-agent-configuration",
        ".kibana_security_session_1",
        "blogs"
      ],
      "data_streams": [],
      "include_global_state": true,
      "state": "SUCCESS",
      "start_time": "2026-07-16T06:59:27.844Z",
      "start_time_in_millis": 1784185167844,
      "end_time": "2026-07-16T06:59:28.045Z",
      "end_time_in_millis": 1784185168045,
      "duration_in_millis": 201,
      "failures": [],
      "shards": {
        "total": 12,
        "failed": 0,
        "successful": 12
      },
      "feature_states": [
        {
          "feature_name": "kibana",
          "indices": [
            ".kibana_security_solution_8.15.5_001",
            ".apm-custom-link",
            ".kibana_8.15.5_001",
            ".apm-agent-configuration",
            ".kibana_task_manager_8.15.5_001",
            ".kibana_security_session_1",
            ".kibana_alerting_cases_8.15.5_001",
            ".kibana_ingest_8.15.5_001",
            ".kibana_analytics_8.15.5_001"
          ]
        },
        {
          "feature_name": "security",
          "indices": [
            ".security-7",
            ".security-profile-8"
          ]
        }
      ]
    }
  ],
  "total": 3,
  "remaining": 0
}

レスポンスには、Repository内に保存されているすべてのSnapshotが表示されます。特定のSnapshotだけを確認したい場合は、前節で紹介したようにSnapshot名を指定します。

GET _snapshot/my_repository/snapshot_02

Snapshot Get APIでは、Snapshot名だけでなく、取得対象のIndexやSnapshotの状態、取得開始・終了時刻などを確認できます。

項目	説明
snapshot	Snapshot名
repository	保存先Repository名
indices	Snapshotに含まれるIndex
state	Snapshotの状態（SUCCESS、FAILED、IN_PROGRESSなど）
include_global_state	Cluster Stateを含めて取得したかどうか
start_time	Snapshot取得開始時刻
end_time	Snapshot取得終了時刻
duration_in_millis	Snapshot取得に要した時間
failures	Snapshot取得時に発生したエラー
shards	Snapshot対象Shard数と成功・失敗数

stateがSUCCESSであればSnapshotは正常に作成されています。一方、取得中はIN_PROGRESS、エラーが発生した場合はFAILEDとなるため、Restoreを実行する前に状態を確認しておくことが重要です。

また、前節で説明したように、include_global_stateの値によってindicesに表示される内容が変わります。例えば、include_global_stateをfalseにしてSnapshotを取得した場合は、indicesには指定したblogsのみが表示されます。一方、デフォルトのtrueで取得した場合は、KibanaやSecurityなどのFeature Stateも含まれるため、.kibana_*や.security-*などのシステムIndexもindicesに表示されます。これは正常な動作です。

Kibanaでは、
Stack Management > Snapshot and Restore > Snapshots
からSnapshotを一覧表示できます。GUIではSnapshot名、Repository、取得日時、状態などを確認できるため、Snapshotが正常に作成されているかを視覚的に確認したい場合に便利です。

Snapshotの削除

不要になったSnapshotは、Snapshot Delete APIを使用して削除できます。Snapshotを削除してもRepository自体は削除されず、同じRepositoryを使用して新たなSnapshotを取得したり、他のSnapshotからRestoreを実行したりできます。試験では、SnapshotとSnapshot Repositoryは別のリソースであり、それぞれ削除方法が異なることを理解しておくことが重要です。

以下の例では、my_repositoryに保存されているsnapshot_01を削除します。

DELETE _snapshot/my_repository/snapshot_01

正常に削除されると、次のようなレスポンスが返されます。

削除後は、Snapshot Get APIでRepository内のSnapshotを確認すると、削除したSnapshotが一覧から表示されなくなっていることを確認できます。

GET _snapshot/my_repository/_all

削除対象が存在しない場合は、エラーが返されます。そのため、削除前にSnapshot Get APIで対象のSnapshot名を確認しておくと安全です。

Restore

Restoreの実行

第3章でSnapshot Repositoryを作成し、第4章ではSnapshotを取得しました。本節では、取得したSnapshotからデータを復元する方法を学習します。RestoreにはSnapshot Restore APIを使用します。Restoreでは、Snapshot全体を復元することも、次節で説明するように特定のIndexのみを復元することもできます。

以下の例では、snapshot_02からデータを復元します。

POST _snapshot/my_repository/snapshot_02/_restore

正常にリクエストが受け付けられると、次のようなレスポンスが返されます。

{
  "accepted": true
}

下図は、blogs インデックスが存在していた為、Restoreに失敗しています。

一旦blogs インデックスを削除し、あらためてRestoreを実施します。

Snapshotの取得と同様に、Restore APIもデフォルトでは非同期で実行されます。そのため、accepted: trueはRestore要求が受け付けられたことを示しているだけであり、この時点では復元は完了していません。

Restoreの完了まで待機したい場合は、wait_for_completion=trueを指定します。

POST _snapshot/my_repository/snapshot_02/_restore?wait_for_completion=true

この場合は、Restoreが完了してからレスポンスが返されるため、すぐに実行結果を確認できます。ただし、復元対象のデータ量が多い場合は、その分APIの応答時間も長くなります。

Restoreを実行する際は、復元先に同名のIndexが存在しているとRestoreは失敗します。既存のIndexを残したまま復元したい場合は、後述するRename Restoreを利用します。

特定IndexのRestore

Restore APIでは、Snapshotに含まれるすべてのIndexを復元するだけでなく、indicesオプションを使用して特定のIndexのみを復元することもできます。必要なIndexだけを復元したい場合や、大規模なSnapshotから一部のデータのみを取り出したい場合に利用します。

以下の例では、snapshot_01に含まれるblogsのみをRestoreしています。

POST _snapshot/my_repository/snapshot_01/_restore
{
  "indices": "blogs"
}

複数のIndexを復元する場合は、カンマ区切りで指定します。

POST _snapshot/my_repository/snapshot_01/_restore
{
  "indices": "blogs,orders,customers"
}

indicesを指定した場合は、指定したIndexのみがRestoreされます。Snapshotに含まれる他のIndexやData Streamは復元されません。

また、第4章で説明したinclude_global_stateは、Snapshot取得時にCluster StateやFeature Stateを含めるかどうかを指定するオプションでした。一方、アプリケーションのIndexのみを復元する場合は、通常include_global_stateを復元する必要はありません。そのため、第4章で作成したinclude_global_state: falseのSnapshotは、アプリケーションデータのみを別環境へ移行したい場合にも利用しやすいSnapshotとなります。

Rename Restore

前節では、特定のIndexのみをRestoreする方法を説明しました。しかし、Restore先に同名のIndexが存在している場合は、Restoreは失敗します。このような場合は、Restore時にIndex名を変更するRename Restoreを利用します。

Rename Restoreでは、rename_patternとrename_replacementを指定して、Snapshot内のIndex名を別の名前へ変更しながらRestoreできます。

以下の例では、blogsをrestore_blogsという名前でRestoreしています。

POST _snapshot/my_repository/snapshot_02/_restore
{
  "indices": "blogs",
  "rename_pattern": "blogs",
  "rename_replacement": "restore_blogs"
}

確認コマンド

GET _cat/indices/restore*?v

また、正規表現を利用すると、複数のIndex名をまとめて変更できます。次の例では、Restore対象のすべてのIndex名の先頭にrestore_を付与しています。

POST _snapshot/my_repository/snapshot_02/_restore
{
  "rename_pattern": "(.+)",
  "rename_replacement": "restored_$1"
}

Restoreが完了すると、元のIndexはそのまま残り、新しいIndex名でデータが復元されます。そのため、本番環境のデータを保持したままSnapshotの内容を検証したい場合や、別名のIndexとして比較・検証したい場合に便利です。

Searchable Snapshot <Enterpriseライセンス専用>

Searchable Snapshotの作成

第4章ではSnapshotの取得、第5章ではSnapshotからデータをRestoreする方法を説明しました。本節では、SnapshotをRestoreすることなく、そのまま検索対象として利用するSearchable Snapshotを学習します。Searchable Snapshotは、Snapshot Repository上のSnapshotをMountすることで、検索可能なIndexとして利用する機能です。通常のRestoreのようにIndexを完全に復元する必要がないため、ストレージ容量を削減しながらデータを検索できます。

Searchable Snapshotを利用するには、あらかじめSnapshot Repositoryを作成し、Snapshotを取得しておく必要があります。その後、Mount APIを実行してSnapshotを検索可能なIndexとして登録します。

以下の例では、snapshot_02に保存されているblogsをrestored_blogsという名前でMountしています。

POST /_snapshot/my_repository/snapshot_02/_mount
{
  "index": "blogs",
  "renamed_index": "restored_blogs"
}

Searchable Snapshotは “Enterpriseライセンス” 専用
上図では、Searchable Snapshotを作成するためにMount APIを実行していますが、403 Forbiddenが返され、作成に失敗しています。
{
  "type": "security_exception",
  "reason": "current license is non-compliant for [searchable-snapshots]"
}
このエラーは、現在適用されているライセンスではSearchable Snapshotを利用できないことを示しています。

Searchable Snapshotは、Enterpriseライセンス専用の機能です。BasicライセンスやPlatinumライセンスでは利用できないため、Mount APIを実行しても上図のようなsecurity_exceptionが返されます。

そのため、Searchable Snapshotを利用する前に、対象環境へEnterpriseライセンスが適用されていることを確認しておきましょう。
補足
現在のライセンスは、次のAPIで確認できます。
GET /_license
レスポンスのtypeを確認することで、現在適用されているライセンスの種類や状態を確認できます。Searchable Snapshotを利用するには、typeがenterpriseであり、ライセンスが有効な状態である必要があります。
Elastic Docs > Deploy and manage > Backup, high availability, and resilience tools > Snapshot and restore > Searchable snapshots
https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore/searchable-snapshots
Elastic self-managed subscriptions
https://www.elastic.co/subscriptions/

正常に作成されると、通常のIndexと同様に検索を実行できます。

GET restored_blogs/_search

Searchable Snapshotでは、Snapshot内のIndexを直接Mountするため、通常のRestoreとは異なり、新たにIndexデータを完全に復元するわけではありません。そのため、大量のアーカイブデータを低コストで保持しつつ、必要なときだけ検索したい場合に適しています。

一方で、Searchable SnapshotはSnapshot Repository上のデータを利用するため、Repositoryへアクセスできる状態であることが前提となります。また、Mount時にはrenamed_indexを指定するため、既存Indexと名前が重複することはありません。

ILMで指定するSearchable Snapshot

Searchable Snapshotは、Mount APIを使用して手動で作成するだけでなく、ILM（Index Lifecycle Management）から自動的に作成することもできます。

ILM Policyの ”searchable_snapshot” アクションを設定すると、指定したフェーズ（通常はColdまたはFrozen）へ移行する際にSnapshotを取得し、そのSnapshotをSearchable SnapshotとしてMountします。これにより、検索機能を維持したままローカルストレージの使用量を削減できます。

なお、Searchable SnapshotをILMで利用する場合も、事前にSnapshot Repositoryを登録しておく必要があります。また、Searchable Snapshotはライセンスが必要な機能であるため、利用可能なライセンスが適用されていることを確認しておきましょう。

Searchable Snapshotの確認

Searchable SnapshotをMountすると、通常のIndexと同様に検索できます。MountされたIndexは、CAT Indices APIやSearch APIを使用して確認できます。

例えば、restored_blogsという名前でMountした場合は、次のコマンドでIndexの存在を確認できます。

GET _cat/indices/restored*?v

また、通常のIndexと同様に検索を実行できます。

GET restored_blogs/_search

Kibanaでは、Stack Management > Index Management > IndicesからMountされたIndexを確認できます。

Searchable Snapshotの削除

不要になったSearchable Snapshotは、MountされたIndexを削除することで利用を終了できます。

例えば、restored_blogsを削除する場合は、通常のIndexと同様にDelete Index APIを実行します。

DELETE restored_blogs

この操作で削除されるのは、MountされたSearchable SnapshotのIndexのみです。Snapshot Repositoryに保存されているSnapshot自体は削除されず、そのまま保持されます。

RestoreとMount

RestoreとMountは、どちらもSnapshotを利用してデータを参照するための機能ですが、データの利用方法が異なります。

Restoreは、Snapshot内のIndexをElasticsearchへ復元する機能です。復元後は通常のIndexとして利用でき、Snapshot Repositoryへアクセスできなくなっても影響を受けません。

一方、Mountは、Snapshot内のIndexをElasticsearchへ完全に復元することなく、検索可能なIndex（Searchable Snapshot）として利用する機能です。そのため、ローカルストレージの使用量を抑えながらデータを検索できますが、利用中はSnapshot Repositoryへアクセスできることが前提となります。また、Searchable SnapshotはEnterpriseライセンス専用の機能です。

Restore基本コマンド

POST _snapshot/my_repository/my_snapshot/_restore
{
  "indices": "blogs"
}

Mount基本コマンド

POST /_snapshot/my_repository/my_snapshot/_mount
{
  "index": "blogs",
  "renamed_index": "restored_blogs"
}

Snapshot Lifecycle Management (SLM)

SLM Policyの作成

第4章ではSnapshotを手動で取得する方法を説明しました。本節では、Snapshotの取得を自動化する「Snapshot Lifecycle Management（SLM）」を学習します。SLMには、

Snapshotを定期的に取得する処理
不要になった古いSnapshotを定期的に削除する処理

の2つの役割があります。後者はRetentionと呼ばれ、保持期間や保持数を設定することで、不要になったSnapshotを自動的に削除できます。SLMでは、Policyを作成することで、これらの処理を指定したスケジュールに従って実行できます。手動でSnapshotを取得する運用に比べ、取得漏れを防ぎ、バックアップ運用を効率化できます。

SLM Policyを作成するには、事前にSnapshot Repositoryを登録しておく必要があります。以下の例では、my_repositoryへ毎日午前1時にSnapshotを取得し、Snapshot名をdaily-snapshotとしています。

PUT _slm/policy/daily_policy
{
  "schedule": "0 0 1 * * ?",
  "name": "<daily-snapshot-{now/d}>",
  "repository": "my_repository",
  "config": {
    "indices": [
      "blogs"
    ],
    "include_global_state": false
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 30
  }
}

正常に作成されると、次のようなレスポンスが返されます。

主な設定項目は次のとおりです。

項目	説明
schedule	Snapshotを取得するスケジュール（Cron形式）
name	Snapshot名。日付などを含めた名前を自動生成できる
repository	保存先となるSnapshot Repository
config.indices	Snapshot対象のIndexまたはData Stream
config.include_global_state	Cluster StateやFeature Stateを含めるかどうか
retention	古いSnapshotの保持期間や保持数

schedule

Snapshotを取得するスケジュールをCron形式で指定します。ElasticsearchのCron式は、左から「秒、分、時、日、月、曜日」の6項目で構成され、必要に応じて末尾に「年」を加えます。

秒分時日月曜日 [年]

例えば、次の指定は毎日UTCの1時30分にSnapshotを取得します。

“schedule”: “0 30 1 * * ?”

各値の意味は次のとおりです。

値	項目	意味
0	秒	0秒に実行
30	分	30分に実行
1	時	1時に実行
*	日	毎日
*	月	毎月
?	曜日	曜日を指定しない

“ * ”は「すべての値」、?は「指定なし」を意味します。日と曜日は同時に指定せず、どちらか一方に?を指定するのが基本です。また、”0/30” のような間隔指定(※)、”MON-FRI” のような範囲指定、”MON,WED,FRI” のような複数指定も利用できます。

※ 間隔指定

分の場合 : “0/30” を分に指定した場合は、0分から30分間隔で実行されます。例えば、0分、30分に実行されます。

時間の場合 : “0/6” を時間に指定した場合は、0時から6時間間隔で実行されます。例えば、0時、6時、12時、18時に実行されます。

SLMのCron式はUTCを基準に実行されます。たとえば、日本時間の毎日午前2時に実行したい場合は、UTCでは前日の17時となるため、次のように指定します。

“schedule”: “0 0 17 * * ?”

参考として、以下のSLMで取得されたSnapshotをKibanaで確認します。

PUT _slm/policy/daily_snapshot_jst_9am
{
  "schedule": "0 30 0 * * ?",
  "name": "<daily-snapshot-{now/d}>",
  "repository": "my_repository",
  "config": {
    "indices": "*",
    "include_global_state": true
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

Stack Management > Snapshot and Restore

上図のように「daily-snapshot-2026.07.17-qcqg1wkqspgrtzbc0a66kq」という名称で、日本時間09:30にsnapshotが取得されています。

name

作成されるSnapshot名を指定します。<snapshot-{now/d}>のように日付や時刻を含む名前を自動生成できるため、世代管理を容易に行えます。

{now}は、Snapshot取得時点の日時に置き換えられます。{now/d}を指定した場合は日付のみが使用されますが、<daily-snapshot-{now{yyyy.MM.dd-HH.mm.ss}}>のように日時のフォーマットを指定すると、daily-snapshot-2026.07.17-09.30.00のようなSnapshot名を生成できます。同じ日に複数回Snapshotを取得する場合は、このように時刻まで含めることでSnapshot名の重複を防ぐことができます。

repository

Snapshotの保存先となるSnapshot Repositoryを指定します。事前に作成したRepositoryを指定し、そのRepositoryへSnapshotが保存されます。

config

configでは、Snapshotの取得対象や取得方法を指定します。

パラメータ	説明
indices	Snapshotの対象となるIndexまたはData Streamを指定します。複数指定やワイルドカードも利用できます。
include_global_state	Cluster StateやFeature StateをSnapshotに含めるかどうかを指定します。
ignore_unavailable	存在しないIndexや閉じられたIndexが含まれている場合に、処理を継続するかどうかを指定します。
partial	Primary Shardが利用できないIndexを含む場合でも、取得可能なShardのみをSnapshotに保存するかどうかを指定します。
feature_states	Snapshotに含めるFeature Stateを指定します。KibanaやSecurityなどのシステムデータを個別に指定できます。
metadata	Snapshotに任意のメタデータを付与します。用途や管理情報などを保存できます。

設定例

PUT _slm/policy/daily-snapshot-policy
{
  "schedule": "0 0 0 * * ?",
  "name": "<daily-snapshot-{now/d}>",
  "repository": "my_repository",
  "config": {
    "indices": [
      "logs-*",
      "orders",
      "metrics-*"
    ],
    "include_global_state": true,
    "ignore_unavailable": true,
    "partial": false,
    "feature_states": [
      "kibana",
      "security"
    ],
    "metadata": {
      "environment": "production",
      "created_by": "slm",
      "description": "Daily backup"
    }
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 30
  }
}

Elastic API Docs > v8 > Snapshot lifecycle management > Create or update a policy
https://www.elastic.co/docs/api/doc/elasticsearch/v8/operation/operation-slm-put-lifecycle

retention

retentionでは、不要になったSnapshotを削除する条件を指定します。Retention処理が実行されたタイミングで、設定した条件に従って古いSnapshotが自動的に削除されます。

パラメータ	説明
expire_after	Snapshotの保持期間を指定します。指定した期間を超えたSnapshotは削除対象となります。
min_count	保持するSnapshotの最小件数を指定します。保持期間を超えたSnapshotでも、この件数までは削除されません。
max_count	保持するSnapshotの最大件数を指定します。保持期間内であっても、この件数を超えた古いSnapshotは削除対象となります。

設定例

"retention": {
  "expire_after": "30d",
  "min_count": 5,
  "max_count": 30
}

この例では、Snapshotを30日間保持し、最低5件は必ず保持します。また、30件を超えた場合は、30日以内のSnapshotであっても古いものから削除されます。

SLM Policyの確認

前節ではSLM Policyを作成しました。本節では、作成したPolicyが正しく登録されていることを確認する方法を学習します。SLM Policyの確認には、Get SLM Policy API を使用します。すべてのPolicyを確認する場合は、次のコマンドを実行します。

GET _slm/policy

特定のPolicyのみを確認する場合は、Policy名を指定します。

GET _slm/policy/daily_policy

レスポンスには、Policyの設定内容が表示されます。

Kibanaでは Stack Management > Snapshot and Restore > Policies から登録済みのSLM Policyを確認できます。GUIでは、Policy名やスケジュール、Repositoryなどを一覧で確認できるため、設定内容を視覚的に確認したい場合に便利です。

SLM Policyの実行

前節ではSLM Policyが正しく登録されていることを確認しました。本節では、作成したSLM Policyを手動で実行する方法を学習します。

通常、SLM Policyはscheduleで指定した時刻に自動実行されます。しかし、設定内容をすぐに確認したい場合や、Snapshotが正常に取得できることを検証したい場合は、Execute SLM Policy API を使用して手動で実行できます。

以下の例では、daily_policyを手動で実行しています。

POST _slm/policy/daily_policy/_execute

正常にリクエストが受け付けられると、次のようなレスポンスが返されます。

SLM Policyの実行後は、第4章で説明したSnapshot Get APIを使用して、Snapshotが正常に作成されていることを確認します。

GET _snapshot/my_repository/_all

また、Kibanaでは Stack Management > Snapshot and Restore > Snapshots から、作成されたSnapshotを確認できます。Snapshot名や取得日時、状態などを一覧で確認できるため、SLM Policyが正常に実行されたかを視覚的に確認できます。

POST _slm/policy/{policy}/_executeは、指定したPolicyによるSnapshot取得を即座に実行するAPIです。scheduleには影響せず、次回以降は設定したスケジュールどおりに自動実行されます。そのため、Policyの動作確認や検証用途で利用すると便利です。

SLM Policyの削除

不要になったSLM Policyは、Delete SLM Policy APIを使用して削除できます。Policyを削除すると、Snapshotの自動取得は実行されなくなります。

以下の例では、daily_policyを削除しています。

DELETE _slm/policy/daily_policy

正常に削除されると、次のようなレスポンスが返されます。

SLM Policyを削除しても、これまでに取得したSnapshotやSnapshot Repositoryは削除されません。削除されるのは、Snapshotを自動取得するためのPolicyのみです。そのため、既存のSnapshotは引き続きRestoreやSearchable Snapshotなどで利用できます。

Retentionの実行

前節までで、SLM Policyの作成・確認・実行・削除について説明しました。本節では、Policyに設定したRetentionを実行し、不要になったSnapshotを削除する方法を学習します。

Retentionは、SLM Policy作成時に設定した保持期間や保持件数に基づいて、不要になったSnapshotを削除する処理です。Retentionを実行すると、各Policyのretention設定を参照し、削除条件に一致した古いSnapshotが自動的に削除されます。RetentionはSnapshotを取得する処理とは独立しており、Retentionを実行しても新しいSnapshotは作成されません。

Retentionを手動で実行するには、Execute Retention APIを使用します。

POST _slm/_execute_retention

正常にリクエストが受け付けられると、次のようなレスポンスが返されます。

このAPIはRetention処理の開始を要求するものであり、acknowledged: trueはリクエストが受け付けられたことを示します。実際に削除対象となるSnapshotは、各SLM Policyで設定したexpire_after、min_count、max_countの条件に従って削除されます。

通常の運用では、Retentionを手動で実行する必要はありません。SLMが内部で定期的にRetention処理を実行するため、設定した保持期間や保持件数に従って古いSnapshotは自動的に削除されます。

一方、Retention APIは、Policyの設定が正しく動作することをすぐに確認したい場合や、検証環境で不要なSnapshotを即座に削除したい場合に利用します。例えば、expire_afterやmax_countの設定を変更した直後にRetention APIを実行すると、期待どおりに古いSnapshotが削除されることをその場で確認できます。

そのため、本番環境では自動実行に任せ、手動実行は主に検証用途で利用するAPIと考えておけば十分です。

実践問題

Practice Question 1

A shared file system has already been configured in elasticsearch.yml as follows:

path.repo: ["/var/tmp/snapshots"]

Create a snapshot repository that meets the following requirements.

Repository name: training_repository
Repository type: Shared File System
Storage location: /var/tmp/snapshots
Enable repository data compression.

After creating the repository, verify that it has been registered successfully.

解答

PUT _snapshot/training_repository
{
  "type": "fs",
  "settings": {
    "location": "/var/tmp/snapshots",
    "compress": true
  }
}

解説

Shared File Systemを利用する場合は、Repositoryのtypeにfsを指定します。
locationには、elasticsearch.ymlのpath.repoで許可されているディレクトリを指定します。path.repoに登録されていないディレクトリは、Repositoryの保存先として使用できません。
compressをtrueにすると、Snapshotのメタデータが圧縮されます。Indexのデータファイル自体を圧縮する設定ではありません。
Repository作成後は、Snapshot Get Repository APIを使用して、種類や保存先が正しく登録されていることを確認します。
Repository確認コマンド

GET _snapshot/training_repository

Practice Question 2

Create an SLM policy named daily_blogs_policy that meets the following requirements.

Store snapshots in training_repository.
Run every day at 01:00 UTC.
Back up only the blogs index.
Do not include the global cluster state.
Use a snapshot name that includes the execution date.
Keep snapshots for 30 days.
Always keep at least 5 snapshots.
Never keep more than 30 snapshots.

解答

PUT _slm/policy/daily_blogs_policy
{
  "schedule": "0 0 1 * * ?",
  "name": "<daily-blogs-{now/d}>",
  "repository": "training_repository",
  "config": {
    "indices": [
      "blogs"
    ],
    "include_global_state": false
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 30
  }
}

解説

scheduleには、Snapshotを取得する時刻をCron形式で指定します。 0 0 1 * * ? このCron式は、毎日UTCの1時0分0秒に実行することを意味します。
nameには日付を含むSnapshot名を指定しています。{now/d}は実行日の日付に置き換えられ、実際のSnapshot名には重複を防ぐための識別子も自動的に付与されます。
config.indicesでblogsのみを取得対象とし、include_global_stateをfalseにすることで、Cluster StateやFeature Stateを取得対象から除外しています。
Retentionでは、30日を超えたSnapshotを削除対象としながら、最低5件を保持し、最大保持件数を30件に制限しています。
Policy確認コマンド GET _slm/policy/daily_blogs_policy

Practice Question 3

当問題は、SLM Policyの主要な設定項目を総合的に確認するためのトレーニング問題です。実際の試験で、ここまで細かな要件が一度に出題される可能性は高くありませんが、各パラメータの役割を理解し、自分でPolicyを作成できるようになることを目的としています。実際にコマンドを入力し、各設定の動作を確認してみましょう。

Create an SLM policy named weekday_application_policy that meets the following requirements.

Store snapshots in training_repository.
Run at 09:30 UTC from Monday through Friday.
Back up the logs-*, orders, and metrics-* indices.
Continue processing even if one of the specified indices does not exist.
Fail the snapshot if a primary shard is unavailable.
Do not include the global cluster state.
Add the following metadata:
- environment: production
- backup_type: weekday
Include the execution date and time in the snapshot name.
Keep snapshots for 14 days.
Always keep at least 10 snapshots.
Never keep more than 50 snapshots.

解答

PUT _slm/policy/weekday_application_policy
{
  "schedule": "0 30 9 ? * MON-FRI",
  "name": "<application-{now{yyyy.MM.dd-HH.mm.ss}}>",
  "repository": "training_repository",
  "config": {
    "indices": [
      "logs-*",
      "orders",
      "metrics-*"
    ],
    "include_global_state": false,
    "ignore_unavailable": true,
    "partial": false,
    "metadata": {
      "environment": "production",
      "backup_type": "weekday"
    }
  },
  "retention": {
    "expire_after": "14d",
    "min_count": 10,
    "max_count": 50
  }
}

解説

scheduleにはCron形式で実行スケジュールを指定します。”0 30 9 ? * MON-FRI” は、毎週月曜日から金曜日の09:30（UTC）にSnapshotを取得することを表します。
indicesには、複数のIndexとワイルドカードを指定しています。
ignore_unavailableをtrueにしているため、指定したIndexの一部が存在しなくても、存在するIndexを対象としてSnapshotの取得を継続します。
partialをfalseにしているため、対象IndexのPrimary Shardが利用できない場合は、取得可能なShardだけを保存するのではなく、Snapshotの取得を失敗させます。
metadataにはSnapshotの用途を示す任意の管理情報を保存しています。この情報は、Snapshotの内容を確認する際に参照できます。
Snapshot名には日付だけでなく時刻も含めています。同じ日に複数回Policyを実行した場合でも、実行時刻を確認しやすい形式になります。
Retentionでは14日間の保持に加えて、最低10件、最大50件という件数条件を設定しています。14日以内であっても50件を超えた古いSnapshotは削除対象となり、14日を超えていても保持件数が10件を下回る場合は削除されません。

Policy確認コマンド

GET _slm/policy/weekday_application_policy

Policy手動実行コマンド

POST _slm/policy/weekday_application_policy/_execute

Snapshot確認コマンド

GET _snapshot/training_repository/_all

Elastic社が提供する無料Hands-on Trainingで理解を深めよう

本記事では、Snapshot Repositoryの作成からSnapshot、Restore、Searchable Snapshot、SLMまで、Elastic Certified Engineer Examで求められる基本操作を学習しました。ここまで理解できれば試験対策として十分ですが、さらに理解を深めたい場合は、Elastic社が提供している無料のHands-on Trainingも活用してみましょう。

Hands-on Trainingでは、実際にElasticsearchやKibanaを操作しながらSnapshotの取得やRestore、SLM Policyの作成などを体験できます。APIを実行するだけでなく、GUIから各機能を確認できるため、試験対策だけでなく実務での運用イメージも身につきます。

受講にはElastic Cloudのアカウントが必要です。以下のサイトからElastic Cloudのアカウントを作成し、無料のHands-on Trainingを体験してみましょう。本記事で学習した内容を実際に操作しながら復習することで、Elasticsearchへの理解をさらに深めることができます。

Elastic Cloud アカウント作成
https://cloud.elastic.co/registration

Elastic Training
https://www.elastic.co/training

Elastic Learning Portal
https://learn.elastic.co/pages/58/home-page

試験対策ポイント

SLM Policyを作成、実行できること
schedule、repository、config、retentionなどの主要な設定項目を理解し、基本的なSLM Policyを作成できるようにしておく。
SLM Policyを実行できること手動実行（_execute）によるSnapshot取得ができるようにしておく。
要件に沿ったRepositoryの作成ができること。

基本的なRepositoryの作成、SLMの定義と実行を習得しておき、SLMのconfigについては、公式のドキュメントで、該当箇所を確認し、解答できるように準備しておくことをお勧めします。
https://www.elastic.co/docs/api/doc/elasticsearch/v8/operation/operation-slm-put-lifecycle