Consul 백업·복구 — Snapshot Save/Restore

이 글은 HashiCorp Consul 마스터 노트 시리즈의 다섯 번째 편입니다. 4편(KV)까지 데이터 저장·조회를 잡았다면, 이번엔 그 데이터를 재해 복구할 수 있도록 백업 — Objective 5.

운영 Consul에서 백업은 비즈니스 연속성의 핵심. 단일 명령 consul snapshot save로 시작합니다.

스냅샷에 포함되는 것

consul snapshot save backup.snap
   ↓
하나의 파일에 다음 모든 정보 포함:
├── KV Store 데이터
├── Service Catalog (등록된 서비스)
├── Health Checks
├── ACL Tokens·Policies·Roles
├── Sessions
├── Prepared Queries
└── Raft 메타데이터

여기서 정말 중요한 시험 함정 — Gossip 키와 TLS 인증서는 스냅샷에 포함 X. 별도 백업 필요. 7편(보안)에서 다룸.

consul snapshot save — 백업

# 기본 사용
consul snapshot save backup.snap

# 특정 서버 지정
consul snapshot save -http-addr=https://server1:8501 backup.snap

# ACL 토큰 (활성 시)
consul snapshot save -token=<UUID> backup.snap

어디서 실행해야?

리더에서 실행 권장. 다른 서버나 클라이언트에서도 가능하지만 리더가 직접 처리.

# 리더 확인
consul operator raft list-peers
# State 컬럼 = leader 인 노드

# 리더에서 실행
ssh leader-server "consul snapshot save /backups/backup-$(date +%Y%m%d-%H%M).snap"

스냅샷 검증

# 생성한 스냅샷 정보 보기
consul snapshot inspect backup.snap

# 출력:
# ID            2-1234-1633872000000
# Size          ...
# Index         12345
# Term          5
# Version       1

여기서 시험 함정이 하나 있어요. consul snapshot inspect 로 스냅샷이 손상 안 됐는지 사전 검증. 복원 후에야 깨진 거 알면 늦음.

자동 백업 — Cron

운영 환경 표준 — 매일 새벽 자동 백업.

#!/bin/bash
# /usr/local/bin/consul-backup.sh

set -e

BACKUP_DIR="/backups/consul"
TIMESTAMP=$(date +%Y%m%d-%H%M)
BACKUP_FILE="${BACKUP_DIR}/consul-${TIMESTAMP}.snap"

mkdir -p "${BACKUP_DIR}"

# 스냅샷 생성
/usr/bin/consul snapshot save "${BACKUP_FILE}"

# 검증
/usr/bin/consul snapshot inspect "${BACKUP_FILE}" > /dev/null

# S3로 업로드 (선택)
aws s3 cp "${BACKUP_FILE}" "s3://my-backups/consul/"

# 14일 이전 로컬 백업 삭제
find "${BACKUP_DIR}" -name "consul-*.snap" -mtime +14 -delete

echo "Backup complete: ${BACKUP_FILE}"

Cron 설정

# 매일 새벽 2시 백업
0 2 * * * /usr/local/bin/consul-backup.sh >> /var/log/consul-backup.log 2>&1

consul snapshot restore — 복구

# 정지·복구·재시작 흐름
sudo systemctl stop consul
consul snapshot restore backup.snap
sudo systemctl start consul

Restore 흐름

1. 클러스터에서 스냅샷 복구 명령 실행
   - 새 클러스터에 처음 복원: 단일 서버 띄우고 restore
   - 기존 클러스터 복구: 리더에 restore (다른 노드는 자동 동기화)

2. Raft 로그 재구성

3. 모든 서버 상태 재동기화

복구 시나리오

시나리오 A — 부분 데이터 손실

# 잘못된 KV 키 삭제 같은 운영 사고
# 백업에서 복구

consul snapshot restore backup.snap
# 백업 시점 상태로 모든 데이터 복원

여기서 정말 중요한 시험 함정 — restore는 전체 데이터 덮어쓰기입니다. 부분 복원 X. 백업 시점 이후 변경된 모든 데이터 손실.

시나리오 B — 클러스터 전체 손실

# 1. 새 5 서버 클러스터 부트스트랩 (2편 참조)
# 2. 첫 노드 시작 후 restore
ssh new-leader "consul snapshot restore /tmp/backup.snap"
# 3. 다른 4 서버 합류 → 자동 동기화

시나리오 C — 다른 환경으로 마이그레이션

# DC1 백업 → DC2 새 클러스터에 복원
# 단, datacenter 이름 일치해야 함

Snapshot Agent — Enterprise 기능

자동 백업·로테이션·외부 저장소 통합 (HashiCorp Cloud Platform 또는 Enterprise).

# /etc/consul.d/snapshot.hcl
snapshot_agent {
  http_addr = "127.0.0.1:8500"
  
  snapshot {
    interval         = "1h"   # 1시간마다
    retain           = 30     # 30개 보관
    deregister_after = "8h"
  }
  
  log {
    level = "INFO"
  }
  
  # AWS S3 저장
  aws_storage {
    s3_region = "us-east-1"
    s3_bucket = "my-consul-backups"
    s3_key_prefix = "consul-snapshots"
  }
}

OSS 사용자는 위의 Cron 스크립트로 직접 구현.

Restore 시 주의사항

Datacenter 이름 일치

# 원본 DC 이름과 다르면 거부
consul snapshot restore backup.snap
# Error: Snapshot is from a different datacenter

원본 백업의 datacenter 설정과 새 클러스터 datacenter가 일치해야 함.

Raft 버전 호환

스냅샷 Raft 버전과 새 클러스터 Raft 버전 호환 필요. 일반적으로 같은 메이저 버전 안에서는 OK.

진행 중 트래픽 중단

운영 중 restore = 모든 트래픽이 백업 시점 데이터로 갑자기 바뀜. 운영 시간 외 또는 점검 모드에서.

여기서 시험 함정이 하나 있어요. restore 시 백업 시점 이후 데이터는 모두 손실. 분 단위 데이터가 중요하면 백업 주기를 짧게 + Snapshot Agent의 interval = "10m" 같이.

DR (Disaster Recovery) 시나리오

Recovery Point Objective (RPO)

마지막 성공 백업 시점 = 데이터 복구 가능 시점.

백업 주기 1시간 → 최악의 경우 1시간 데이터 손실
백업 주기 1일 → 최악의 경우 1일 데이터 손실

운영 중요도에 맞춰 주기 조정.

Recovery Time Objective (RTO)

장애 발생 → 서비스 복구까지 시간.

RTO = (탐지 시간) + (복구 인프라 준비) + (restore 시간) + (검증)

Consul restore 자체는 빠름 (수십 초~수 분). 인프라 준비가 더 오래.

백업 검증 — 정기 테스트

운영 중요한 것 — 백업이 실제로 복구되는지 정기 테스트.

# 1. 별도 테스트 환경에 단일 서버 띄움
docker run -d --name consul-test consul:latest agent -dev

# 2. 운영 백업 가져옴
scp prod-server:/backups/latest.snap .

# 3. restore
docker exec consul-test consul snapshot restore /tmp/latest.snap

# 4. KV·서비스 확인
docker exec consul-test consul kv get -recurse
docker exec consul-test consul catalog services

매월·매분기 정기 테스트로 백업 무결성 확인.

OS 레벨 백업 — Raft 디렉토리

# data_dir 백업 (consul.hcl의 data_dir)
sudo systemctl stop consul
sudo tar czf consul-data-backup.tar.gz /opt/consul/
sudo systemctl start consul

consul snapshot이 권장이지만 OS 레벨 백업도 보조 수단으로 가능.

여기서 시험 함정이 하나 있어요. OS 레벨 백업은 클러스터 전체 동시에. 한 노드만 백업·복원 X — Raft 일관성 깨짐.

모니터링

# 백업 성공 메트릭 (자체 구현)
# - 마지막 백업 타임스탬프
# - 백업 크기 (이상 증가/감소 알람)
# - 백업 파일 검증 결과

# CloudWatch·Prometheus 알람
# - 백업 24h 이상 안 됨 → 알람
# - 백업 검증 실패 → 즉시 알람

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 5편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• 백업 = consul snapshot save backup.snap
• 스냅샷 포함 — KV / Catalog / Health Checks / ACL / Sessions / Prepared Query / Raft 메타
• Gossip 키·TLS 인증서는 스냅샷 X — 별도 백업
• 리더에서 실행 권장
• ACL 활성 시 — -token=<UUID>
• consul snapshot inspect = 스냅샷 검증
• 자동 백업 = Cron + 스크립트
• 14일·30일 보관 + S3 등 외부 저장
• 복구 = consul snapshot restore
• 전체 덮어쓰기 — 부분 복원 X
• 백업 시점 이후 데이터 모두 손실
• Datacenter 이름 일치 필수
• Raft 버전 호환 필요
• Snapshot Agent (Enterprise) = 자동 + S3 통합
• OSS는 직접 Cron으로 구현
• RPO = 백업 주기 (최악 데이터 손실)
• RTO = 복구 시간 (인프라 + restore + 검증)
• 백업 정기 테스트 필수 — 별도 테스트 환경
• OS 레벨 백업 = data_dir tar — 보조 수단
• OS 백업은 클러스터 전체 동시에 (한 노드만 X)
• 모니터링 — 마지막 백업 시점·검증 결과

시리즈 다른 편

• 1편 — Consul 입문
• 2편 — 단일 DC 배포
• 3편 — Service Discovery
• 4편 — KV Store
• 5편 — 백업 & 복구 (현재 글)
• 6편 — Service Mesh (Connect)
• 7편 — 보안 운영

공식 문서: Consul Snapshot에서 더 깊이.

다음 글(6편)에서는 Service Mesh — Connect 활성화·사이드카 프록시·Envoy·Intentions·mTLS까지 풀어 갑니다.