백업 리스트 (TERRA) - 1

=====================================================================
TERRA 라인 전체(TERRA-01~14) 백업 대상 최종 정리본
=====================================================================
작성일: 2026-10-01
검증방법: root로 14개 노드 전체 SSH 직접 접속(df -h/du -sh/systemctl 실측)
          + kubectl get pv/pvc 전수조회(StorageClass·노드·경로 확인)
          + 전체 네임스페이스 Pod spec에서 hostPath 볼륨 전수 검색
          + ceph df, kubelet volume stats로 실사용량 교차검증
읽는 법: ★ 표시 = 중요/주의. 모든 용량은 "실사용량"(할당량 아님) 기준.

=====================================================================
[0. 요약 — 꼭 알아야 할 5가지]
1. 전체 서비스 데이터는 4곳에 나뉘어 있음: ①Ceph RGW(S3) ②Ceph CephFS ③Ceph RBD
   ④노드 로컬 디스크(Ceph 전혀 아님) — 사용자 계획(RGW pull + CephFS snapshot)은 ①②만 커버함.
   ③④는 반드시 별도 백업 절차 추가해야 데이터 유실 없음. (상세: 3.)
2. ★★★ kafka·elastic은 Ceph가 아니라 각 노드 로컬 NVMe에 저장됨(local-nvme). 완전히 빠지는 부분. (상세: 3-2., 3-3.)
3. HAProxy+DHCP는 TERRA-01 단 1대에서만 동작(SPOF). 이 노드 죽으면 LB+PXE 부팅 동시 중단. (상세: 1.)
4. 라이선스 파일(MATLAB, 33MB) 등 일부 hostPath 데이터는 PVC가 아예 없어 어떤 백업 계획에도 안 걸림. (상세: 3-4.)
5. etcd(클러스터 설정)는 01/02/03 3대 모두 정상 존재(3중화 완료, 문제없음). (상세: [2])
6. ★★★ "Ceph 스냅샷"은 Ceph 내부에만 존재하는 포인터임 — Ceph 클러스터 자체가 없으면 스냅샷도 함께 사라짐.
   Ceph 없이 재구성하려면 스냅샷을 "외부의 실제 파일"로 export해야 함: RBD→rbd export, CephFS→rsync/tar로 실제 파일 복사, RGW→radosgw-admin/S3 client로 오브젝트 pull.
   스냅샷만 떠두고 Ceph 밖으로 꺼내지 않으면 "Ceph 없이 복구"는 불가능함. (상세: 3., 5.)
7. HAProxy/인증서/DHCP/kubeadm·etcd 외에 OS 자체를 재구성하려면 각 노드의 디스크 파티션(UUID/fstab)·네트워크(이중 NIC: 관리망+Ceph IPoIB망)·yum repo·containerd 레지스트리 설정도 필요 — 14개 노드 SSH 전수 확인 완료. (상세: 8.)

=====================================================================
[1. 노드별(TERRA-01~14) 실측 현황 — SSH 직접 접속 df -h/systemctl]

노드	역할	루트(/) 실사용/용량(%)	containerd	kubelet디렉토리(PVC마운트포함)	haproxy	dhcpd	kubelet
TERRA-01	control-plane+LB	1.5T/3.5T(41%)	185G	56G	active	active	active
TERRA-02	control-plane	41G/3.5T(2%)	7.4G	2.2M	inactive	inactive	active
TERRA-03	control-plane	39G/3.5T(2%)	7.2G	1.3M	inactive	inactive	active
TERRA-04	worker	223G/3.5T(7%)	125G	351G (RBD PVC 4개)	inactive	inactive	active
TERRA-05	worker	280G/3.5T(8%)	243G	1.3T (RBD PVC 9개, postgres 등)	inactive	inactive	active
TERRA-06	worker	254G/3.5T(8%)	212G	961M (RBD PVC 다수, 대부분 10G)	inactive	inactive	inactive
TERRA-07	worker	219G/3.5T(7%)	115G	2.3T (nexus-data-3681 4T 포함)	inactive	inactive	active
TERRA-08	worker	382G/3.5T(11%)	230G	279G (RBD PVC 다수)	inactive	inactive	active
TERRA-09	GPU worker	240G/7.0T(4%)	187G	1.5T (postgres-data 4.9T 포함)	inactive	inactive	active
TERRA-10	GPU worker(모델)	282G/7.0T(4%)	228G	1.8T (house-corps-models 포함)	inactive	inactive	active
TERRA-11	GPU worker(모델)	312G/7.0T(5%)	258G	1.6T (house-corps-models 포함)	inactive	inactive	active
TERRA-12	GPU worker(모델)	275G/7.0T(4%)	220G	2.4T (house-corps-models 포함)	inactive	inactive	active
TERRA-13	GPU worker(모델)	307G/7.0T(5%)	253G	1.6T (mongodb pvc 포함)	inactive	inactive	active
TERRA-14	GPU worker	291G/7.0T(5%)	236G	512G	inactive	inactive	active

 

★ HAProxy/DHCP는 TERRA-01 단 1대에서만 active(13대 전부 inactive 직접 확인) → SPOF, 이중화 권고
★ 모든 노드 OS/커널 동일: Rocky Linux 9.7(Blue Onyx), kernel 5.14.0-611.5.1.el9_7.x86_64 → 신규 서버도 동일 버전 맞출 것
★ GPU 노드(09~14)는 각 15~16개 local-nvme 디스크(7.0TiB) 장착 — scylla/kafka/elastic이 바로 이 디스크 위에 있음(3. 참조)
★ kubelet 디렉토리가 1~2.4TB로 큰 노드들은 전부 "Ceph RBD PVC가 마운트된 것"일 뿐 — 노드 자체를 백업할 필요 없음(Ceph 레벨 백업으로 충분, 중복 금지)

=====================================================================
[2. 컨트롤플레인 핵심 구성요소 (노드별 실측 크기)]

항목	TERRA-01	TERRA-02	TERRA-03	비고
etcd(/var/lib/etcd)	535 MB	524 MB	518 MB	반드시 etcdctl snapshot save로 백업(raw copy 금지). 3대 모두 정상 → 3중화 완료, 추가 조치 불요
/etc/kubernetes(PKI)	156 KB	148 KB	144 KB	CA/인증서/kubeconfig — 유실 시 클러스터 재구성 불가, 최우선 백업 대상
/etc/haproxy	308 KB	-	-	TERRA-01 전용([4]-1 haproxy-backup에 이미 포함됨)
/var/lib/rook(mon메타데이터)	190 MB	214 MB	204 MB	실제 OSD 데이터는 각 노드 로컬 디스크에 분산(Ceph 자체 복제로 보호됨)

※ 워커 노드(04~14)는 /etc/kubernetes에 kubelet.conf만 8.0KB로 존재(PKI 없음) — 정상 구성

=====================================================================
[3. ★★★ Ceph 사각지대 — 로컬 디스크에만 있는 데이터 (가장 중요, 위치·용량 전수 기재)]

• 검증방법 : kubectl get pv -o json 전수조회(StorageClass별 분류) + 전체 Pod spec hostPath 전수 검색 + SSH du -sh 실측
• 결론 : 아래 4종류는 사용자 계획의 "RGW pull"·"CephFS snapshot"으로 전혀 백업되지 않음. 반드시 별도 절차 필요.

---------------------------------------------------------------------

(3-1. Scylla — scylla-local-static (no-provisioner, 로컬 디스크 직결))

노드(샤드)	디스크개수	경로	용량(디스크당)	claim
terra-09	8개	/local-nvme/sda~sdi	4Ti	scylla-data-0~7-scylla-09-0
terra-10	8개	/local-nvme/sda~sdi	4Ti	scylla-data-0~7-scylla-10-0
terra-11	8개	/local-nvme/sda,sdc~sdi	4Ti	scylla-data-0~7-scylla-11-0
terra-12	8개	/local-nvme/sda~sdi	4Ti	scylla-data-0~7-scylla-12-0
terra-13	8개	/local-nvme/sda,sdc~sdi	4Ti	scylla-data-0~7-scylla-13-0
terra-14	8개	/local-nvme/sda~sdi	4Ti	scylla-data-0~7-scylla-14-0

PV 48개 전부 Bound(정상 사용중) / 실사용량 합계: 4,138.4 GB

★ 백업법: nodetool snapshot(6개 노드 동시 실행) → 스냅샷을 외부(Ceph RGW 등)로 복사. RAW 디스크 dd/tar 금지(일관성 깨짐)

---------------------------------------------------------------------
(3-2. Kafka — local-nvme (rancher.io/local-path, 로컬 디스크))

PVC(브로커)	노드	경로	용량
kafka-data-kafka-0	terra-09	/local-nvme/sde/pvc-cdba0661..._kafka-data-kafka-0	1Ti
kafka-data-kafka-1	terra-14	/local-nvme/sdn/pvc-68b1290f..._kafka-data-kafka-1	1Ti
kafka-data-kafka-2	terra-12	/local-nvme/sdf/pvc-f2c453b1..._kafka-data-kafka-2	1Ti
kafka-data-kafka-3	terra-10	/local-nvme/sdj/pvc-b7f930f9..._kafka-data-kafka-3	1Ti
kafka-data-kafka-4	terra-13	/local-nvme/sde/pvc-d1442d03..._kafka-data-kafka-4	1Ti
kafka-data-kafka-5	terra-11	/local-nvme/sdk/pvc-b6eea1fa..._kafka-data-kafka-5	1Ti

 

실사용량 합계: 469.7 GB (※ 과거 재배포 잔존 PV 11개가 "Released" 상태로 남아있음 — 미사용, 삭제 전 내용만 확인)

 

★ 백업법: kafka-topics/MirrorMaker로 토픽 데이터 외부 export, 또는 각 노드에서 경로 직접 tar/rsync

---------------------------------------------------------------------
(3-3. Elasticsearch — local-nvme (rancher.io/local-path, 로컬 디스크))

PVC(샤드)	노드	경로	용량
elasticsearch-data-elasticsearch-0	terra-14	/local-nvme/sdg/...	3Ti
elasticsearch-data-elasticsearch-1	terra-11	/local-nvme/sdi/...	3Ti
elasticsearch-data-elasticsearch-2	terra-12	/local-nvme/sdh/...	3Ti
elasticsearch-data-elasticsearch-3	terra-10	/local-nvme/sdd/...	3Ti
elasticsearch-data-elasticsearch-4	terra-13	/local-nvme/sdh/...	3Ti
elasticsearch-data-elasticsearch-5	terra-09	/local-nvme/sdj/...	3Ti

 

실사용량 합계: 2,733.0 GB

 

★ 백업법: Elasticsearch Snapshot API로 S3(RGW) 리포지토리에 스냅샷 생성 권장(등록돼 있으면 계획 2번과 자동 통합). 미등록 시 디스크 직접 백업만이 유일한 방법 — 지금 바로 repository 등록 필요

---------------------------------------------------------------------
(3-4. hostPath — PVC 자체가 없어 어떤 백업 계획에도 안 걸리는 데이터)

네임스페이스	노드	경로	실측용량	비고
mps	terra-01	/var/lib/mathworks-network-license-manager	33 MB	★라이선스 파일 — 재발급 어려울 수 있음, 최우선 백업
mps	terra-01	/var/lib/matlab-runtime-legacy/roots	57 GB	레거시 런타임(install_legacy_matlab_runtimes.sh로 재설치 가능한지 확인 필요)
mps	terra-01	/var/lib/matlab-production-server/apps	11 MB	배포된 MPS 애플리케이션
mps	terra-01	/var/lib/matlab-production-server/logs	12 MB	운영 로그(중요도 낮음)
house-dev	terra-07	/var/lib/house/openhands-config	180 KB	openhands 설정 파일
house-dev	terra-07	/var/lib/house/openhands-workspace	0 (비어있음	현재 데이터 없음

 

★ 백업법: 전부 용량이 작으므로 SSH로 직접 tar 떠서 /root 백업 묶음에 포함시키면 충분

---------------------------------------------------------------------
(3-5. Ceph RBD(rook-ceph-block) 중 "비-DB 파일데이터" — Ceph 안에 있지만 RGW/CephFS 계획에서 누락)

네임스페이스	PVC개수	용도	권장 백업법
gitlab	8개	git repo/container registry/CI 아티팩트	gitlab-backup 툴(이미 /root에 있으나 5개월 지남) 또는 RBD snapshot export
house-container-dev	753개	개발자 임시 워크스페이스 파일	대부분 0GB, 우선순위 낮음, 필요시 RBD snapshot
aid-container	60개	aid 서비스 파일 데이터	RBD snapshot export 또는 앱 레벨 백업 확인
house/house-container	26개	일반 애플리케이션 파일	RBD snapshot export
imsi	26개	레거시 ES/Kafka/PG/RabbitMQ 잔존 데이터	이관 완료 여부 재확인 후 삭제 또는 백업

 

 

※ RBD는 Ceph replicapool(18TiB) 안에 있어 "완전히 없어지는" 사각지대는 아니지만, RGW pull·CephFS snapshot 절차로는 반출 안 됨
=> Ceph 클러스터 자체가 통째로 사라지는 재해/신규서버 이전 상황을 가정하면 RBD snapshot을 rbd export로 반드시 외부 반출해야 함