7-3-6. Backing Up Your Cluster

As with any software that stores data, it is important to routinely back up your data. Elasticsearch replicas provide high availability during runtime; they allow you to tolerate sporadic node loss without an interruption of service.

데이터를 저장하는 모든 S/W와 마찬가지로, 데이터를 정기적으로 백업하는 것은 중요하다. Elasticsearch의 replica는 실행 시간 동안 고 가용성을 제공하고, 서비스의 중단 없이, 돌발적인 node 손실을 극복할 수 있다.

Replicas do not provide protection from catastrophic failure, however. For that, you need a real backup of your cluster—a complete copy in case something goes wrong.

replica가 치명적인 오류를 막을 수는 없다. 그래서, cluster의 실제 백업(뭔가 잘못된 경우의 완벽한 복제본)이 필요하다.

To back up your cluster, you can use the snapshot API. This will take the current state and data in your cluster and save it to a shared repository. This backup process is "smart". Your first snapshot will be a complete copy of data, but all subsequent snapshots will save the delta between the existing snapshots and the new data. Data is incrementally added and deleted as you snapshot data over time. This means subsequent backups will be substantially faster since they are transmitting far less data.

cluster를 백업하기 위해, snapshot API를 사용할 수 있다. 이것은 cluster의 현재 상태와 데이터를 가져와, 공유 저장소(shared repository)에 저장한다. 이 백업 프로세스는 "smart" 하다. 첫 번째 snapshot은 데이터의 완벽한 복제본 이지만, 이후의 모든 snapshot은 기존의 shapshot과 새로운 데이터 사이의 증가분(delta) 을 저장한다. 데이터는 시간에 따라 snapshot으로, 점진적으로 추가되고 삭제된다. 즉, 이어지는 백업은 훨씬 적은 데이터를 전송하기 때문에, 대체로 더 빠르다.

To use this functionality, you must first create a repository to save data. There are several repository types that you may choose from:

이 기능을 쓰기 위해서, 먼저 데이터를 저장할 저장소를 만들어야 한다. 선택할 수 있는 몇 가지 저장소 형태가 있다.

• NAS 같은 Shared filesystem
• Amazon S3
• HDFS (Hadoop Distributed File System)
• Azure Cloud

Creating the Repositoryedit

Let’s set up a shared filesystem repository:

공유 filesystem 저장소를 설정하자.

PUT _snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup" 
    }
}

	저장소의 이름을 지정한다. 이 경우에는 my_backup
	저장소의 type이 공유 filesystem이 되도록 지정한다.
	그리고 마지막으로, 목적지로 mount된 drive를 지정한다.

The shared filesystem path must be accessible from all nodes in your cluster!

공유 filesystem 경로는 cluster의 모든 경로에서 액세스할 수 있어야 한다!

This will create the repository and required metadata at the mount point. There are also some other options that you may want to configure, depending on the performance profile of your nodes, network, and repository location:

이것은 mount 지점에 저장소와 필요한 metadata를 생성한다. node, 네트워크, 저장소 위치의 성능 프로파일에 따라, 구성할 수 있는, 몇 가지 다른 옵션이 있다.

max_snapshot_bytes_per_sec

When snapshotting data into the repo, this controls the throttling of that process. The default is 20mb per second.

저장소에 데이터의 snapshot을 생성하는 경우, 이것은 해당 프로세스의 조절을 제어한다. 기본값은 20mb/s 이다.

max_restore_bytes_per_sec

When restoring data from the repo, this controls how much the restore is throttled so that your network is not saturated. The default is 20mb per second.

저장소에서 데이터를 restore할 경우, 이것은 네트워크가 포화되지 않도록 하기 위해, restore를 얼마나 조절할지를 제어한다. 기본값은 20mb/s 이다.

Let’s assume we have a very fast network and are OK with extra traffic, so we can increase the defaults:

매우 빠른 네트워크를 가지고 있고, 추가 트래픽도 괜찮다고 가정한다면, 기본값을 증가시킬 수 있다.

POST _snapshot/my_backup/ 
{
    "type": "fs",
    "settings": {
        "location": "/mount/backups/my_backup",
        "max_snapshot_bytes_per_sec" : "50mb", 
        "max_restore_bytes_per_sec" : "50mb"
    }
}

	PUT 이 아닌 POST 를 사용해야 한다는 점을 기억하자. 이것은 기존 저장소의 설정을 업데이트한다.
	그 다음에 새로운 설정을 추가한다.

Snapshotting All Open Indicesedit

A repository can contain multiple snapshots. Each snapshot is associated with a certain set of indices (for example, all indices, some subset, or a single index). When creating a snapshot, you specify which indices you are interested in and give the snapshot a unique name.

저장소는 다수의 snapshot을 포함할 수 있다. 각 snapshot은 index의 특정 집합(예를 들자면, 모든 index, 일부 index의 집합, 단일 index 등)과 관련되어 있다. snapshot을 생성하는 경우, 관심있는 index와 snapshot의 고유한 이름을 지정해야 한다.

Let’s start with the most basic snapshot command:

가장 기본적인 snapshot 명령어로 시작해 보자.

PUT _snapshot/my_backup/snapshot_1

This will back up all open indices into a snapshot named snapshot_1, under the my_backuprepository. This call will return immediately, and the snapshot will proceed in the background.

이것은 my_backup 저장소에, snapshot_1 로 이름 붙여진 snapshot으로, 모든 index를 백업한다. 이 호출은 즉시 반환되고, snapshot은 background로 처리할 것이다.

Usually you’ll want your snapshots to proceed as a background process, but occasionally you may want to wait for completion in your script. This can be accomplished by adding a wait_for_completion flag:

일반적으로, snapshot은 background process로 처리되기를 원하겠지만, 경우에 따라, script에서 완료되기를 기다려야 할 수도 있다. 이 경우에는 wait_for_completion flag를 추가하여 수행할 수 있다.

PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true

This will block the call until the snapshot has completed. Note that large snapshots may take a long time to return!

이것은 snapshot이 완료될 때까지 호출을 블록(block)한다. 거대한 snapshot은 반환하는데 시간이 소요될 수 있다는 것을 기억하자.

Snapshotting Particular Indicesedit

The default behavior is to back up all open indices. But say you are using Marvel, and don’t really want to back up all the diagnostic .marvel indices. You just don’t have enough space to back up everything.

기본 동작은 열려있는 모든 index를 백업하는 것이다. 하지만, 진단용 .marvel index를 백업하지 않으려 한다. 모든 것을 백업할 공간이 없다.

In that case, you can specify which indices to back up when snapshotting your cluster:

이런 경우, cluster의 snapshot을 생성할 때, 백업할 index를 지정할 수 있다.

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

This snapshot command will now back up only index1 and index2.

이 snapshot 명령은 index1 과 index2 만을 백업한다.

Listing Information About Snapshotsedit

Once you start accumulating snapshots in your repository, you may forget the details relating to each—particularly when the snapshots are named based on time demarcations (for example, backup_2014_10_28).

저장소에 snapshot이 축적되기 시작하면, 각각과 관련된 상세 정보를 잊을 수 있다. 특히, snapshot을 시간으로 구분하여, 이름 붙인 경우에(예를 들어, backup_2014_10_28) 그럴 수 있다.

To obtain information about a single snapshot, simply issue a GET request against the repo and snapshot name:

단일 snapshot에 대한 정보를 얻기 위해, 간단하게 저장소와 snapshot의 이름으로 GET request를 실행하면 된다.

GET _snapshot/my_backup/snapshot_2

This will return a small response with various pieces of information regarding the snapshot:

이것은 snapshot에 대한 다양한 정보를 가진 조그마한 response를 반환한다.

{
   "snapshots": [
      {
         "snapshot": "snapshot_1",
         "indices": [
            ".marvel_2014_28_10",
            "index1",
            "index2"
         ],
         "state": "SUCCESS",
         "start_time": "2014-09-02T13:01:43.115Z",
         "start_time_in_millis": 1409662903115,
         "end_time": "2014-09-02T13:01:43.439Z",
         "end_time_in_millis": 1409662903439,
         "duration_in_millis": 324,
         "failures": [],
         "shards": {
            "total": 10,
            "failed": 0,
            "successful": 10
         }
      }
   ]
}

For a complete listing of all snapshots in a repository, use the _all placeholder instead of a snapshot name:

저장소에 있는 모든 snapshot의 완벽한 목록을 얻으려면, snapshot 이름 대신에 _all 을 사용하자.

GET _snapshot/my_backup/_all

Deleting Snapshotsedit

Finally, we need a command to delete old snapshots that are no longer useful. This is simply a DELETE HTTP call to the repo/snapshot name:

마지막으로, 더 이상 쓸모가 없는, 기존의 snapshot을 삭제할 명령어가 필요하다. 이것은 repo/snapshot 이름에 대한 간단한 DELETE HTTP 호출이다.

DELETE _snapshot/my_backup/snapshot_2

It is important to use the API to delete snapshots, and not some other mechanism (such as deleting by hand, or using automated cleanup tools on S3). Because snapshots are incremental, it is possible that many snapshots are relying on old segments. The delete API understands what data is still in use by more recent snapshots, and will delete only unused segments.

snapshot을 삭제하기 위해, 다른 메커니즘(수동으로 삭제하거나, S3 같은 자동 정리 도구 등)이 아닌, API를 사용하는 것은 중요하다. snapshot은 증분 백업이기 때문에, 많은 snapshot이 기존 segment에 의존할 수 있다. delete API는, 최근 snapshot에 의해 아직 사용중인, 데이터가 무엇인지를 알고, 사용되지 않는 segment만을 삭제한다.

If you do a manual file delete, however, you are at risk of seriously corrupting your backups because you are deleting data that is still in use.

그러나, 수동으로 파일을 삭제하면, 아직 사용 중인 데이터를 삭제했기 때문에, 백업에 심각한 손상을 입힐 위험이 있다.

Monitoring Snapshot Progressedit

The wait_for_completion flag provides a rudimentary form of monitoring, but really isn’t sufficient when snapshotting or restoring even moderately sized clusters.

wait_for_completion flag는 모니터링의 기본적인 형식을 제공하지만, snapshot을 생성하거나 적당한 크기의 cluster를 복원할 경우에는 충분하지 않다.

Two other APIs will give you more-detailed status about the state of the snapshotting. First you can execute a GET to the snapshot ID, just as we did earlier get information about a particular snapshot:

snapshot의 상태에 대한 더 자세한 상황를 제공하는 두 가지 다른 API가 있다. 먼저, 이전에 특정 snapshot에 대한 정보를 얻었을 때처럼, snapshot ID로 GET 을 실행할 수 있다.

GET _snapshot/my_backup/snapshot_3

If the snapshot is still in progress when you call this, you’ll see information about when it was started, how long it has been running, and so forth. Note, however, that this API uses the same threadpool as the snapshot mechanism. If you are snapshotting very large shards, the time between status updates can be quite large, since the API is competing for the same threadpool resources.

이것을 호출했을 때. snapshot이 여전히 진행 중이면, 시작 시간, 실행된 시간 등에 대한 정보를 얻을 수 있다. 그러나, 이 API는 snapshot 메커니즘과 동일한 threadpool을 사용한다는 점을 기억하자. 매우 큰 shard에 대한 snapshot을 생성하고 있다면, 상태 업데이트 사이의 시간이 매우 클 수 있다. 왜냐하면, API는 동일한 threadpool 자원을 두고 경쟁하기 때문이다.

A better option is to poll the _status API:

더 나은 옵션은 _status API를 폴링하는 것이다.

GET _snapshot/my_backup/snapshot_3/_status

The _status API returns immediately and gives a much more verbose output of statistics:

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
                     }
                  },
                  ...

	현재 실행되고 있는 snapshot은 그 상태를 IN_PROGRESS 로 나타낸다.
	이 snapshot은 하나의 shard가 아직 전송 중이다. 다른 4개는 이미 완료되었다.

The response includes the overall status of the snapshot, but also drills down into per-index and per-shard statistics. This gives you an incredibly detailed view of how the snapshot is progressing. Shards can be in various states of completion:

response는 snapshot에 대한 전체 상태를 표시할 뿐만 아니라, index 별, shard 별 통계를 보여준다. 이것은 snapshot의 진행 상태를 믿을 수 없을 만큼 자세하게 보여준다. shard는 다양한 완료 상태에 있을 수 있다.

INITIALIZING

The shard is checking with the cluster state to see whether it can be snapshotted. This is usually very fast.

shard는 snapshot을 생성할 수 있는지 알아보기 위해, cluster의 상태를 확인 중이다. 이것은 일반적으로 매우 빠르다.

STARTED

Data is being transferred to the repository.

데이터가 저장소로 전송되고 있다.

FINALIZING

Data transfer is complete; the shard is now sending snapshot metadata.

데이터 전송은 완료되었다. shard는 지금 snapshot metadata를 전송하고 있다.

DONE

Snapshot complete!

snapshot이 완료되었다!

FAILED

An error was encountered during the snapshot process, and this shard/index/snapshot could not be completed. Check your logs for more information.

snapshot process에서 에러가 발생하였다. 그리고, 이 shard/index/snapshot는 완료되지 못했다. 더 많은 정보는 로그를 참조하자.

Canceling a Snapshotedit

Finally, you may want to cancel a snapshot or restore. Since these are long-running processes, a typo or mistake when executing the operation could take a long time to resolve—and use up valuable resources at the same time.

마지막으로, snapshot의 생성이나 restore를 취소할 수 있다. 오랜 시간 진행되는 프로세스이기 때문에, 동작을 실행할 때 오타나 실수는 해석에 오랜 시간이 소요될 수 있다. 동시에 귀중한 자원을 소모한다.

To cancel a snapshot, simply delete the snapshot while it is in progress:

snapshot 생성을 취소하려면, 진행 중인 상태에서 단순하게 snapshot을 삭제하자.

DELETE _snapshot/my_backup/snapshot_3

This will halt the snapshot process. Then proceed to delete the half-completed snapshot from the repository.

이것은 snapshot 생성 프로세스를 중단시킨다. 그 다음에 저장소에서 아직 완료되지 않은 snapshot의 삭제를 진행한다.