Elasticsearch 입문 28편 — Snapshot & Restore (S3·SLM·Searchable Snapshot)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 28편이에요. 27편(Shard Allocation) 까지가 "샤드를 어느 노드에 어떻게 둘 것인가" 였다면, 이제부터는 "그 데이터를 어떻게 안전하게 백업하고 필요할 때 복원하는가" 자리예요. 운영자가 가장 늦게 신경 쓰다가 "새벽 3시에 한 번도 안 돌려 본 백업" 으로 회사를 잃는 자리가 바로 여기. Snapshot & Restore 가 ES 운영의 최후 보루 인 이유.

Replica 가 있어도 백업이 필요한 이유

ES 의 Replica = 1 만 둬도 데이터가 두 벌이라 노드 한 대 장애 는 막혀요. 그래서 신규 운영자가 "그럼 replica 가 곧 백업 아닌가" 하는 오해를 자주 합니다. Replica 는 동시 장애 한 대 까지의 고가용성 도구 일 뿐이고, 백업은 아니에요.

Replica 가 못 막는 자리가 셋이에요. 모든 노드 동시 다운 (AZ 전체 장애·power 차단), 논리 오류 (운영자가 DELETE /my-index 를 잘못 실행 · 앱이 잘못된 update 를 대량 전송), 데이터 손상 (랜섬웨어 · 디스크 부분 손상이 replica 까지 동기 전파). 이 셋 중 어느 하나가 들어와도 replica 만으로는 복구 불가.

Snapshot 은 ES 클러스터 바깥의 외부 저장소 에 데이터를 시점 단위 로 떠 두는 도구예요. 논리적 백업 이 아니라 Lucene segment 파일을 물리적으로 복사 해서 증분(incremental) 방식으로 쌓아요. 한 번 운영 표준으로 박아 두면 논리 오류 · 클러스터 전체 손상 · 데이터센터 단위 사고 까지 복구 옵션이 살아납니다.

이 글은 Repository → Snapshot → Restore → SLM 자동화 → Searchable Snapshot 다섯 도구를 한 호흡에 묶어, 백업·복원이 표준 운영 프로세스 가 되는 구성까지 풀어 봅니다.

Repository — Snapshot 저장소 추상화

ES 의 백업이 동작하려면 가장 먼저 어디에 떠 둘지 가 정의돼야 해요. 그 어디 를 ES 는 Repository 라는 추상으로 다루는데, 한 번 등록해 두면 그 뒤로 snapshot 명령은 어떤 저장소든 같은 API 로 작동.

운영에서 가장 자주 만나는 자리가 S3 · GCS · Azure 셋이에요. 한국 회사는 AWS S3 또는 MinIO (S3 호환 자체 운영) 이 압도적이고, 둘 다 repository-s3 한 플러그인으로 다 잡혀요.

# S3 repository 등록 (AWS S3)
PUT /_snapshot/my_s3_repo
{
  "type": "s3",
  "settings": {
    "bucket": "my-es-backup",
    "region": "ap-northeast-2",
    "base_path": "production-cluster",
    "compress": true,
    "chunk_size": "1gb",
    "server_side_encryption": true
  }
}

base_path 는 한 버킷 안에서 클러스터별로 디렉토리 분리 하는 키. 여러 클러스터가 한 버킷을 공유할 때 필수예요. chunk_size 는 한 segment 파일을 S3 에 올릴 때 분할 단위 — 1GB 가 일반.

S3 자격 증명 은 보통 노드의 IAM Role (EC2 · EKS Service Account) 로 처리해요. ES 키스토어에 직접 access key 를 박는 것도 가능하지만, 키 회전이 까다로워서 비추천. 운영 환경에서 가장 자주 만나는 사고가 S3 IAM 권한 누락 이라 한 번 정리하고 넘어가요.

# S3 IAM 정책 최소 필수 권한 (ES 8.x snapshot 용)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": "arn:aws:s3:::my-es-backup"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload"
      ],
      "Resource": "arn:aws:s3:::my-es-backup/*"
    }
  ]
}

이 7개 액션이 빠지면 "AccessDenied" 가 떨어지고 snapshot 이 PARTIAL · FAILED 상태로 끝나요. 등록 직후 반드시 verify 를 한 번 돌려 권한을 점검.

# repository 등록 검증
POST /_snapshot/my_s3_repo/_verify
{
  "nodes": {
    "node-1": { "name": "data-1" },
    "node-2": { "name": "data-2" }
  }
}

이 호출이 모든 data 노드에서 S3 에 write 시도 → 결과 회신 을 수행해서, 한 노드만 권한이 빠져도 즉시 잡혀요. 권한 점검은 repository 등록 직후 1회 · IAM 정책 변경 후 매번 이 표준.

Shared FS 는 모든 마스터·데이터 노드 에 같은 경로 로 마운트된 공유 디스크여야 해요. NFS 한 곳만 빠뜨려도 snapshot 이 PARTIAL 로 끝납니다. 클라우드 환경이면 S3·GCS 가 압도적으로 안전한 선택.

Snapshot API — 생성·조회·삭제·증분 메커니즘

Repository 가 등록됐으면 그 다음은 snapshot 자체 의 생성·관리예요. 핵심 API 셋만 외워 두면 90% 가 잡혀요.

# 1) snapshot 생성 (전체 인덱스)
PUT /_snapshot/my_s3_repo/snap_2026_05_19_0300
{
  "indices": "*",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "ops-cron",
    "purpose": "nightly-backup"
  }
}

indices: "*" 는 모든 사용자 인덱스. .security · .kibana 같은 시스템 인덱스를 같이 뜨려면 include_global_state: true 와 묶어 가야 해요. ignore_unavailable: true 는 snapshot 도중 인덱스가 삭제·접근 불가 가 돼도 작업이 멈추지 않게 — 운영에선 거의 항상 true.

metadata 는 자유 형식 태그. 누가 · 왜 · 어떤 환경에서 떴는지 박아 두면 몇 달 뒤 어떤 snapshot 부터 복원할지 선택할 때 큰 도움.

# 2) 비동기 vs 동기 (wait_for_completion)
PUT /_snapshot/my_s3_repo/snap_2026_05_19_0300?wait_for_completion=true
{ ... }

기본은 비동기 — 요청 즉시 200 반환, 백그라운드에서 진행. wait_for_completion=true 면 완료까지 블로킹. 운영 스크립트는 보통 비동기로 시작 → polling 으로 완료 확인 패턴이 안전해요. wait 으로 블로킹하면 snapshot 이 1시간 이상 걸리는 큰 클러스터 에서 HTTP timeout 이 떨어져요.

# 3) snapshot 상태 조회
GET /_snapshot/my_s3_repo/snap_2026_05_19_0300

{
  "snapshots": [{
    "snapshot": "snap_2026_05_19_0300",
    "uuid": "a9b8c7d6...",
    "version": "8.13.0",
    "indices": ["products", "orders", "users"],
    "state": "SUCCESS",
    "start_time_in_millis": 1747627200000,
    "end_time_in_millis": 1747629000000,
    "duration_in_millis": 1800000,
    "shards": {
      "total": 30,
      "successful": 30,
      "failed": 0
    }
  }]
}

state 가 핵심. IN_PROGRESS · SUCCESS · PARTIAL · FAILED · INCOMPATIBLE 다섯 가지. PARTIAL 은 일부 샤드만 성공 — 가장 자주 만나는 경고 상태고, 보통 접근 불가 샤드 · 권한 누락 · 디스크 가득 셋 중 하나가 원인. PARTIAL 은 백업으로 인정 X 라고 외워 두면 안전.

# 4) snapshot 진행률 (큰 snapshot 모니터링)
GET /_snapshot/my_s3_repo/snap_2026_05_19_0300/_status

이 API 는 바이트 단위 진행률·노드별 처리량 까지 보여 줘서 왜 snapshot 이 느리지 진단에 핵심.

# 5) snapshot 삭제
DELETE /_snapshot/my_s3_repo/snap_2026_05_19_0300

여기서 ES 의 증분(incremental) 메커니즘 이 자주 헷갈리니까 한 번 정리. ES snapshot 은 Lucene segment 단위 로 떠요. 어제 snapshot 에 포함된 segment 가 오늘도 같은 내용이면 재업로드 X · 참조만 추가. 그래서 2번째 snapshot 부터는 변경된 segment 만 새로 올라가 시간·비용이 1차보다 크게 줄어요.

중요한 점 — 어제 snapshot 을 지워도 오늘 snapshot 이 무사 합니다. ES 가 어떤 segment 가 어느 snapshot 들에서 참조 중인지 추적해서, 마지막 참조가 사라질 때만 S3 에서 실제 파일 삭제. 일반 파일 시스템의 hard link · reference count 와 같은 메커니즘이에요. 그래서 오래된 snapshot 을 안심하고 지워도 최근 snapshot 이 깨지지 않아요.

Restore — 복원의 4가지 옵션

Snapshot 떠 두는 건 절반의 작업이고, 진짜 시험 은 복원에서 와요. 복원 옵션을 미리 알아 두면 원본 클러스터 옆에 검증용 임시 인덱스로 복원 같은 안전 패턴이 가능해져요.

# 기본 복원 — 모든 인덱스를 원래 이름으로
POST /_snapshot/my_s3_repo/snap_2026_05_19_0300/_restore
{
  "indices": "*",
  "ignore_unavailable": true,
  "include_global_state": false
}

이렇게 그냥 부르면 snapshot 안의 모든 인덱스를 원래 이름으로 클러스터에 띄워요. 그런데 원래 이름의 인덱스가 이미 존재 하면 에러. 운영에서 자주 만나는 게 "기존 데이터 보존 + snapshot 데이터를 옆에 복원해서 비교" 자리라, rename 옵션이 거의 필수예요.

# 옵션 1 — 이름 바꿔서 복원 (rename_pattern · rename_replacement)
POST /_snapshot/my_s3_repo/snap_2026_05_19_0300/_restore
{
  "indices": "products,orders",
  "rename_pattern": "(.+)",
  "rename_replacement": "restored_$1",
  "include_global_state": false,
  "include_aliases": false
}

rename_pattern 은 정규식 캡처 그룹, rename_replacement 는 치환 패턴. 위 예시는 products → restored_products 로 와요. 원본은 그대로 두고 옆에 별도 인덱스로 복원 해서 데이터 비교 후 alias 스왑 하는 zero-downtime 복원 패턴의 핵심.

include_aliases: false 는 snapshot 안의 alias 를 그대로 복원 X — alias 가 원본·복원본 양쪽에 동시 에 붙으면 검색이 양쪽에서 결과가 섞이니까 거의 항상 false 가 안전.

# 옵션 2 — 일부 인덱스만 복원 (indices)
POST /_snapshot/my_s3_repo/snap_2026_05_19_0300/_restore
{
  "indices": "products,orders-2026-05-*",
  "ignore_unavailable": true,
  "include_global_state": false
}

indices 는 쉼표 + 와일드카드 + 패턴 모두 OK. ILM 으로 날짜별 인덱스 가 쌓이는 환경이면 "5월 데이터만 복원" 같은 범위가 가능.

# 옵션 3 — 글로벌 상태까지 복원 (include_global_state)
POST /_snapshot/my_s3_repo/snap_2026_05_19_0300/_restore
{
  "indices": "*",
  "include_global_state": true
}

include_global_state: true 는 클러스터 설정 · index template · ingest pipeline · ILM policy · SLM policy 까지 같이 복원. 새 클러스터에 처음 셋업 할 때 유용하지만, 기존 운영 클러스터에 부으면 클러스터 전체 설정이 덮어써져 사고가 큽니다. 운영 복원은 거의 항상 false.

# 옵션 4 — 인덱스 설정 일부 무시 (ignore_index_settings)
POST /_snapshot/my_s3_repo/snap_2026_05_19_0300/_restore
{
  "indices": "products",
  "index_settings": {
    "index.number_of_replicas": 0,
    "index.refresh_interval": "60s"
  },
  "ignore_index_settings": [
    "index.routing.allocation.require._tier_preference"
  ]
}

index_settings 는 복원 시점에 설정을 덮어쓰기, ignore_index_settings 는 snapshot 안의 일부 설정을 무시. Cold/Frozen tier 가 없는 새 클러스터로 복원 할 때 _tier_preference 무시는 거의 필수예요. 없으면 그 tier 노드를 찾다가 unassigned 가 돼서 yellow/red 가 길어집니다.

복원 진행 모니터링 은 _recovery API 가 핵심.

GET /_recovery?active_only=true
{
  "products": {
    "shards": [{
      "id": 0,
      "type": "SNAPSHOT",
      "stage": "INDEX",
      "primary": true,
      "index": {
        "size": {
          "total_in_bytes": 5368709120,
          "recovered_in_bytes": 2147483648,
          "percent": "40.0%"
        }
      }
    }]
  }
}

stage 가 INIT · INDEX · TRANSLOG · FINALIZE · DONE 다섯 단계로 진행돼요. 큰 인덱스 복원은 수십 분~수 시간 이라 monitoring 대시보드에 항상 박아 두는 게 안전.

SLM — Snapshot Lifecycle Management 자동화

손으로 매일 snapshot 을 뜨고 retention 을 관리하면 언젠가 빼먹어서 사고가 나요. 그 자리를 ES 가 자동으로 잡아 주는 도구가 SLM (Snapshot Lifecycle Management) 입니다. 운영 클러스터의 백업 cron 을 클러스터 안에서 굴리는 방식.

# SLM 정책 생성
PUT /_slm/policy/nightly-backup
{
  "schedule": "0 30 1 * * ?",
  "name": "<nightly-snap-{now/d}>",
  "repository": "my_s3_repo",
  "config": {
    "indices": ["*"],
    "ignore_unavailable": true,
    "include_global_state": false,
    "partial": false
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 7,
    "max_count": 50
  }
}

schedule 은 Cron 7-field 형식 (초·분·시·일·월·요일·연도). 위 예시는 매일 새벽 1시 30분 에 실행. ES 의 cron 은 클러스터 시간대(cluster.routing.allocation.awareness.attributes 와 별개로 JVM TZ) 기준이라, 한국 운영이면 Asia/Seoul 인지 UTC 인지를 한 번 확인하고 박는 게 안전.

name 은 snapshot 이름 템플릿. <...{now/d}> 는 날짜 단위로 굳히는 표현이라 nightly-snap-2026.05.19-xxxxxx 같은 이름이 자동 생성. 같은 시점에 중복 실행돼도 충돌 X.

retention 이 SLM 의 가장 중요한 부분. 세 설정의 의미를 정확히 알고 가야 사고 2(retention 미설정) 가 막혀요.

세 조건이 동시에 적용 돼요. 예를 들어 expire_after=30d · min_count=7 · max_count=50 이면:

• 31일 지난 snapshot 이라도 최근 snapshot 이 7개 미만이면 삭제 X. → 백업 작업이 며칠 멈춰도 복구할 백업이 7개 남음.
• snapshot 수가 50개 넘으면 expire_after 안 지났어도 오래된 것부터 삭제. → S3 비용 폭증 방지.

# SLM 정책 즉시 실행 (테스트용)
POST /_slm/policy/nightly-backup/_execute

# SLM 실행 이력
GET /_slm/policy/nightly-backup
{
  "nightly-backup": {
    "version": 1,
    "modified_date_millis": 1747600000000,
    "policy": { ... },
    "last_success": {
      "snapshot_name": "nightly-snap-2026.05.19-xxxxxx",
      "start_time": 1747627800000,
      "time": 1747629000000
    },
    "last_failure": null,
    "stats": {
      "snapshots_taken": 30,
      "snapshots_failed": 0,
      "snapshots_deleted": 0,
      "snapshot_deletion_failures": 0
    }
  }
}

last_failure 가 null 이 아니라면 즉시 알람으로 묶어야 해요. 운영 체크리스트에 SLM last_failure 모니터링 한 줄이 백업 자산의 90% 를 지켜 줍니다.

SLM 권한 관리 는 30편(Security) 에서 깊이 가지만, 백업 전용 role (manage_slm · cluster:admin/snapshot/*) 을 만들어 백업 cron 만 그 role 로 작동하는 게 표준. 일반 운영자 계정에 백업 권한을 박지 X.

Searchable Snapshot — S3 직접 검색하는 Cold/Frozen Tier

ES 8.x 에서 가장 큰 비용 게임 체인저 가 Searchable Snapshot 이에요. 이름은 snapshot 의 일종 같지만 실제는 별도의 데이터 tier 와 결합한 새 인덱스 형태. 한 번 이해해 두면 오래된 로그·시계열 데이터의 S3 비용 절감 자리에서 압도적입니다.

전통적 ILM 의 Hot → Warm → Cold tier 는 모두 로컬 디스크에 데이터 사본을 들고 있어요 (16편 ILM 참조). Cold tier 는 replica 0 + 압축 으로 비용을 줄여도 원본 데이터가 SSD/HDD 에 있어야 검색이 돼서, 데이터가 PB 단위로 쌓이면 디스크 비용 자체가 문제.

Searchable Snapshot 은 그 자리를 풀어요. 데이터를 S3 에만 두고, 검색이 들어올 때만 필요한 segment 를 S3 에서 fetch 해 검색해요. 로컬 디스크는 캐시만 들고, 캐시가 비면 S3 에서 lazy load. S3 가 주 저장소 가 되고 노드 디스크는 읽기 가속용 캐시 로 역할이 바뀌어요.

# 1) 일반 snapshot 을 먼저 떠둠
PUT /_snapshot/my_s3_repo/cold_snap_2026_05
{
  "indices": "logs-2025-*",
  "include_global_state": false
}

# 2) Searchable Snapshot 으로 mount
POST /_snapshot/my_s3_repo/cold_snap_2026_05/_mount?storage=full_copy
{
  "index": "logs-2025-01",
  "renamed_index": "logs-2025-01-cold",
  "index_settings": {
    "index.number_of_replicas": 0
  }
}

storage 옵션이 핵심. full_copy 는 S3 + 로컬 전체 복사 (Cold tier 와 비슷), shared_cache 는 S3 만 두고 로컬 캐시 (Frozen tier). 후자가 비용 절감 최대.

Frozen tier 는 수 년치 로그·감사 데이터 자리에 디스크 비용을 90% 이상 절감 시켜요. 검색이 들어오는 비율이 1% 미만 이고 검색 응답이 초 단위라도 OK 인 자리에 가장 효과가 큰 자리.

ILM 정책에 묶어 두면 Hot 30일 → Warm 60일 → Cold 90일 → Frozen 365일 → Delete 같은 자동 흐름이 가능. 16편(ILM) 의 cold·frozen phase 가 바로 이 메커니즘과 연결돼요.

# ILM 정책에 searchable snapshot 추가
PUT /_ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot":   { "actions": { "rollover": { "max_age": "30d" } } },
      "cold":  {
        "min_age": "90d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_s3_repo",
            "force_merge_index": true
          }
        }
      },
      "frozen": {
        "min_age": "365d",
        "actions": {
          "searchable_snapshot": {
            "snapshot_repository": "my_s3_repo",
            "storage": "shared_cache"
          }
        }
      },
      "delete": { "min_age": "1825d", "actions": { "delete": {} } }
    }
  }
}

이 한 정책이 5년치 로그 를 비용 효율 로 굴리는 표준 패턴이에요. Searchable Snapshot 자체에는 Enterprise 라이선스가 필요 합니다 (8.x 기준). OpenSearch 진영은 UltraWarm·Cold Storage 라는 다른 이름의 비슷한 기능을 AWS OpenSearch Service 에 한정 해서 제공해요.

Restore 전 검증 — verify_repository · _status

복원은 진짜 사고 한가운데에서 처음 돌려 보는 작업이면 거의 실패해요. 주기적으로 테스트 환경에 복원 해 snapshot 이 살아 있는지 검증하는 게 운영의 핵심. 두 도구가 있어요.

# 1) Repository 자체 점검 (read·write)
POST /_snapshot/my_s3_repo/_verify

repository 등록 직후 한 번, IAM 변경 후 매번, 분기 정기 점검 으로 한 번 — 이렇게 세 시점에 돌리는 게 표준이에요.

# 2) Snapshot 무결성 점검 (8.10+ 추가됨)
POST /_snapshot/my_s3_repo/_analyze?blob_count=10&concurrency=2

_analyze 는 S3 가 ES 가 기대하는 동작 규칙을 정확히 따르는지 점검해요. eventual consistency · multipart upload abort · 동시 쓰기 같은 S3 호환 저장소(MinIO·Ceph) 의 잘못된 구현 을 잡아 줘요. MinIO 운영이면 반드시 분기 1회 돌려 두기.

# 3) snapshot 자체 무결성 (메타데이터 점검)
GET /_snapshot/my_s3_repo/snap_2026_05_19_0300/_status
{
  "snapshots": [{
    "snapshot": "snap_2026_05_19_0300",
    "state": "SUCCESS",
    "stats": {
      "incremental": { "file_count": 120, "size_in_bytes": 1073741824 },
      "total":       { "file_count": 3500, "size_in_bytes": 53687091200 },
      "start_time_in_millis": 1747627200000,
      "time_in_millis": 1800000
    },
    "indices": { ... }
  }]
}

incremental.file_count 와 total.file_count 의 차이 — 증분만 새로 올린 파일 수 vs 총 참조 파일 수. 운영 monitoring 으로 incremental 이 0 가까이 면 변경이 거의 없는 평화로운 날, incremental 이 total 의 50% 이상 이면 대량 reindex 같은 이벤트 가 있었던 날 신호.

최종 검증 은 실제 복원 까지 해 봐야 정확해요. 분기 1회 · 별도 검증 클러스터 로 최근 snapshot 1개 를 복원해 문서 갯수·샘플 검색 결과 가 원본과 일치하는지 점검. 이걸 한 번도 안 돌리면 진짜 사고 때 처음으로 복원 절차를 굴리는 최악의 시나리오 가 들어와요.

자주 만나는 사고 7가지

사고 1 — S3 IAM 권한 누락

원인 — repository-s3 등록은 됐는데 IAM 정책에 s3:AbortMultipartUpload 가 빠져 있으면, 큰 인덱스 snapshot 도중 multipart upload 가 cancel 되지 못해 PARTIAL 또는 FAILED 로 끝나요. 또는 s3:ListBucket 누락으로 snapshot 목록 조회 자체가 거부.

해결 — 본문에 정리한 7개 액션 최소 권한 을 정확히 박고, 등록 직후 POST /_snapshot/my_s3_repo/_verify 로 모든 데이터 노드에서 권한 점검. IAM 변경 후에는 반드시 다시 verify.

사고 2 — SLM Retention 미설정

원인 — SLM 정책을 짤 때 retention 블록을 빠뜨리면 snapshot 이 영원히 쌓여 S3 비용이 폭증해요. 3개월 운영 → 매일 1개 → 90개 누적 → 각 1TB → 90TB 청구 가 실제 사례.

해결 — 모든 SLM 정책에 retention 블록 필수. expire_after · min_count · max_count 세 키 모두 박기. 운영 시작 전에 S3 라이프사이클 정책 (예: 90일 후 Glacier 이동) 도 같이 박아 두면 비용 안전망이 이중.

사고 3 — Snapshot 도중 마스터 변경

원인 — Snapshot 작업은 마스터 노드가 조정 하는데, 작업 중 마스터가 GC pause · 네트워크 끊김 으로 재선출되면 진행 중 snapshot 이 상태 동기화 실패 로 PARTIAL · INCOMPATIBLE 이 될 수 있어요.

해결 — 26편(Cluster Operations) 의 Master 전용 노드 분리 · 작은 힙 8~16GB 패턴을 적용. SLM 스케줄은 클러스터 부하가 낮은 시간 (한국 시간 새벽 1~3시) 에 박아 마스터 안정성 확보. snapshot 도중 다른 운영 작업 금지 가 표준.

사고 4 — Restore 시 Mapping 충돌

원인 — snapshot 시점의 mapping 과 현재 클러스터의 인덱스 template · component template 이 다르면, 복원된 인덱스가 새 template 을 자동 적용 받아 예상과 다른 mapping 으로 떠요. 8편(Mapping Deep) 에서 다룬 Mapping Explosion 이 복원 직후 발생하는 사고.

해결 — 복원 전 index_settings · ignore_index_settings 로 template 자동 적용을 차단. index.lifecycle.name · index.routing.allocation.require._tier_preference 같은 환경 의존 설정 은 거의 항상 ignore 가 안전.

사고 5 — Incremental Chain 깨짐

원인 — Repository S3 버킷의 외부 직접 수정 (수동 파일 삭제 · 잘못된 라이프사이클 적용) 으로 snapshot 이 참조하는 segment 파일이 없어지면, 그 이후 모든 snapshot 이 INCOMPATIBLE · 복원 불가 상태가 돼요.

해결 — Repository S3 버킷은 ES 외에 누구도 직접 수정 X. S3 라이프사이클 정책을 박더라도 base_path 하위는 제외 하는 게 안전. 분기 1회 POST /_snapshot/my_s3_repo/_analyze 로 무결성 점검.

사고 6 — Searchable Snapshot Tier 노드 부재로 복원 실패

원인 — Frozen tier 의 searchable snapshot 을 Frozen 노드가 없는 새 클러스터 로 복원하면 _tier_preference: data_frozen 때문에 할당 가능 노드 X · 영구 unassigned 가 떨어져요.

해결 — 복원 시 ignore_index_settings: ["index.routing.allocation.require._tier_preference", "index.routing.allocation.include._tier_preference"] 로 tier 강제 우선순위 를 무시. 또는 새 클러스터에 최소 1대의 frozen 노드 (또는 통합 노드) 를 추가해 정상 매핑.

사고 7 — 백업은 있지만 복원 한 번도 안 함

원인 — SLM 으로 매일 백업은 잘 돼서 snapshot 100개가 S3 에 쌓였는데, 진짜 사고가 났을 때 복원을 처음 돌려 보면 권한 누락 · template 충돌 · 디스크 부족 · 절차 미숙 으로 예상보다 10배 오래 걸려 RTO 실패.

해결 — 분기 1회 검증 복원 을 운영 표준에 박기. 별도 검증 클러스터 또는 원본 클러스터에 rename_pattern 으로 옆에 복원 후 문서 수·샘플 검색 결과 비교. 복원 절차서 (runbook) 를 문서화해 사람이 매번 같은 순서 로 실행하도록 만들어요.

운영 권장 패턴 5가지

Repository 는 클러스터별 + 환경별로 분리 합니다. production cluster A → bucket1 · staging cluster A → bucket2 처럼 base_path 또는 버킷 자체를 나눠, 환경 간 snapshot 혼합 사고 를 차단. 한 버킷 공유는 비용·관리 측면에서 편하지만 staging snapshot 을 production 에 복원 같은 사고의 빌미가 돼요.

SLM 정책은 최소 2개 (nightly + weekly) 운영 으로 가져가요. nightly 는 retention 30일·매일 1개, weekly 는 retention 365일·일요일 1개. 일일 작업 실수로 최근 백업이 다 망가져도 주간 백업이 1년 치 안전망 으로 남아요. 비용은 incremental 메커니즘 덕에 1.5배 안쪽.

복원 검증은 분기 1회 표준 작업 으로 박아 두세요. 가장 효과적인 방법은 production snapshot → staging cluster 로 복원 → 문서 수·검색 결과 자동 비교 스크립트. 분기 1회면 백업이 살아 있는지 + 절차 숙련도 둘 다 함께 확인되는 자산.

Searchable Snapshot 은 ILM 과 묶어 가는 게 표준이에요. Hot → Warm → Cold → Frozen → Delete 흐름을 ILM 정책 1개 에 박아 두면, 운영자가 수동 mount 를 칠 일이 거의 없어져요. Enterprise 라이선스 가 부담이면 Cold tier (full_copy) 만 써도 디스크 비용의 30% 정도는 절감.

Repository 무결성 점검 은 _verify (분기 1회) + _analyze (반기 1회) 로 묶어 자동화합니다. MinIO·Ceph 같은 S3 호환 저장소 는 eventual consistency 동작 이 조금씩 다를 수 있어 _analyze 가 조용한 비호환 을 잡아 줘요. AWS S3 라도 region 변경·버킷 정책 변경 후에는 한 번 돌리는 게 안전.

시험 직전 한 번 더 — 압축 노트

• Replica = HA 도구, 백업 아님. 논리 오류·동시 장애·랜섬웨어 못 막음.
• Snapshot = 외부 저장소에 Lucene segment 단위 로 떠 두는 물리적 증분 백업.
• Repository 종류 = S3 · GCS · Azure · HDFS · Shared FS · URL(읽기). 운영은 S3 (또는 GCS·Azure) 가 표준.
• S3 IAM 최소 권한 = ListBucket · GetBucketLocation · ListBucketMultipartUploads · GetObject · PutObject · DeleteObject · AbortMultipartUpload 7개.
• Repository 등록 후 반드시 POST /_snapshot/{repo}/_verify 로 권한 점검.
• Snapshot 상태 = IN_PROGRESS · SUCCESS · PARTIAL · FAILED · INCOMPATIBLE. PARTIAL 은 백업으로 인정 X.
• 증분 메커니즘 — segment 단위 참조 카운트. 옛 snapshot 지워도 새 snapshot 무사.
• Restore 옵션 핵심 = rename_pattern · rename_replacement · ignore_index_settings · include_global_state(거의 false).
• 복원 모니터링 = _recovery?active_only=true. stage INIT → INDEX → TRANSLOG → FINALIZE → DONE.
• SLM = 클러스터 내부 백업 cron. schedule · name · repository · config · retention 5블록 필수.
• SLM retention = expire_after · min_count · max_count 세 키 동시 적용. 빠뜨리면 비용 폭증.
• Searchable Snapshot = S3 직접 검색하는 새 인덱스 형태. full_copy (Cold) · shared_cache (Frozen). Enterprise 라이선스.
• ILM 정책 = Hot → Warm → Cold(full_copy) → Frozen(shared_cache) → Delete 5단계 자동 흐름.
• 검증 도구 = _verify (분기 1회) · _analyze (반기 1회) · 실제 복원 테스트 (분기 1회).
• 7대 사고 = S3 권한 누락 · SLM retention 미설정 · 마스터 변경 · mapping 충돌 · incremental 깨짐 · tier 노드 부재 · 복원 미테스트.
• 운영 5규칙 = Repository 분리 · SLM 이중 (nightly+weekly) · 분기 복원 검증 · ILM 묶음 · 무결성 점검 자동화.

시리즈 다른 편

• 이전 글 = 27편 Shard Allocation — Awareness·Filtering·Forced Awareness·Rebalance
• 다음 글 = 29편 Security — TLS·Realm·RBAC·API Key
• 30편 = Monitoring — Elastic Stack Monitoring·Prometheus·Grafana
• 31편 = Performance Tuning — Heap·Refresh·Merge·Bulk size
• 16편 = ILM·Aliases·Rollover — Hot/Warm/Cold/Frozen tier 자동 흐름
• 26편 = Cluster Operations — master·voting·rolling restart·split-brain
• 35편 = AWS OpenSearch Service — Domain·Serverless·UltraWarm·Cold Storage
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — Elasticsearch Snapshot & Restore = S3 Repository + 증분 snapshot + Restore 옵션 + SLM 자동화 + Searchable Snapshot 다섯 도구로 데이터 보호의 최후 보루 를 세우는 운영 표준. Replica 는 HA · Snapshot 은 백업 한 줄을 외우고, 분기 복원 검증 한 줄을 박아 두면 사고 90% 가 막혀요.