7-3-7. Restoring from a Snapshot

Once you’ve backed up some data, restoring it is easy: simply add _restore to the ID of the snapshot you wish to restore into your cluster:

어떤 데이터를 백업했다면, restore은 매우 쉽다. 단순히, cluster에 restore하려는 snapshot의 ID에 _restore 를 추가하면 된다.

POST _snapshot/my_backup/snapshot_1/_restore

The default behavior is to restore all indices that exist in that snapshot. If snapshot_1 contains five indices, all five will be restored into our cluster. As with the snapshot API, it is possible to select which indices we want to restore.

기본 동작은 해당 snapshot에 존재하는 모든 index를 restore하는 것이다. snapshot_1 이 5개의 index를 포함하고 있다면, 모두 5개가 cluster에 restore될 것이다. snapshot API와 마찬가지로, restore하려는 index를 선택하는 것이 가능하다.

There are also additional options for renaming indices. This allows you to match index names with a pattern, and then provide a new name during the restore process. This is useful if you want to restore old data to verify its contents, or perform some other processing, without replacing existing data. Let’s restore a single index from the snapshot and provide a replacement name:

index 이름을 변경하는 추가 옵션도 있다. 이렇게 하면, index 이름과 패턴을 일치시켜, restore가 진행되는 동안 새로운 이름을 제공할 수 있다. 이것은 내용을 확인하거나, 어떤 다른 처리를 위해, 기존의 데이터를 교체하지 않고, 이전 데이터를 restore할 경우에 유용하다. snapshot에서 단일 index를 restore하고, 이름을 변경해 보자.

POST /_snapshot/my_backup/snapshot_1/_restore
{
    "indices": "index_1", 
    "rename_pattern": "index_(.+)", 
    "rename_replacement": "restored_index_$1" 
}

	snapshot에 존재하는 나머지는 무시하고, index_1 index만을 restore한다.
	제공한 패턴에 일치하는, restore될 index를 찾는다.
	대체 패턴으로 그들의 이름을 변경한다.

This will restore index_1 into your cluster, but rename it to restored_index_1.

이것은 index_1 을 cluster에 restore한다. 그러나, 이름을 restored_index_1 로 변경한다.

Similar to snapshotting, the restore command will return immediately, and the restoration process will happen in the background. If you would prefer your HTTP call to block until the restore is finished, simply add the wait_for_completion flag:

snapshot 생성과 유사하게, restore 명령은 즉시 반환되고, restore 과정은 background로 처리된다. restore가 완료될 때까지 블록(block)하기 위해, HTTP 호출을 하려면, 단순하게wait_for_completion flag를 추가하자.

POST _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true

Monitoring Restore Operationsedit

The restoration of data from a repository piggybacks on the existing recovery mechanisms already in place in Elasticsearch. Internally, recovering shards from a repository is identical to recovering from another node.

저장소 데이터의 restore는 이미 Elasticsearch에 있는 기존 복구 메커니즘에 편승한다. 내부적으로, 저장소에서 shard를 복구하는 것은 다른 node에서의 복구와 동일하다.

If you wish to monitor the progress of a restore, you can use the recovery API. This is a general-purpose API that shows the status of shards moving around your cluster.

restore 과정을 모니터링 할 경우에는, recovery API를 사용할 수 있다. 이것은 cluster를 이동하는 shard의 상태를 보여주는 범용 API이다.

The API can be invoked for the specific indices that you are recovering:

API는 복구 중인 특정 index에 대해 호출할 수 있다.

GET restored_index_3/_recovery

Or for all indices in your cluster, which may include other shards moving around, unrelated to your restore process:

또는, restore 프로세스와 관련이 없는, 이동하는 다른 shard를 포함한, cluster의 모든 index에 대해 호출할 수 있다.

GET /_recovery/

The output will look similar to this (and note, it can become very verbose depending on the activity of your cluster!):

출력은 다음과 유사하다. cluster의 활동에 따라 매우 자세한 정보가 될 수 있다는 점을 기억하자.

{
  "restored_index_3" : {
    "shards" : [ {
      "id" : 0,
      "type" : "snapshot", 
      "stage" : "index",
      "primary" : true,
      "start_time" : "2014-02-24T12:15:59.716",
      "stop_time" : 0,
      "total_time_in_millis" : 175576,
      "source" : { 
        "repository" : "my_backup",
        "snapshot" : "snapshot_3",
        "index" : "restored_index_3"
      },
      "target" : {
        "id" : "ryqJ5lO5S4-lSFbGntkEkg",
        "hostname" : "my.fqdn",
        "ip" : "10.0.1.7",
        "name" : "my_es_node"
      },
      "index" : {
        "files" : {
          "total" : 73,
          "reused" : 0,
          "recovered" : 69,
          "percent" : "94.5%" 
        },
        "bytes" : {
          "total" : 79063092,
          "reused" : 0,
          "recovered" : 68891939,
          "percent" : "87.1%"
        },
        "total_time_in_millis" : 0
      },
      "translog" : {
        "recovered" : 0,
        "total_time_in_millis" : 0
      },
      "start" : {
        "check_index_time" : 0,
        "total_time_in_millis" : 0
      }
    } ]
  }
}

	type field는 restore의 원본이다. 이 shard는 snapshot에서 restore되는 중이다.
	source 는 restore될 특정 snapshot과 저장소를 나타낸다.
	percent field는 restore의 상태에 대해 알려준다. 이 특정 shard는 지금까지 파일의 94%가 restore되었다. 거의 완료되었다.

The output will list all indices currently undergoing a recovery, and then list all shards in each of those indices. Each shard will have stats about start/stop time, duration, recover percentage, bytes transferred, and more.

출력은 현재 복구중인 모든 index를 나열하고, 해당 index 각각에서 모든 shard를 나열한다. 해당 shard 각각은 시작/정지 시간, 소요 시간, 복구 비율, 전송된 byte 등에 대한 통계를 가진다.

Canceling a Restoreedit

To cancel a restore, you need to delete the indices being restored. Because a restore process is really just shard recovery, issuing a delete-index API alters the cluster state, which will in turn halt recovery. For example:

restore을 취소하려면, restore하려는 index를 삭제해야 한다. restore 프로세스는 실제로 shard 복구이기 때문에, delete-index API 호출은 cluster의 상태를 변경한다. 이것이 결국 복구의 중단이다. 예를 들어

DELETE /restored_index_3

If restored_index_3 was actively being restored, this delete command would halt the restoration as well as deleting any data that had already been restored into the cluster.

restored_index_3 이 restore되는 경우, 이 delete 명령어는 이미 cluster에 restore 되었던 모든 데이터를 삭제할 뿐만 아니라, restore를 중단할 것이다.