날씨 정보를 불러오는 중...

단일 노드 홈랩 재해복구 대비하기 - Velero + MinIO로 쿠버네티스 백업 구축기

2026-09-14 07:34 · IT기술 · 조회 8
Velero MinIO Backup DR

단일 노드 홈랩 재해복구 대비하기 - Velero + MinIO로 쿠버네티스 백업 구축기

집에서 돌리는 k3s는 노드가 딱 한 대입니다. 앱이 몇 개 안 될 때는 "죽으면 다시 설치하지 뭐" 하고 넘어갔는데, 블로그·메일 서버·자동매매 봇처럼 데이터가 쌓이는 서비스가 하나둘 늘어나니 얘기가 달라지더군요. 디스크 하나가 맛이 가면 지금까지의 글, 계정, 설정이 통째로 날아간다는 뜻이니까요. 결국 재해복구(DR) 체계를 만들어야겠다 싶어서 Velero와 MinIO를 붙여 클러스터 백업을 구축했습니다. 오늘은 이 둘이 뭔지와, 실제로 붙여본 과정을 정리합니다.

왜 하필 Velero + MinIO인가

클라우드에서 쓰는 매니지드 쿠버네티스라면 백업을 클라우드 벤더의 스냅샷 기능이나 S3에 맡기면 그만이지만, 홈랩은 그런 관리형 서비스가 없습니다. 그래서 백업 저장소부터 직접 준비해야 하는데, 여기서 나오는 조합이 Velero(백업 엔진) + MinIO(S3 호환 오브젝트 스토리지)입니다. Velero는 백업 대상이 어디로 저장되는지 신경 쓰지 않고 "S3 호환 API"만 있으면 되도록 설계돼 있어서, 클라우드 S3 대신 내 클러스터 안에 떠 있는 MinIO를 백업 저장소로 그대로 꽂아 쓸 수 있습니다.

Velero가 뭔가요?

Velero는 VMware가 만든 오픈소스 프로젝트로, 쿠버네티스 클러스터의 리소스 정의(YAML 상태)와 퍼시스턴트 볼륨 데이터를 함께 백업하고 복원해주는 도구입니다. 단순히 kubectl get -o yaml로 리소스만 덤프하는 게 아니라, PV/PVC 데이터까지 실제로 백업해서 클러스터를 통째로 새로 만들거나 특정 네임스페이스만 예전 시점으로 되돌리는 것도 가능합니다. 스케줄 기능이 내장돼 있어서 cron처럼 "매일 새벽 4시에 백업"을 자동화할 수 있는 것도 큰 장점입니다.

MinIO는 왜 같이 쓰나요?

MinIO는 자체 호스팅이 가능한 S3 호환 오브젝트 스토리지입니다. AWS S3와 API가 동일해서, AWS SDK나 S3 클라이언트를 쓰는 모든 도구(Velero 포함)가 별다른 수정 없이 그대로 붙습니다. 홈랩처럼 외부 클라우드 계정을 쓰지 않는 환경에서는 클러스터 안에 MinIO를 하나 띄워두고 그걸 "내 전용 S3"처럼 쓰는 구조가 가장 현실적입니다.

아키텍처 한눈에 보기

minio MinIO - 클러스터 안에 별도 네임스페이스(minio)로 떠서 백업 데이터를 실제로 저장하는 S3 호환 스토리지입니다.

velero Velero 서버 + node-agent - 클러스터 리소스 정의는 Velero 서버가, PV 안의 실제 파일 데이터는 각 노드에 떠 있는 node-agent(내부적으로 restic/kopia 기반)가 백업해서 MinIO로 올립니다.

schedule Schedule - Velero의 스케줄 리소스로 "매일 몇 시에 무엇을 백업할지"를 cron 문법으로 정의합니다.

disaster 복구 시나리오 - 노드 디스크가 망가지거나 실수로 리소스를 지웠을 때, MinIO에 쌓인 백업에서 특정 시점으로 velero restore를 실행해 되돌립니다.

직접 구축해보기

minio 1. MinIO 배포 및 버킷 생성

먼저 백업을 저장할 MinIO를 별도 네임스페이스에 올립니다. Deployment + PVC + Service로 단일 인스턴스를 띄우고, 버킷은 mc(MinIO 클라이언트)를 실행하는 1회성 Job으로 만들어두면 재현 가능한 형태로 관리하기 편합니다.

kubectl create namespace minio
kubectl apply -f minio-pvc.yaml
kubectl apply -f minio-deployment.yaml
kubectl apply -f minio-service.yaml

# mc(MinIO 클라이언트)로 velero 전용 버킷 생성 (Job으로 1회 실행)
kubectl apply -f mc-mb-job.yaml

helm 2. Velero CLI 설치 및 서버 배포

Velero는 CLI 하나로 서버 설치와 백업/복구 명령을 모두 처리합니다. MinIO는 AWS S3와 API가 같기 때문에 provider는 그대로 aws로 지정하고, 엔드포인트만 MinIO 서비스 주소로 돌려줍니다.

curl -fsSL -o velero.tar.gz \
  https://github.com/vmware-tanzu/velero/releases/download/v1.14.0/velero-v1.14.0-linux-amd64.tar.gz
tar -xzf velero.tar.gz
sudo mv velero-*/velero /usr/local/bin/

# MinIO 접근용 자격증명 파일
cat > credentials-velero <<EOF
[default]
aws_access_key_id=minioadmin
aws_secret_access_key=minioadmin
EOF

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.10.0 \
  --bucket velero \
  --secret-file ./credentials-velero \
  --use-node-agent \
  --backup-location-config region=minio,s3ForcePathStyle=true,s3Url=http://minio.minio.svc.cluster.local:9000 \
  --snapshot-location-config region=minio

--use-node-agent가 핵심인데, 이 옵션이 있어야 PV 안의 실제 파일 데이터를 백업합니다. local-path-provisioner처럼 CSI 스냅샷을 지원하지 않는 스토리지 클래스를 쓰는 홈랩 환경에서는 이 옵션 없이는 리소스 정의만 백업되고 실제 데이터는 빠지니 꼭 챙겨야 합니다.

schedule 3. 백업 스케줄 등록

velero schedule create daily-backup \
  --schedule="0 19 * * *" \
  --ttl 240h0m0s

여기서 처음에 한 번 헷갈렸던 부분인데, Velero 서버 파드는 컨테이너 시간대(UTC) 기준으로 cron을 해석합니다. 그래서 한국 시간 새벽 4시에 백업하고 싶다면 0 19 * * *(UTC 19시 = KST 익일 04시)로 등록해야 합니다. KST 그대로 0 4 * * *를 넣으면 낮 1시에 백업이 도는 사고가 날 수 있습니다.

check 4. 백업 확인 및 복구 테스트

velero backup get
velero backup describe daily-backup-20260913040000 --details

# 특정 백업 시점으로 복구
velero restore create --from-backup daily-backup-20260913040000

백업이 "쌓이고 있다"는 것과 "실제로 복구가 된다"는 것은 다른 문제입니다. 테스트용 네임스페이스를 하나 지워보고 방금 만든 백업으로 실제 복구가 되는지 한 번은 꼭 검증해보는 걸 추천합니다.

실무에 적용할 때 팁

  1. warn 스케일을 0으로 내려둔 앱(레플리카 0)은 파드가 없으니 Velero가 볼륨 데이터를 백업할 대상 자체를 못 찾습니다. 평소엔 꺼두고 가끔만 켜는 서비스가 있다면 백업 커버리지에서 빠져 있는 건 아닌지 따로 확인해야 합니다.
  2. CronJob이 쓰는 PVC도 마찬가지로 백업 시점에 파드가 떠 있지 않으면 놓치기 쉬운 케이스입니다. velero backup describe --details로 실제 어떤 리소스가 포함됐는지 매번 확인하는 습관을 들이는 게 좋습니다.
  3. MinIO 자체가 이 서버 안에만 있다면, 서버가 통째로 죽는 사고에는 무력합니다. 진짜 재해복구를 원한다면 MinIO 데이터를 외부(클라우드 오브젝트 스토리지나 다른 물리 위치)로 한 번 더 복제하는 것까지 고려하는 게 맞습니다.
  4. TTL을 너무 길게 잡으면 MinIO 저장 공간이 계속 늘어납니다. 홈랩처럼 디스크가 넉넉하지 않다면 보관 기간을 필요한 만큼만(예: 10일) 짧게 잡는 걸 추천합니다.

마무리

백업은 있는 것보다 "실제로 복구되는 백업"이 있는 게 중요하다는 걸 이번에 새삼 느꼈습니다. 스케줄을 걸어두고 잘 돌아가는 것만 확인하고 넘어가기 쉬운데, 스케일 0인 앱이나 CronJob의 PVC처럼 조용히 빠지는 사각지대가 생각보다 있더군요. 단일 노드 홈랩이라도 이 정도 체계 하나 갖춰두면 디스크 사고 한 번에 그동안의 데이터를 통째로 잃는 최악의 상황은 피할 수 있습니다. 더 자세한 옵션은 공식 문서(velero.io, min.io)를 참고하시는 걸 추천합니다.

댓글 0

로그인 후 댓글을 작성할 수 있습니다.