Snapshot Lifecycle Management(SLM) — 백업을 스케줄과 보존 정책으로 자동화
Elasticsearch Nested 타입 및 Snapshot Lifecycle Management 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(reference/elasticsearch/mapping-reference/nested, api/doc/elasticsearch/operation/operation-slm-put-lifecycle) Elastic 공식 문서 Create or update a policy(SLM)
이 모듈을 다 읽으면
- SLM이 수동 스냅샷 API 호출과 근본적으로 다른 지점(스케줄+보존 자동화)을 설명할 수 있다
- min_count가 expire_after보다 우선한다는 것의 실무적 의미를 설명할 수 있다
elasticsearch-learn-10에서 다룬 스냅샷의 증분 백업 원리를 전제로, 그 스냅샷을 사람이 수동으로 호출하는 대신 크론 기반 스케줄과 보존 정책에 따라 자동으로 만들고 지워주는 SLM(Snapshot Lifecycle Management)을 정리한다.
schedule — 크론 표현식으로 스냅샷 생성을 자동화
SLM 정책은 schedule 파라미터에 크론 표현식(<초> <분> <시> <일> <월> <요일> [연도])을 지정해, 정해진 주기 또는 특정 시점마다 자동으로 스냅샷을 생성한다 — elasticsearch-learn-10에서 다룬 수동 스냅샷 API 호출을 사람이 잊어버리거나 빼먹을 위험 자체를 없애는 방식이다.
핵심 포인트
- SLM 정책의 schedule은 크론 표현식으로 스냅샷 생성 주기를 자동화 — 수동 호출을 사람이 깜빡할 위험을 원천 제거
retention — expire_after/min_count/max_count의 상호작용
보존 정책은 세 파라미터로 구성된다 — expire_after는 스냅샷이 삭제 대상이 되는 나이(예: 30일)를 정하고, max_count는 나이와 무관하게 유지할 최대 스냅샷 개수 상한을 정한다. 핵심은 min_count가 expire_after보다 우선한다는 점이다 — min_count를 5로 설정했다면, 스냅샷이 5개뿐이고 전부 expire_after 기준을 넘겨 만료됐더라도 단 하나도 삭제되지 않는다. 즉 min_count는 '아무리 오래돼도 최소 이만큼은 반드시 남긴다'는 안전장치로 동작한다.
핵심 포인트
- expire_after(나이 기준 만료)/min_count(최소 보장 개수)/max_count(최대 개수 상한) 세 파라미터로 보존 정책 구성
- min_count가 expire_after보다 우선 — 스냅샷 수가 min_count 이하면 전부 만료돼도 삭제되지 않는 안전장치
max_count 초과 시 동작 — 최신 것부터 유지
저장소에 있는 스냅샷 수가 max_count를 초과하면, 아직 expire_after 기준으로 만료되지 않았더라도 정책은 가장 최근 스냅샷들을 유지하고 그보다 오래된 것부터 삭제한다 — 즉 max_count는 나이와 무관하게 '전체 개수'를 상한선으로 관리하는 별도의 축이다. 이 세 파라미터를 조합하면 관리자가 매번 수동으로 오래된 백업을 정리하지 않아도 일관된 보존 정책이 자동으로 유지된다.
핵심 포인트
- max_count 초과 시 아직 만료 안 됐어도 가장 오래된 스냅샷부터 삭제 — 나이가 아니라 '개수' 기준의 별도 축
- 세 파라미터 조합으로 관리자의 수동 개입 없이 일관된 보존 정책이 자동 유지됨