백업 및 복원

스냅샷은 실행 중인 Elasticsearch 클러스터의 백업입니다. 스냅샷은 다음 용도로 사용할 수 있습니다:

다운타임 없이 클러스터를 정기적으로 백업
데이터 삭제나 하드웨어 장애 이후 데이터 복구
클러스터 간 데이터 이전
cold 및 frozen 데이터 티어에서 검색 가능한 스냅샷을 사용해 스토리지 비용 절감

중요

스냅샷은 데이터 이상의 것을 보존합니다. 사용 사례에 따라 ILM 정책, 인덱스 템플릿과 파이프라인, Kibana 저장된 객체, 알림 규칙, Fleet 설정과 통합, Elastic Security 데이터 등 Elastic Stack 기능의 구성과 내부 데이터도 함께 포함합니다.

데이터를 재색인하거나 다른 외부 소스에서 복구할 수 있더라도, 최소한 모든 Elasticsearch 시스템 인덱스와 클러스터 상태는 스냅샷으로 백업하는 것을 고려하세요. 이러한 백업이 없으면 재해 복구 상황에서 기반 데이터는 복원할 수 있더라도 스택 구성과 기능 상태를 잃을 수 있습니다.

Elasticsearch는 스냅샷 리포지토리라고 하는 클러스터 외부 스토리지 위치에 스냅샷을 저장합니다. 스냅샷을 생성하거나 복원하려면 먼저 클러스터에 스냅샷 리포지토리를 등록해야 합니다. Elasticsearch는 배포 유형에 따라 서로 다른 리포지토리 유형을 지원합니다:

스냅샷 리포지토리를 등록한 뒤에는 스냅샷 수명 주기 관리(SLM)를 사용해 스냅샷을 자동으로 생성하고 관리할 수 있습니다. 그런 다음 스냅샷을 복원해 데이터를 복구하거나 이전할 수 있습니다.

참고

스냅샷 관련 작업의 대부분은 모든 배포 유형에서 비슷하지만, Elastic Cloud Hosted, Elastic Cloud Enterprise(ECE), Elastic Cloud on Kubernetes(ECK)는 아래에 설명된 추가 기능을 제공합니다.

Elastic Cloud Hosted

Elastic Cloud Enterprise

Elastic Cloud on Kubernetes (ECK)

참고

스냅샷은 열린 인덱스만 백업합니다. 인덱스를 닫으면 스냅샷에 포함되지 않으며 해당 데이터를 복원할 수 없습니다.

기본적으로 클러스터의 스냅샷에는 클러스터 상태, 모든 일반 데이터 스트림, 모든 일반 인덱스가 포함됩니다. 클러스터 상태에는 다음이 포함됩니다:

클러스터의 특정 데이터 스트림이나 인덱스만 스냅샷으로 만들 수도 있습니다. 데이터 스트림이나 인덱스를 포함하는 스냅샷에는 해당 별칭도 자동으로 포함됩니다. 스냅샷을 복원할 때 이러한 별칭을 복원할지 여부를 선택할 수 있습니다.

스냅샷에 포함되지 않거나 백업되지 않는 항목은 다음과 같습니다:

임시(transient) 클러스터 설정
등록된 스냅샷 리포지토리
노드 구성 파일
보안 구성 파일

기능 상태에는 Elasticsearch 보안, Kibana, Fleet, Watcher 같은 Elastic 기능의 구성, 이력, 기타 데이터를 저장하는 데 사용되는 인덱스와 데이터 스트림이 들어 있습니다. 기능 상태 목록을 조회하려면 Features API를 사용하세요.

				GET /_features

기능 상태에는 일반적으로 하나 이상의 시스템 인덱스 또는 시스템 데이터 스트림이 포함됩니다. 해당 기능이 사용하는 일반 인덱스와 데이터 스트림도 포함될 수 있습니다. 예를 들어 기능 상태에는 해당 기능의 실행 이력이 담긴 일반 인덱스가 포함될 수 있습니다. 이 이력을 일반 인덱스에 저장하면 더 쉽게 검색할 수 있습니다.

Elasticsearch 8.0 이상 버전에서는 기능 상태가 시스템 인덱스와 시스템 데이터 스트림을 백업하고 복원하는 유일한 방법입니다. 기능 상태 외부에서 시스템 인덱스나 데이터 스트림을 복원하려고 시도하는 것은 허용되지 않으며 다음과 같은 오류가 발생합니다:

		requested system indices [.example], but system indices can only be restored as part of a feature state
		
	

시스템 인덱스와 데이터 스트림을 복원하려면 제한된 인덱스를 편집할 수 있는 임시 상승 권한이 필요합니다. 자세한 내용은 파일 기반 액세스 복구를 참조하세요. 필요한 임시 상승 권한 없이 시스템 인덱스나 데이터 스트림을 복원하려고 하면 다음과 같은 오류가 발생합니다:

Indices [.example] use and access is reserved for system operations

스냅샷은 스토리지 공간을 절약하고 네트워크 전송 비용을 줄이기 위해 자동으로 중복 제거됩니다. 인덱스를 백업할 때 스냅샷은 해당 인덱스의 세그먼트를 복사해 스냅샷 리포지토리에 저장합니다. 세그먼트는 불변이므로, 스냅샷은 리포지토리의 마지막 스냅샷 이후 생성된 새 세그먼트만 복사하면 됩니다.

각 스냅샷은 논리적으로 독립적입니다. 스냅샷을 삭제하면 Elasticsearch는 해당 스냅샷에서만 사용되는 세그먼트만 삭제합니다. 리포지토리의 다른 스냅샷이 사용하는 세그먼트는 삭제하지 않습니다.

스냅샷은 인덱스의 주 샤드에서 세그먼트를 복사합니다. 스냅샷을 시작하면 Elasticsearch는 사용 가능한 모든 주 샤드의 세그먼트를 즉시 복사하기 시작합니다. 샤드가 시작 중이거나 재배치 중이면 Elasticsearch는 이러한 과정이 완료될 때까지 기다린 후 해당 샤드의 세그먼트를 복사합니다. 하나 이상의 주 샤드를 사용할 수 없으면 스냅샷 시도가 실패합니다.

스냅샷이 샤드의 세그먼트 복사를 시작하면, 리밸런싱이나 샤드 할당 설정이 일반적으로 재할당을 유발하는 상황이더라도 Elasticsearch는 해당 샤드를 다른 노드로 이동하지 않습니다. Elasticsearch는 스냅샷이 해당 샤드의 데이터 복사를 마친 후에만 샤드를 이동합니다.

스냅샷은 특정 시점의 클러스터를 정확히 나타내지 않습니다. 대신 각 스냅샷에는 시작 시간과 종료 시간이 포함됩니다. 스냅샷은 이 두 시점 사이의 어느 시점에서의 각 샤드 데이터 뷰를 나타냅니다.

스냅샷을 클러스터에 복원하려면 스냅샷, 클러스터, 복원되는 모든 인덱스의 버전이 호환되어야 합니다.

스냅샷을 이전 버전의 Elasticsearch로 복원할 수는 없습니다. 예를 들어 7.6.0에서 생성한 스냅샷을 7.5.0을 실행 중인 클러스터로 복원할 수 없습니다.

스냅샷에서 복원하는 모든 인덱스는 현재 클러스터의 버전과도 호환되어야 합니다. 호환되지 않는 버전에서 생성된 인덱스를 복원하려고 하면 복원 시도가 실패합니다.

스냅샷 및 복원 과정에서의 인덱스 호환성은, Elasticsearch가 스냅샷에서 해당 인덱스와 데이터를 일반 인덱스로 또는 아카이브 인덱스를 통해 읽기 전용 형태로 복원할 수 있음을 의미합니다. 해당 데이터를 읽는 모든 애플리케이션이 대상 클러스터 버전에서 그 데이터를 유효한 것으로 취급한다는 뜻은 아닙니다.

직접 소유하고 관리하는 인덱스와 데이터 스트림의 경우, 호환되는 복원은 보통 데이터를 계속 사용할 수 있음을 의미합니다. Kibana 저장된 객체를 포함해 다른 기능이 자체 인덱스에 기록하는 데이터 등 Elastic Stack 기능 데이터의 경우, Elasticsearch 호환성이 버전 간 유효성을 보장하지는 않습니다. 이러한 애플리케이션은 Elastic Stack 버전에 따라 서로 다른 데이터 형식을 기대할 수 있으므로, Elasticsearch가 허용하는 복원이더라도 실패하거나 데이터가 사용할 수 없는 상태로 남을 수 있습니다.

스냅샷 복원은 직접 소유한 데이터를 복구하거나 이전하는 데 사용하세요. Elastic Stack 기능 업그레이드의 대체 수단으로 사용하지 마세요. Kibana와 기타 기능 상태에는 일반적인 업그레이드 경로를 따르세요.

다음 표는 특정 클러스터 버전으로 인덱스를 복원할 수 있는지 보여줍니다. 왼쪽 열에서 인덱스의 생성 버전을, 맨 위에서 클러스터 버전(복원 대상 버전)을 찾으세요. 예를 들어 6.8에서 생성된 인덱스는 9.0.0–9.5.1 클러스터로 복원할 수 있지만(✅), 7.0–7.1 클러스터로는 복원할 수 없습니다(❌).


	복원 대상 9.0.0–9.5.1	8.3–8.19	8.0–8.2	7.2–7.17	7.0–7.1	6.8
인덱스가 생성된 버전
5.0–5.6	✅ ¹	✅ ¹	❌	❌	❌	✅
6.0–6.7	✅ ¹	✅ ¹	❌	✅	✅	✅
6.8	✅ ¹	✅ ¹	❌	✅	❌	✅
7.0–7.1	✅ ^{1, 2}	✅	✅	✅	✅	❌
7.2–7.17	✅ ^{1, 2}	✅	✅	✅	❌	❌
8.0–8.19	✅	✅	✅	❌	❌	❌
9.0.0–9.5.1	✅	❌	❌	❌	❌	❌

¹ 아카이브 인덱스로 지원됩니다.

² 검색 가능한 스냅샷으로 지원됩니다.

인덱스를 이전 버전의 Elasticsearch로 복원할 수는 없습니다. 예를 들어 8.18.0에서 생성된 인덱스를 8.15.0을 실행 중인 클러스터로 복원할 수 없습니다.

호환되는 스냅샷에도 호환되지 않는 이전 버전에서 생성된 인덱스가 포함될 수 있습니다. 이러한 비호환 인덱스를 복원하려면 추가 절차가 필요합니다. 예를 들어 7.17 클러스터의 스냅샷에 6.8에서 생성된 인덱스가 포함되어 있을 수 있습니다. 이 6.8 인덱스를 8.18 클러스터로 복원하는 작업은 아카이브 기능을 사용하지 않으면 실패합니다. 7.17 인덱스를 9.0 클러스터로 복원하려면 아카이브 기능이나 검색 가능한 스냅샷을 사용할 수 있습니다. 클러스터를 업그레이드하기 전에 스냅샷을 생성할 때 이 점을 염두에 두세요.

인덱스 호환성을 확보하려면, 먼저 해당 인덱스와 현재 클러스터 양쪽 모두와 호환되는 최신 버전의 Elasticsearch를 실행 중인 다른 클러스터로 인덱스를 복원할 수 있습니다. 그런 다음 reindex-from-remote를 사용해 현재 클러스터에 인덱스를 다시 구성할 수 있습니다. 원격 재색인은 인덱스의 _source가 활성화되어 있는 경우에만 가능합니다.

원격 재색인은 스냅샷 복원보다 훨씬 오래 걸릴 수 있습니다. 시작하기 전에 데이터의 일부를 대상으로 원격 재색인 과정을 테스트해 소요 시간을 예측하세요.

Elasticsearch와 Kibana는 복원된 스냅샷에 서로 다른 호환성 규칙을 적용합니다. Elasticsearch가 허용한 복원이라도 Kibana가 시작될 때 실패할 수 있습니다.

Elasticsearch는 일반적으로 이전 주 버전에서 생성된 인덱스의 데이터를 읽을 수 있습니다. 예를 들어 8.1.0 클러스터의 스냅샷을 9.2.4 클러스터로 복원하는 작업은 Elasticsearch 계층에서는 성공할 수 있지만 Kibana 계층에서는 실패할 수 있습니다. 이는 Kibana가 시작 시 적용하는 추가 검사 때문일 수 있습니다. Kibana는 .kibana 인덱스의 버전 별칭을 검사하고 저장된 객체 마이그레이션을 실행합니다.

복원된 .kibana, .kibana_task_manager 같은 Kibana 시스템 인덱스가 8.18.0보다 오래된 버전에서 마지막으로 기록된 것이라면, Kibana 9.x는 마이그레이션을 시작하지 않고 다음과 유사한 오류를 보고합니다:

		FATAL  Error: Kibana 8.1.0 deployment detected. Please upgrade to Kibana 8.18.0 or newer before upgrading to 9.x series.
		
	

오래된 스냅샷을 9.x 클러스터로 바로 복원하는 것은 일반적인 업그레이드 경로를 우회하는 지름길이 아닙니다. 스냅샷을 사용해 클러스터 간에 데이터를 이전하는 경우에도, 주 버전 업그레이드 전에 호환되는 최신 마이너 릴리스로 업그레이드하는 것을 권장합니다.

이전 8.x 스냅샷의 Kibana 상태를 9.x 클러스터와 호환되게 만들려면, 먼저 중간 단계인 8.19.x 클러스터로 복원해 마이그레이션한 뒤, 그 중간 클러스터에서 스냅샷을 생성하고, 다시 대상 버전으로 복원하세요:

Kibana 8.19.x를 실행 중인 클러스터로 스냅샷을 복원합니다. 대상이 9.0.x라면 업그레이드 준비에 설명된 대로 8.18.x를 실행 중인 클러스터로 복원합니다.
중간 클러스터에서 Kibana를 시작하고 시작이 완료될 때까지 기다립니다. 시작 과정에서 Kibana는 이전의 호환 버전 데이터를 감지하고, Kibana 업그레이드 시와 유사하게 저장된 객체 마이그레이션을 실행합니다. 이 과정은 .kibana 시스템 인덱스를 복원된 버전(예: 8.1.0)에서 9.x와 완전히 호환되는 8.19.x 형식으로 다시 씁니다. Elasticsearch는 스냅샷 복원 중에 이러한 마이그레이션을 실행하지 않습니다.
마이그레이션된 클러스터의 새 스냅샷을 생성한 다음, 해당 스냅샷을 9.x 클러스터로 복원합니다. Kibana를 시작하고 시작이 완료될 때까지 기다립니다. 시작 과정에서 Kibana는 8.19.x에서 9.x로 업그레이드할 때와 마찬가지로 저장된 객체 마이그레이션을 실행합니다.

예를 들어 8.1.0 스냅샷의 Kibana 상태를 9.2.4 클러스터로 복원하려면, 8.1.0 스냅샷을 8.19.x 클러스터로 복원하고, Kibana가 시작 마이그레이션을 완료하도록 한 뒤, 8.19.x 클러스터의 스냅샷을 생성해 9.2.4로 복원하고, Kibana가 최신 데이터 마이그레이션을 수행하도록 합니다.

또는 데이터만 복구하면 되고 Kibana를 새로 설정해도 무방하다면, kibana 기능 상태를 제외하고 스냅샷을 복원하세요.

업그레이드 실패 후 롤백

주 버전 간 Kibana 구성 및 저장된 객체 이전에 설명된 절차는 Kibana 상태를 더 새로운 주 버전으로 이동시킵니다. 업그레이드 실패 후 롤백하는 데 이 절차를 사용하지 마세요.

Kibana를 롤백하려면, 실패한 업그레이드 직전에 생성한 스냅샷에서 kibana 기능 상태를 복원한 다음, 그 업그레이드 시도 이전에 실행 중이던 버전으로 Kibana를 시작하세요. 자세한 내용은 Kibana 롤백을 참조하세요.

스냅샷 생성은 클러스터를 백업하는 유일하게 신뢰할 수 있고 지원되는 방법입니다. 노드의 데이터 디렉터리를 복사하는 방식으로는 Elasticsearch 클러스터를 백업할 수 없습니다. 파일 시스템 수준 백업에서 데이터를 복원하는 지원되는 방법은 없습니다. 그런 백업으로 클러스터를 복원하려고 하면 손상, 파일 누락, 기타 데이터 불일치가 보고되며 실패하거나, 성공한 것처럼 보이면서 일부 데이터가 조용히 손실될 수 있습니다.

클러스터 노드의 데이터 디렉터리 복사본은 단일 시점의 내용을 일관되게 나타내지 않기 때문에 백업으로 동작하지 않습니다. 복사 중에 노드를 종료하거나 원자적 파일 시스템 수준 스냅샷을 사용해도 이 문제를 해결할 수 없는데, Elasticsearch에는 클러스터 전체에 걸친 일관성 요구 사항이 있기 때문입니다. 클러스터 백업에는 반드시 내장 스냅샷 기능을 사용해야 합니다.

리포지토리 내부의 어떤 것도 수정하지 말고, 그 내용에 간섭할 수 있는 프로세스를 실행하지 마세요. Elasticsearch가 아닌 다른 것이 리포지토리의 내용을 수정하면, 이후의 스냅샷이나 복원 작업이 손상 또는 기타 데이터 불일치를 보고하며 실패하거나, 성공한 것처럼 보이면서 일부 데이터가 조용히 손실될 수 있습니다.

다만 다음 조건을 지키면 백업에서 리포지토리를 복원하는 것은 안전합니다

리포지토리 내용을 복원하는 동안 해당 리포지토리가 Elasticsearch에 등록되어 있지 않아야 합니다.
리포지토리 복원을 마쳤을 때 그 내용이 백업 시점과 정확히 동일해야 합니다.

리포지토리의 스냅샷이 더 이상 필요하지 않다면, 기반 스토리지에서 내용을 삭제하기 전에 Elasticsearch에서 해당 리포지토리 등록을 해제하세요.

또한 스냅샷에는 보안에 민감한 정보가 포함될 수 있으므로, 전용 리포지토리에 저장하는 것이 좋습니다.