システムバージョン:centos 7ソフトウェアバージョン:Elasticsearch 7.3.2
Elasticsearchはsnapshot APIをバックアップとして提供しています

方法一(crul)

注:elasticsearchユーザーは、プロファイルの変更、>バックアップ・ウェアハウスの作成、>作成したウェアハウスへのインデックスのバックアップの開始、>データのリカバリ(リカバリ・インデックスが存在する場合は閉じる)のコマンド・フローを実行する必要があります.

1、プロファイルの変更(開始):

①Elasticsearchのプロファイルを修正するelasticsearch.ymlで設定を追加するには:

vim /elasticsearch-7.3.2/config/elasticsearch.yml

修正内容は次のとおりです.

path.repo: /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

2、バックアップ倉庫ディレクトリの作成

curl -H "Content-Type: application/json" -X PUT http://IP :9200/_snapshot/esbackup -d'{
    "type": "fs", 
    "settings": {
        "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/esbakup"
    }
}'

3、バックアップ（バックアップ完了後に結果を返すためにwait_for_completion=trueパラメータを追加する必要がある場合；バックアップの名称：snapshot_20191028）

curl -H "Content-Type: application/json" -X PUT http://IP :9200/_snapshot/esbackup/snapshot_20191028?wait_for_completion=true

4、バックアップ状況の表示

curl -X GET "http://IP :9200/_snapshot/esbackup/_all?pretty"

[elasticsearch@test1 root]$ curl -X GET “http://IPアドレス:9200/snapshot/esbackup/_all?pretty” { “snapshots” : [ { “snapshot” : “snapshot_20191028”, “uuid” : “ZofYODhERHeE4PefB_Q47Q”, “version_id” : 7030299, “version” : “7.3.2”, “indices” : [ “a”, “aaa”, “table_2” ], “include_global_state” : true, “state” : “SUCCESS”, “start_time” : “2019-10-28T07:23:06.076Z”, “start_time_in_millis” : 1572247386076, “end_time” : “2019-10-28T07:23:06.312Z”, “end_time_in_millis” : 1572247386312, “duration_in_millis” : 236, “failures” : [ ], “shards” : { “total” : 11, “failed” : 0, “successful” : 11 } } ] }
バックアップのインデックスが「a」、「aaa」、「table_2」であることがわかります.

5、データの復旧（終了）

リカバリデータ=クラスタのスナップショットIDに後を付ける_restoreでOK、(?wait_for_completion=trueコールバックプロンプトが成功したかどうか)

curl -X POST http://1IP :9200/_snapshot/esbackup/snapshot_20191028/_restore?wait_for_completion=true

実行結果は次のとおりです.対応するインデックス・データがリカバリされたことを示します.
[elasticsearch@test1 root]$ curl -X POST http://IPアドレス:9200/snapshot/esbackup/snapshot_20191028/_restore?wait_for_completion=true {“snapshot”:{“snapshot”:“snapshot_20191028”,“indices”:[“aaa”,“a”,“table_2”],“shards”:{“total”:11,“failed”:0,“successful”:11}}}[elasticsearch@test1 root]$

6、検証

[yeemiao@localhost esbak]$ curl -X GET ‘http://IPアドレス:9200/cat/indices?v’ここで出力は元のホストの結果と一致する
[elasticsearch@test1 config]$ curl -X GET ‘http://IPアドレス:9200/cat/indices?v’ health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open aaa CvzBAfCbSPG9lQg8XrgC6Q 5 1 1 0 4.9kb 4.9kb yellow open a qY3DAJGKSlmEyPQ3k-4STg 5 1 3 0 11.9kb 11.9kb yellow open table_2 WlaimLOuRvevtqtwscAfuw 1 1 3 0 10.9kb 10.9kb [elasticsearch@test1 config]$

以下は参考までにしてください。

方法2(es-head)

1、バックアップ倉庫を作成する（自分のシステム構成ファイルシステムによって選択すればよい）

バックアップAPIを使用する前に、複数の倉庫タイプを選択できる倉庫を作成する必要があります.

共有ファイルシステム、例えばNAS

Amazon S3

HDFS(Hadoop分散ファイルシステム)

Azure Cloud

倉庫を作成する前に:1 Elasticsearchのプロファイルelasticsearchを変更します.ymlで設定を追加するには:

vim /elasticsearch-7.3.2/config/elasticsearch.yml

修正内容は次のとおりです.

path.repo: /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

バックアップ・ウェアハウスの場所を選択(/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup)
:wq保存後ES②を再起動し、_を呼び出すsnapshot apiは倉庫を作成し、「fs」は倉庫タイプを表し、「location」はバックアップ場所である.

PUT http:IP :9200/_snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/my_backup" 
    }
}

PUT _snapshot/my_backup#は私たちの倉庫に名前をつけました.スナップショットの名前です.この例ではmyと呼ばれています.backup . 「type」:「fs」、#倉庫のタイプは共有ファイルシステムであるべきであることを指定します.「location」:「/mount/backups/my_backup」#マウントディレクトリ.
注意:max_snapshot_bytes_per_secスナップショットデータが倉庫に入ると、このパラメータはこのプロセスのストリーム制限状況を制御する.デフォルトは毎秒20 mbです.max_restore_bytes_per_sec倉庫からデータを復元すると、このパラメータは、ネットワークが満たされないことを保証するために、いつリカバリプロセスがストリームに制限されるかを制御します.デフォルトは毎秒20 mbです.これらの構成を増やして速度をカスタマイズする必要がある場合は、POSTを使用します.

POST http:IP :9200/_snapshot/my_backup/  {
     "type": "fs",
     "settings": {
         "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/my_backup",
         "max_snapshot_bytes_per_sec" : "50mb", 
         "max_restore_bytes_per_sec" : "50mb"
     } }
 
   POST   PUT 。 。

2、バックアップ開始

開いているすべてのインデックスをleo_にバックアップ20191028では、呼び出し後すぐに結果が返され、スナップショットがバックグラウンドで実行され、バックアップが完了すると、バックアップディレクトリの下に対応するファイルが表示されます.

PUT http:IP :9200/_snapshot/my_backup/leo_20191028

通常、バックグラウンドプロセスとしてスナップショットを実行することを望んでいますが、スクリプトが完了するまで待機したい場合があります.これはwaitを追加することでfor_completionタグ実装:スナップショットが完了するまで呼び出しがブロックされます.大きなスナップショットが戻ってくるのに時間がかかることに注意してください.

PUT _snapshot/my_backup/leo_20191028?wait_for_completion=true

インデックスをいくつかだけバックアップすることもできます.

PUT _snapshot/my_backup/leo_1
{
    "indices": "index_1,index_2"
}

使用できないインデックスを無視したり、共通の部分をバックアップしないなど、他のパラメータに参加することもできます.

PUT _snapshot/my_backup/leo_2
{
    "ignore_unavailable": true,
	"include_global_state": false
}

スナップショットを表示するときに使用できます.

GET _snapshot/my_backup/leo_20191028

倉庫内のすべてのスナップショットの完全なリストを取得するには、次の手順に従います.allプレースホルダは、特定のスナップショット名を置き換えます.「_all」を使用するのは一般的です.たとえば、すべてのスナップショットを閉じたり、すべてのスナップショットを開いたりして使用できます.

GET _snapshot/my_backup/_all
# 
POST _all/_close
# 
POST _all/_open

3、Elasticsearchバックアップリストア

リカバリデータ=クラスタのスナップショットIDに後を付ける_restoreでいいです(注:デフォルトはスナップショット内のすべてのインデックスを復元します)

POST _snapshot / my_backup / snapshot_1 / _restore
POST http:IP :9200/_snapshot/my_backup/leo_20191028/_restore

リカバリコマンドにwait_を付けることもできますfor_completion=trueパラメータ

POST http:xxxx:9200/_snapshot/my_backup/leo_20191028/_restore?wait_for_completion=true

次の参照:他のライブラリにリカバリする必要がある場合は、次の操作を行います。

1、バックアップ倉庫のパッケージング

cd /home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

以下の経路はelasticsearchである.ymlが配置するバックアップウェアハウスの位置path.repo:/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup

tar -czvf esbakup20191028.tar ./esbakup

特に、元のマシンのバックアップファイルをディレクトリに加圧するため、元のマシンと一致するパラメータに注意してください.
path.repo:/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup
2、esデータを復元する倉庫の場所に解凍する

tar -xvf esbakup20191028.tar

3、リカバリの実行時にバックアップ指定ディレクトリを作成する必要がある

curl -H "Content-Type: application/json" -X PUT http://IP :9200/_snapshot/esbackup -d'{
    "type": "fs", 
    "settings": {
        "location": "/home/elasticsearch/deploy/elasticsearch-7.3.2/data/backup/esbakup"
    }
}'

4、バックアップ情報を確認する.この時点でバックアップ情報はcurl-X GETに登録されている.http://IPアドレス:9200/snapshot/esbackup/_all?pretty”
5、リカバリを実行すれば?にさせておく

curl -X POST http://1IP :9200/_snapshot/esbackup/snapshot_20191028/_restore?wait_for_completion=true

6、検証

curl -X GET 'http://IP :9200/_cat/indices?v'

============================================================

索引を閉じる

curl -XPOST 'http://192.168.180.46:9200/schema_1/_close/' #（_open ）

スナップショットの編集をキャンセル

スナップショットを削除する場合は、バックアップファイルを直接削除することをお勧めしません.DELETEを使用すると、スナップショットプロセスが中断されます.次に、倉庫で半分に行われたスナップショットを削除します.

DELETE _snapshot/my_backup/leo_1

スナップショットをAPIで削除することは重要であり、他のメカニズム(例えば手動で削除したり、S 3上の自動クリアツールを使用したり)は使用できません.スナップショットはインクリメンタルなので、過去のセグメントに依存するスナップショットが多い可能性があります.delete APIでは、どのデータがより最近のスナップショットで使用されているかがわかり、使用されなくなったセグメントのみが削除されます.
ただし、手動でファイルを削除すると、まだ使用中のデータを削除している可能性があるため、バックアップが深刻に破損するリスクに直面します.

スナップショットの進行状況編集の監視

wait_for_completionタグはモニタリングの基礎形式を提供していますが、中規模のクラスタをスナップショットリカバリするだけでは本当に十分ではありません.
他の2つのAPIは、スナップショットのステータスについてより詳細な情報を提供します.まず、特定のスナップショットの情報を取得したときに行ったように、スナップショットIDにGETを実行できます.

GET _snapshot/my_backup/snapshot_3

このコマンドを呼び出したときにスナップショットが進行中の場合は、いつ開始され、どのくらい実行されたかなどの情報が表示されます.ただし、このAPIはスナップショットメカニズムが同じスレッドプールを使用していることに注意してください.スナップショットが非常に大きいスライスでは、APIが同じスレッドプールリソースを競合しているため、ステータス更新の間隔が大きくなります.
もっと良い案は引き抜くことです.status APIデータ:

GET _snapshot/my_backup/snapshot_3/_status

_status APIはすぐに戻り、詳細な統計値の出力を与えます.

{
   "snapshots": [
      {
         "snapshot": "snapshot_3",
         "repository": "my_backup",
         "state": "IN_PROGRESS", ①
         "shards_stats": {
            "initializing": 0,
            "started": 1, ②
            "finalizing": 0,
            "done": 4,
            "failed": 0,
            "total": 5
         },
         "stats": {
            "number_of_files": 5,
            "processed_files": 5,
            "total_size_in_bytes": 1792,
            "processed_size_in_bytes": 1792,
            "start_time_in_millis": 1409663054859,
            "time_in_millis": 64
         },
         "indices": {
            "index_3": {
               "shards_stats": {
                  "initializing": 0,
                  "started": 0,
                  "finalizing": 0,
                  "done": 5,
                  "failed": 0,
                  "total": 5
               },
               "stats": {
                  "number_of_files": 5,
                  "processed_files": 5,
                  "total_size_in_bytes": 1792,
                  "processed_size_in_bytes": 1792,
                  "start_time_in_millis": 1409663054859,
                  "time_in_millis": 64
               },
               "shards": {
                  "0": {
                     "stage": "DONE",
                     "stats": {
                        "number_of_files": 1,
                        "processed_files": 1,
                        "total_size_in_bytes": 514,
                        "processed_size_in_bytes": 514,
                        "start_time_in_millis": 1409663054862,
                        "time_in_millis": 22
                     }
                  },
                  ...

①実行中のスナップショットにIN_が表示されますPROGRESSをステータスとします.2この特定のスナップショットは、1つのスライスがまだ伝送されている(他の4つは完了している).応答には、スナップショットの全体的な状況が含まれますが、各インデックスと各スライスにドリルダウンする統計値も含まれます.これは、スナップショットの進行に関する非常に詳細なビューを示します.スライスは異なる完了状態で行うことができます:INITIALIZINGスライスはクラスタ状態をチェックして自分がスナップショットできるかどうかを確認します.これは普通とても速いです.STARTEDデータが倉庫に転送されています.FINALIZINGデータ転送完了;スライスはスナップショットメタデータを送信しています.DONEスナップショット完了!FAILEDスナップショット処理中にエラーが発生し、このスライス/インデックス/スナップショットが完了するはずがありません.ログをチェックして、より多くの情報を取得します.
参考:公式文書