はじめに
Elastic Cloudでは、既存のデプロイメントのスナップショットバックアップを別のデプロイメントにリストアすることができます。
ただ、元のデプロイメントにデータが大量に存在すると時間がかかるので、フルのリストアは手軽には実施できません。この記事では、設定値まわりと一部のユーザーデータだけをリストアする方法をご紹介します。
今回の環境はElastic Stack 9.0を使用していますが、v8でも同様に動くと考えられます。
手順
リストア先のデプロイメントにソースのスナップショットリポジトリを登録
新しいデプロイメントを作成後、クラウドコンソールのこの画面よりRestore from another deployment
を選択します。
ここではリポジトリの登録だけが目的なので、Specify Indices
部分は空にして、リストアを実行します。
その後、KibanaにログインしてスナップショットのRepositories
タブの設定を確認すると、このように_clone_xxxxxxxx
といったリポジトリが作成されています。これが今の操作で登録されたソースとなるデプロイメントのスナップショット・リポジトリです。
リストアの実行
Snapshots
のタブからこのソースの方の最新のスナップショットのリンクをクリックします。
リストア設定では以下の赤いところを変更します。基本的にはデータはリストアせず、Global stateとfeature stateだけをリストアします。Index patternsは指定なしの意味で-*
といれてください。
最後のAPIで同じ操作をするときのコマンドも確認した上で、リストアを実行します。
リストアを実行すると、セキュリティ周りの設定もリストアされるため、Kibanaが動作しなくなり、強制ログアウトされると思います。その後アクセスしようとすると、以下のようなエラーが出ました。
{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred. Check Kibana server logs for details."}
{"statusCode":500,"error":"Internal Server Error","message":"[illegal_argument_exception\n\tRoot causes:\n\t\tillegal_argument_exception: application privileges must refer to at least one resource]: application privileges must refer to at least one resource"}
3分ほど待ちましたが、まだエラーしていたため、以下のクラウドコンソールからKibanaのForce Restartを実行しました。そうするとKibanaへログインできるようになりました。
リストアされたデータの確認 (Global Stateデータ)
リストアする際に指定したGlobal Stateが何かは以下のマニュアルに書かれています。
https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore#snapshot-contents
- Persistent cluster settings
- Index templates
- Legacy index templates
- Ingest pipelines
- ILM policies
- Stored scripts
いくつかリストアされていることを確認しました。
-
Cluster settingsの確認 (デフォルト値を変更したauto_create_index がfalseに正しくリストアされていました)
-
Snapshot Policyの確認 (デフォルト値を変更したSchedule */31 が正しくリストアされていました)
リストアされたデータの確認 (Feature Stateデータ)
Feature Stateとは何か?は以下のコマンドでリストを取得できます。全てをリストアするので問題ないと思いますが、最低限同じようなユーザー環境やダッシュボードをリストアするにはkibanaとsecurityの指定が必要です。
{
"features": [
{
"name": "ent_search",
"description": "Manages configuration for Enterprise Search features"
},
{
"name": "async_search",
"description": "Manages results of async searches"
},
{
"name": "synonyms",
"description": "Manages synonyms"
},
{
"name": "kibana",
"description": "Manages Kibana configuration and reports"
},
{
"name": "transform",
"description": "Manages configuration and state for transforms"
},
{
"name": "logstash_management",
"description": "Enables Logstash Central Management pipeline storage"
},
{
"name": "searchable_snapshots",
"description": "Manages caches and configuration for searchable snapshots"
},
{
"name": "security",
"description": "Manages configuration for Security features, such as users and roles"
},
{
"name": "tasks",
"description": "Manages task results"
},
{
"name": "inference_plugin",
"description": "Inference plugin for managing inference services and inference"
},
{
"name": "enrich",
"description": "Manages data related to Enrich policies"
},
{
"name": "fleet",
"description": "Manages configuration for Fleet"
},
{
"name": "watcher",
"description": "Manages Watch definitions and state"
},
{
"name": "geoip",
"description": "Manages data related to GeoIP database downloader"
},
{
"name": "machine_learning",
"description": "Provides anomaly detection and forecasting functionality"
}
]
}
ここもいくつかリストア状況を確認します。
念のため同じAPIキーが、リストア先でも通る確認しましたが、問題ありませんでした。
ユーザー・インデックス・データのリストア(一部だけ)
こちらのソースのデプロイメントにあるData Streamsをリストアしていきます。
このData StreamのBacking Indexも確認しておきます。Hot Data tierに2つあるのと、Frozen Data tierに1つあります。
リストアする際はこのようにData Stream名だけ指定しました。Data Stream全体ではなく、一部のBacking Indexだけリストアすることも可能です。
結果をDiscoverで確認します。左がリストア先、右がリストア元です。この時点ではFrozen Data Tierをリストア先デプロイメントでは有効にしていないので、そのデータの分だけ参照できていませんが、Hot Data Tierの方は参照できています。
Searchable Snapshotであるpartial-*のデータも参照できるようになりました!
念のため新しいログが書き込みできることも確認しました。
POST /mylogs-test01/_doc
{
"@timestamp": "2025-06-24T01:16:44Z",
"message": "ingest into a new deployment!"
}
そのままでは動かなかったもの
AI Assistantの中で使われているシークレットなAPIキーが別デプロイメントではリストアできないようなので、ここはシークレットな値の設定のし直しが必要です。同じように他のConnector周りでもAPIキーの設定のし直しは必要かもしれません。
おわり
リストアは設定を理解していないと、とっつきにくいですが、このように一度テストしてみると安心感が出て、いざ何かをリストアしないといけない時に役立ちます。
Elastic Cloudの場合はこのように比較的手軽に別デプロイメントにリストア可能です。