事例Elasticsearchのスナップショットは増分で管理されているけど、最も古いスナップショットを削除してもリストアできる自称OSクラッシュおじさんがElasticsearchを破壊した時に備えてスナップショットの仕様を確認しました。Serviceのんピ2021.08.10727この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。もといOSクラッシュおじさんです。Serverのシステム領域を削除して、OSを破壊してきました。Serviceの手動スナップショットをLambdaで管理するブログを書きました。このブログを書いているとき、ふと「Elasticsearchのスナップショットの仕様を知らないと、安心してElasticsearchを破壊できない」と思いました。そんな思いを払拭するために、Elasticsearchのスナップショットについて調べると、以下のように「スナップショットは増分で作成され、最後に成功したスナップショット以降に変更されたデータのみを保存する」との記載がありました。古いスナップショットを削除しても、正しくリストアができるのか気になったので、検証してみます。まとめElasticsearchのスナップショットは増分で管理されるけど、最も古いスナップショットを削除しても正常にリストアできるドキュメントを確認してみるもう少しドキュメントを確認してみます。APIを使ってください」という記載がありました。snapshotsわざわざAPI経由で削除するということは、単純にスナップショットのデータを削除するだけではなく、裏側で様々な処理が発生していそうですね。Stackの管理ツールである、ELKmanのブログを確認すると以下のような記載がありました。Deletes機械翻訳結果は以下の通りです。削除は完全にマスターノードによって実行されます。リポジトリを読み込んで、削除するスナップショットのインデックス、シャード、セグメントのリストを作成します。次に、マスターは他のすべてのスナップショットのメタデータを再読み込みし、重要なのは、それらに含まれるインデックスとセグメントを再読み込みします。削除予定のスナップショットのリストと、used-by-other-snaphotsのリストを比較します。残っているスナップショットから参照されていないものは削除マークが付けられ、基本的に必要のないセグメントは削除されますが、必要なものはすべて残されます。残りのスナップショットから参照されていないレポ内のインデックスも削除されます。このエレガントなソリューションは、非常に柔軟で堅牢です。スナップショットを削除する際に、他のスナップショットのメタデータを読み込んで、他のスナップショットから参照されているデータは残すようです。仕組みとしては、EBSスナップショットの世代管理と同様に、最も古いスナップショットを削除してしまっても大丈夫そうですね。世代管理の仕組み)最も古いスナップショットを削除しても正常にリストアできるか確認してみるリストア前の準備それでは、実際に最も古いスナップショットを削除しても正しくリストアができるか確認をしてみます。リストア前のデータ件数を確認します。17:00のCloudTrailのデータ件数は、2,462件であることが分かります。8:59に作成された2つを用意しました。]}これで一つ目のスナップショット(test-delete-snapshot-2021-08-10t08-39-16)を削除します。true}スナップショットの一覧を再度表示すると、確かに削除されていることが確認できます。]}最後に、リストアする前準備として、CloudTrailのインデックスをクローズします。}}CloudTrailのインデックスをクローズした後、Discoverを確認すると「検索条件に一致する結果がありません」とのメッセージが出力されました。リストアと確認それでは、以下コマンドでスナップショットからCloudTrailのインデックスをリストアします。true}リストア後にDiscoverを確認すると、CloudTrailのデータ件数は、2,696件と正しくインデックスがリストアできていることが分かります。古いスナップショットを削除しても正常にリストアできるElasticsearchのスナップショットの仕様が気になったので検証してみました。これで安心してElasticsearchを壊せそうです。APIを一通り叩いてみた。