앞선 시리즈에서 Secret, ConfigMap, DB 덤프 등 논리적 백업 방법을 다뤘습니다. 하지만 장애 상황이나 대용량 데이터를 다룰 때는 PV(PersistentVolume)의 물리적 데이터를 직접 백업해야 하는 경우가 있습니다.
이 글에서는 PV 데이터를 백업하는 세 가지 방식을 비교하고, 각 상황에 맞는 최적의 방법을 안내합니다.
들어가며: 백업 방식에 따른 안정성 차이
PV 데이터를 백업하는 방식은 크게 세 가지입니다.
| 방식 | 실행 위치 | 안정성 |
|---|---|---|
| kubectl exec | Pod 내부 | 클러스터 정상 시만 가능 |
| minikube ssh | 노드 내부 | 노드 리소스 소모 |
| volume 직접 백업 | 호스트 | 가장 안정적 |
핵심은 **”어디서 백업을 실행하느냐”**입니다. 노드 내부에서 실행할수록 장애에 취약하고, 호스트에서 직접 실행할수록 안정적입니다.
백업 방식 비교
방식 1: kubectl exec (Pod 내부 덤프)
Pod 안에서 직접 덤프 명령을 실행하는 방식입니다.
# PostgreSQL 덤프 예시
kubectl exec -it <postgres-pod> -- pg_dumpall -U postgres > backup.sql
# 파일 복사
kubectl cp <postgres-pod>:/var/lib/postgresql/data ./pgdata-backup
장점
- 가장 직관적이고 간단함
- 논리적 덤프로 이식성 좋음
단점
- kubectl이 동작해야만 가능
- 인증서 만료, API 서버 장애 시 불가
- 대용량 데이터는 시간 오래 걸림
적합한 상황
- 클러스터 정상 상태
- 소규모 데이터 (< 1GB)
- 정기 백업
방식 2: minikube ssh (노드 내부 백업)
minikube 노드에 SSH 접속하여 PV 경로를 직접 백업하는 방식입니다.
# minikube SSH 접속
minikube ssh
# PV 경로 확인
sudo ls -la /tmp/hostpath-provisioner/default/<pvc-name>
# tar로 백업
sudo tar cf /tmp/backup.tar /tmp/hostpath-provisioner/default/<pvc-name>
장점
- kubectl 불가 시에도 가능
- 물리적 파일 그대로 백업
단점
- 노드 리소스(CPU, I/O) 직접 소모
- 대용량 + gzip 시 노드 과부하 위험
- 노드가 죽으면 SSH도 불가
적합한 상황
- kubectl 불가, SSH는 가능
- 소~중규모 데이터 (< 10GB)
- 압축 없이 빠르게 복사할 때
방식 3: docker/podman volume 직접 (호스트 백업)
minikube가 사용하는 docker/podman volume을 호스트에서 직접 접근하여 백업하는 방식입니다.
Docker Driver 환경
# volume 경로 확인
docker volume inspect minikube --format '{{ .Mountpoint }}'
# 직접 백업 (root 권한 필요)
sudo tar cf ~/backup/pgdata-backup.tar \
/var/lib/docker/volumes/minikube/_data/hostpath-provisioner/<namespace>/<pvc-name>
Podman Driver 환경
# volume 경로 확인
podman volume inspect minikube --format '{{ .Mountpoint }}'
# 직접 백업
sudo tar cf ~/backup/pgdata-backup.tar \
/var/lib/containers/storage/volumes/minikube/_data/hostpath-provisioner/<namespace>/<pvc-name>
장점
- 노드 상태와 완전히 독립적
- minikube가 꺼져 있어도 가능
- 가장 안정적
단점
- docker/podman driver에서만 가능
- VM driver(virtualbox 등)에서는 불가
- 경로 파악이 필요
적합한 상황
- 대용량 데이터 (> 10GB)
- 노드 장애/과부하 상황
- 안정적인 백업이 필요할 때
언제 어떤 방식을 써야 하나
클러스터 상태별 선택
| 상태 | kubectl | minikube ssh | 권장 방식 |
|---|---|---|---|
| 정상 | ✅ | ✅ | kubectl exec |
| 인증서 만료 | ❌ | ✅ | minikube ssh 또는 volume 직접 |
| 노드 과부하 | ❌ | ⚠️ 느림 | volume 직접 |
| 노드 장애 | ❌ | ❌ | volume 직접 |
데이터 규모별 선택
| 규모 | 권장 방식 | 비고 |
|---|---|---|
| 소규모 (< 1GB) | kubectl exec | 가장 간단 |
| 중규모 (1~10GB) | minikube ssh (무압축) | gzip 사용 주의 |
| 대규모 (> 10GB) | volume 직접 | 필수 |
대용량 백업 시 주의사항
노드 내부 백업의 위험성
minikube ssh 내부에서 대용량 데이터를 백업하면 다음과 같은 문제가 발생할 수 있습니다.
호스트
└─ minikube 컨테이너/VM
└─ tar + gzip 실행 ← CPU/I/O 폭주
└─ 노드 과부하
└─ SSH 끊김, API 서버 다운
실제 사례: 80GB pgdata를 minikube ssh 내부에서 gzip 압축과 함께 백업 시도 → 노드 과부하로 SSH 끊김 → 클러스터 복구 불가
gzip 병목 문제
대용량 데이터를 압축하면 CPU 사용률이 급격히 증가합니다.
# ❌ 위험: gzip 압축 사용
sudo tar czf backup.tar.gz /path/to/data
# ✅ 권장: 무압축
sudo tar cf backup.tar /path/to/data
무압축 백업 후 필요하다면 호스트에서 별도로 압축하는 것이 안전합니다.
# 호스트에서 압축 (노드에 영향 없음)
gzip ~/backup/pgdata-backup.tar
실패 사례와 교훈
상황: AWX용 PostgreSQL 80GB pgdata 백업 필요
시도 1 (실패)
minikube ssh
sudo tar czf /tmp/pgdata-backup.tar.gz /tmp/hostpath-provisioner/awx/...
# → gzip CPU 폭주 → SSH 끊김 → 노드 죽음
시도 2 (성공)
# 호스트에서 직접 실행
sudo tar cf ~/backup/pgdata-backup.tar \
/var/lib/docker/volumes/minikube/_data/hostpath-provisioner/awx/...
# → 노드 영향 없음 → 안정적 완료
교훈
노드 안에서 무거운 작업을 하면 노드가 죽는다. 호스트에서 직접 백업하면 노드 상태와 무관하게 안전하다.
백업 명령어 정리
Docker Driver 환경
# 1. volume 경로 확인
docker volume inspect minikube --format '{{ .Mountpoint }}'
# 출력 예: /var/lib/docker/volumes/minikube/_data
# 2. PV 데이터 경로 확인
sudo ls /var/lib/docker/volumes/minikube/_data/hostpath-provisioner/
# 3. 백업 실행 (무압축)
sudo tar cf ~/backup/pv-backup-$(date +%Y%m%d).tar \
/var/lib/docker/volumes/minikube/_data/hostpath-provisioner/<namespace>/<pvc-name>
# 4. 필요시 호스트에서 압축
gzip ~/backup/pv-backup-$(date +%Y%m%d).tar
Podman Driver 환경
# 1. volume 경로 확인
podman volume inspect minikube --format '{{ .Mountpoint }}'
# 출력 예: /var/lib/containers/storage/volumes/minikube/_data
# 2. PV 데이터 경로 확인
sudo ls /var/lib/containers/storage/volumes/minikube/_data/hostpath-provisioner/
# 3. 백업 실행 (무압축)
sudo tar cf ~/backup/pv-backup-$(date +%Y%m%d).tar \
/var/lib/containers/storage/volumes/minikube/_data/hostpath-provisioner/<namespace>/<pvc-name>
# 4. 필요시 호스트에서 압축
gzip ~/backup/pv-backup-$(date +%Y%m%d).tar
복원 명령어
# minikube 중지 (데이터 정합성)
minikube stop
# 기존 데이터 백업 (선택)
sudo mv /var/lib/docker/volumes/minikube/_data/hostpath-provisioner/<namespace>/<pvc-name> \
/var/lib/docker/volumes/minikube/_data/hostpath-provisioner/<namespace>/<pvc-name>.old
# 복원
sudo tar xf ~/backup/pv-backup-20260108.tar -C /
# minikube 시작
minikube start
방식별 비교 요약
| 항목 | kubectl exec | minikube ssh | volume 직접 |
|---|---|---|---|
| 실행 위치 | Pod 내부 | 노드 내부 | 호스트 |
| kubectl 필요 | ✅ 필수 | ❌ | ❌ |
| 노드 부하 | 있음 | 높음 | 없음 |
| 대용량 적합 | ❌ | ⚠️ | ✅ |
| 장애 시 사용 | ❌ | ⚠️ | ✅ |
| Driver 제한 | 없음 | 없음 | docker/podman만 |
마무리
PV 데이터 백업은 상황에 따라 적절한 방식을 선택해야 합니다.
핵심 원칙
- 정상 상태에서는 kubectl exec로 논리적 덤프
- 장애 상황이나 대용량은 호스트에서 volume 직접 백업
- 노드 내부에서 gzip 사용 금지
- 무압축 백업 후 호스트에서 별도 압축
주의: minikube(docker/podman driver) 환경에서는
minikube ssh내부에서 대용량 데이터 백업을 수행하지 말 것. 반드시 docker/podman volume을 호스트에서 직접 tar로 백업한다.