백업 리스트 (MAT)

=====================================================================
MAT 라인 전체 백업 대상 인벤토리

=====================================================================
작성일: 2026-09-30 / 최종 갱신: 2026-10-01
조사 방법: root 계정으로 mat 라인 10개 호스트(mat-001~006, 101~103, 201~202)
전체 SSH 직접 접속, 전 항목 실제 명령으로 검증 완료 (미확인 항목 없음)
=====================================================================

[0. 핵심 요약]

1. mat-002 가 사실상 "진짜 운영 서버" 입니다.
   - AEM/eco 서비스(automol.samsungsdi.com, eco.samsungsdi.com) 전부가 여기 있음
   - PostgreSQL, MongoDB, Redis, 코드(13G), haproxy 설정까지 전부 이 호스트 로컬 디스크에만 존재
   - 이 호스트 하나 유실 = 서비스 전체 다운 + 복구 불가능한 데이터 발생. 최우선 백업 대상.

2. CephFS/RGW(공유 스토리지)는 Ceph 복제로 이미 보호되고 있음 → 스냅샷/버킷 반출만 하면 됨.
   로컬 디스크(각 서버의 "/" 파티션)에만 있는 데이터가 진짜 위험 지점이며, 아래 3가지가 핵심:
     - mat-002: /home/delete/dev (163G, pubchem 143G 포함) - CephFS 아님, 복제 없음
     - mat-001/003/004/005/006: 각자의 dev/automol 로컬 사본 (6~8G × 5대)
     - mat-202: /home/anseong.park/0.openmm_test (분자동역학 연구데이터)

3. 인증서/TLS는 mat 라인 전체 어디에도 없음 (전부 HTTP 평문, DB도 sslmode=disable) → 백업 대상에서 제외.

4. 2026-10-01 추가로 lsblk(전체 디스크/파티션) + podman 마운트(전체 컨테이너 볼륨)까지 전수조사 완료.
   위 2)에 나열한 3곳 외에 추가로 발견된 Ceph 사각지대는 없음 (최종 확정).

 

=====================================================================

[1. 호스트 전체 개요]

호스트	역할	haproxy	인증서	비고
mat-001	admin / ceph mon·mgr·rgw / slurm컨트롤러	없음	없음	MariaDB, Prometheus, ES(컨테이너), Kibana, deep-flask
mat-002	★ 운영 웹서비스 핵심 호스트 ★	있음	없음	AEM/eco 전체 서비스. 아래 2-2번 상세 참고
mat-003	HDD 스토리지 + deep-flask + ES 노드	없음	없음	mat-es-cluster 소속 ES 노드
mat-004	HDD 스토리지 + deep-flask + ES 노드	없음	없음	상동
mat-005	HDD 스토리지 + deep-flask + ES 노드	없음	없음	상동
mat-006	HDD 스토리지 + deep-flask + ES 노드	없음	없음	상동 (+ smartd 디스크 감시)
mat-101	GPU 컴퓨트	없음	없음	vllm-gemma4.service는 3주째 FAILED 상태 (실제 미운영)
mat-102	GPU 컴퓨트	없음	없음	vllm-qwen 정상 운영 중 (Qwen3.5-397B-A17B-FP8)
mat-103	GPU 컴퓨트	없음	없음	Slurm 컴퓨트 노드만, 특이 서비스 없음
mat-201	GPU 컴퓨트 + ceph mon/mgr/mds	없음	없음	Ceph 관리 역할 겸함 (appolo-18)
mat-202	GPU 컴퓨트(vllm-glm) + ceph mon/mds	없음	없음	Ceph 관리 역할 겸함 (appolo-19), osd.153 호스트

참고: 이 환경엔 Elasticsearch 클러스터가 2개 존재함

• mat-es-cluster    : mat-002/003/004/005/006 5노드, native systemd, 데이터는 /data/ssd/elasticsearch/<호스트명> (CephFS)
• mat-es-podman-nvme: mat-001 1노드, 컨테이너(es-nvme-recover), 데이터는 /data/nvme/podman/ (CephFS)

 

=====================================================================

[2. 호스트별 로컬 서비스 상세]

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

(2-1. mat-001)

> DB / 서비스 데이터

항목	경로	용량	비고
MariaDB(slurmdbd)	/var/lib/mysql	462M	덤프 완료: /data/ssd/backup_staging/mariadb/ (118M)
Prometheus TSDB	/var/lib/prometheus	21G	모니터링 시계열 데이터
Elasticsearch(컨테이너)	/data/nvme/podman/elasticsearch/mat-001/	-	mat-es-podman-nvme 클러스터, 스냅샷 미설정(작업 필요)
Kibana	/data/nvme/podman/kibana/data	-	대시보드 설정/세션 데이터
deep-flask 코드	/home/delete/dev/automol/deep-flask	7.8G	로컬 사본, .git 없음(버전관리 안 됨) => 백업 필요

> 설정 파일 - 전부 백업 대상, 용량 작음

• Ceph 접속정보   /etc/ceph/*
• Slurm 설정      /etc/slurm/*.conf, job_submit.lua, healthcheck_cephfs.sh
• Prometheus 설정 /etc/prometheus/prometheus.yml
• 네트워크 설정   /etc/NetworkManager/system-connections/*.nmconnection
• yum repo 설정   /etc/yum.repos.d/*.repo*

> 커스텀 systemd 서비스

서비스명	의존 스크립트
deep-flask-node-8085.service	/home/delete/dev/automol/deep-flask/scripts/run_cluster_node.sh
custom-node-metrics.service	/usr/local/bin/update_custom_metrics.sh
slurm-gpu-postgres-export.service	/usr/local/bin/collect_slurm_gpu_metrics_to_postgres.py
aem-metrics.service	/usr/local/bin/export_aem_metrics.py
ceph-weekly-rebalance.service	/usr/local/sbin/ceph-weekly-rebalance-guard (osd.153 리밸런싱 자동화, 중요)
gpu-util-avg-exporter.service	-

> 컨테이너(podman)

이름	상태	비고
es-nvme-recover	Up 4주 (운영중)	실사용 ES
es-nvme	Stopping(4개월째)	좀비 상태, 정리 대상(백업 불필요)
kibana-nvme	Up 4개월	운영 중
metricbeat-stack-monitoring	Up 4개월	운영 중
ceph 관련 컨테이너 다수	Up (모니터링용)	cephadm 관리, 클러스터 자체가 원본이라 별도 백업 불필요

 

---------------------------------------------------------------------
(2-2. mat-002  ★★★ 최우선 백업 대상 - 운영 서비스 전체가 여기 있음 ★★★)

• haproxy
  • 포트 80, TLS 없음 - HTTP만  
  • 설정파일
    • /etc/haproxy/haproxy.cfg
  • 라우팅
    • automol.samsungsdi.com => 127.0.0.1:8080 (automol_backend)
    • eco.samsungsdi.com => 127.0.0.1:18081 (eco_backend)

> DB / 서비스 데이터 - 전부 로컬 디스크, CephFS 아님

항목	용량	경로/포트	비고
PostgreSQL(dev_aem)	34G	/var/lib/pgsql/data, 포트 5432	pg_dump/pg_basebackup 대상
Redis	204K	/var/lib/redis/dump.rdb + appendonly.aof, 포트 6379	BGSAVE 후 복사
MongoDB	919M	/var/lib/mongo, 포트 27017	mongodump 대상
Elasticsearch(native)	-	/data/ssd/elasticsearch/mat-002 (CephFS), 포트 19200	mat-es-cluster 5노드 중 1
Grafana	1.8M	/var/lib/grafana, /etc/grafana/grafana.ini, ldap.toml
Filebeat	-	etc/filebeat/filebeat.yml
AEM 백엔드 코드	13G	/home/delete/aem/ (jar: aem-0.0.1-SNAPSHOT.jar, 포트 18090)
AEM 프론트엔드	-	/home/delete/aem/.../frontend/dist/F_ECO/browser (정적 빌드, podman nginx)
설정 스크립트/템플릿	-	/etc/aem-manual/start-aem-backend-18090.sh, frontend-18081.conf.template
인증서/TLS	없음		haproxy의 ssl-default-*는 미사용 기본값, PG도 sslmode=disable 확인됨

> ★ 로컬 전용 163G - Ceph 복제 안 되는 백업 사각지대 ★

경로	용량	비고
/home/delete/dev/automol/pubchem	143G	단일 디렉토리, 지금까지 어떤 백업 계획에도 없던 항목. 최우선 반영 필요
/home/delete/dev/automol/deep-flask	6.7G	로컬 사본 (다른 호스트와 별개)
/home/delete/dev/automol2/deep-flask	6.7G	상동
/home/delete/dev 전체	163G	파티션(429G 중 306G=72% 사용, 10개 호스트 중 가장 여유 없음)

※ git 저장소이며 원격(gitlab.aid.samsungsdi.com/delete/automol.git)과 연결되어 있으나 일부 파일이
  미커밋 상태 — 코드 관리 관점에서는 문제 없음(사용자 확인), 다만 "데이터"로서는 로컬에만 있으므로
  백업 시 작업트리 전체를 그대로(미커밋 변경분 포함) 복사해야 함.

 

---------------------------------------------------------------------
(2-3. mat-003 / 004 / 005 / 006 (동일 구성))

• deep-flask-node-8085.service 운영 (mat-001과 동일 서비스, 노드 분산 배치)
• native elasticsearch.service 운영 (mat-es-cluster 5노드 중 각 1노드, 데이터는 /data/ssd/elasticsearch/<호스트명>, CephFS)
• /home/delete/dev/automol 로컬 사본 존재 (호스트당 6.4G, .git 없음 → 버전관리 전혀 안 됨, 반드시 백업 대상)
• mat-006에는 smartd(디스크 SMART 감시) 추가 운영
• haproxy/커스텀 인증서 없음

 

---------------------------------------------------------------------
(2-4. mat-101 / 102 / 103 / 201 / 202 (GPU 컴퓨트))

• mat-101: vllm-gemma4.service 3주째 FAILED(exit 203) 상태 → 실제로는 안 돌고 있음, 백업 우선순위 제외 가능
• mat-102: vllm-qwen 정상 운영 중
• mat-103: Slurm 컴퓨트 노드만, 특이사항 없음
• mat-201/202: Ceph mon/mgr/mds 역할 겸함, mat-202는 osd.153 보유
• mat-201 /home/anseong.park: test.sh, gpu_usage.log 등 소규모 개인 스크립트/로그 (수십KB~MB) → 백업 대상
• mat-202 /home/anseong.park/0.openmm_test: 분자동역학 시뮬레이션 결과물(checkpoint, 궤적, 로그 등)
  로컬 디스크 전용, CephFS 미사용, 지금까지 백업 계획에 없던 개인 연구데이터
  => 반드시 백업 대상 (miniconda3 환경 자체는 재설치 가능하므로 제외해도 됨)
• haproxy/커스텀 인증서 전부 없음

 

=====================================================================

[3. 클러스터 공유 스토리지 (Ceph 기반, mat 라인 전체 공통)]

이미 Ceph 복제로 보호되고 있어 호스트별 반복 조사 불필요. 스냅샷/버킷 반출만 하면 됨.

 

> CephFS 마운트 전체 용량

경로	사용 중	전체	용도
/data/ssd	4.84TB	5.7TB	DB/검색엔진/서비스 데이터
/data/hdd	73.1TB	83.1TB	사용자 대용량 연구 데이터
/data/nvme	2.96TB	11.1TB	고속 인덱스/컨테이너 런타임
/cephfs	0 (미사용)	73.5TB	레거시, 사실상 사용 안 함

> /data/ssd 하위 디렉토리

디렉토리	용량	내용
elasticsearch/	791GiB	mat-es-cluster(mat-002~006 5노드) 데이터
users/	997GiB	사용자 작업 디렉토리 (gpuusers 그룹)
postgresql/	34GB	PostgreSQL 데이터 (mat-002 소속)
mongo/	916MiB	MongoDB 데이터 (mat-002 소속)
aem_subset/	5.4GB	AEM 서브셋 데이터
automol_subset/	1.8GB	Automol 서브셋 데이터
redis/	204KB	Redis 데이터
llm-model/	(제외)	AI 모델 엔진 - 백업 대상 아님
backup_staging/	118MB	이번 작업으로 생성한 백업 스테이징 폴더

> /data/hdd 하위 디렉토리

디렉토리	용량	내용
users/	37TiB	사용자 대용량 데이터 (연구/계산 결과물)

> /data/nvme 하위 디렉토리

디렉토리	용량	내용
podman/	1.5TiB	컨테이너 실 데이터 (mat-001 ES/Kibana 등)
users/	954MiB	사용자 고속 스크래치
elasticsearch-nvme/	0B	미사용 구 경로

> RGW(S3) 버킷별 용량

버킷명	용량	내용
automol2	2.26TB	Automol 메인 데이터 (quota 2.8TB)
eco	590GB	eco 프로젝트
migration-aem-automol-elasticsearch	401GB	AEM-Automol 마이그레이션 ES 덤프
aem	218GB	AEM 프로젝트
automol	1.97GB	Automol 초기 데이터
automol-v2	103MB	Automol v2
migration-aem-automol-mongodb	69MB	Mongo 마이그레이션 덤프
migration-aem-automol-postgres	32MB	Postgres 마이그레이션 덤프
automol2-public	4KB	사실상 빈 상태
automol-dev	0 (추정)	비어있음

> 전체 10개 호스트 로컬 루트 디스크(/) 사용량

호스트	크기	사용	비고
mat-001	429G	203G
mat-002	429G	306G(72%)	home/delete/dev 163G 포함 — 10개 호스트 중 가장 여유 없음
mat-003	429G	36G
mat-004	429G	40G
mat-005	429G	36G
mat-006	429G	37G
mat-101	3.5T	50G
mat-102	3.5T	66G
mat-103	3.5T	41G
mat-201	3.5T	46G
mat-202	3.5T	58G

* CephFS 마운트은 전 호스트 공유 자원이라 이 표에서 제외)

 

=====================================================================

[4. 백업 대상에서 제외 (재생성 가능, 캐시성 데이터)]

• mat-101/102 /root/.cache/pip, /root/.cache/vllm, /root/.cache/flashinfer (vLLM 컴파일/모델 캐시)
• 전 호스트 /opt/nvidia/nsight-*, /opt/python, /opt/gpu-installer-files (설치 바이너리, 재설치 가능)
• mat-202 /home/anseong.park/miniconda3, .conda, .cache (재설치 가능한 환경)
• llm-model/ (AI 모델 엔진 원본 - 별도 관리)

 

=====================================================================

[5. 백업 체크리스트 (우선순위 순)]

[x] mat-001 MariaDB 전체 덤프	완료 (118M, /data/ssd/backup_staging/mariadb/)
[x] 전체 10개 호스트 SSH 전수조사 (서비스/haproxy/인증서/디스크/lsblk/podman 마운트)	완료
[x] mat-002 Redis 실제 데이터 파일 경로 확인	완료 (/var/lib/redis/dump.rdb, appendonly.aof)
[x] 전 호스트 인증서/TLS 유무 확인	완료 (전부 없음)
[ ] mat-002 PostgreSQL(dev_aem, 34G) 덤프	미완료 - pg_dump/pg_basebackup (최우선)
[ ] mat-002 MongoDB(919M) 덤프	미완료 - mongodump
[ ] mat-002 Redis(204K) 덤프	미완료 - BGSAVE 후 복사
[ ] mat-002 AEM 코드+jar(13G) 백업	미완료 - /home/delete/aem/ 전체 rsync
[ ] mat-002 /home/delete/dev(163G, pubchem 143G 포함) 백업	미완료 - ★최우선, Ceph 미복제 영역
[ ] mat-002 haproxy/aem-manual 설정 백업	미완료 - /etc/haproxy/haproxy.cfg, /etc/aem-manual/*
[ ] mat-001/003/004/005/006 dev/automol(호스트당 6~8G) 백업	미완료 - .git 없음, 5개 호스트 전부
[ ] mat-202 /home/anseong.park/0.openmm_test 백업	미완료 - 분자동역학 연구데이터
[ ] mat-201 /home/anseong.park(스크립트/로그) 백업	미완료 - 용량 작음
[ ] mat-001 Elasticsearch(mat-es-podman-nvme) 스냅샷	미완료 - elasticsearch.yml path.repo 설정 필요 + 재시작
[ ] mat-002~006 Elasticsearch(mat-es-cluster, 5노드) 스냅샷	미완료 - 리포지토리 1곳만 설정하면 5노드 전체 커버
[ ] Kibana 데이터 백업	미완료 - 용량 확인 필요
[ ] RGW 버킷 10개 pull	미완료 - rclone/s3cmd
[ ] CephFS 스냅샷(/ssd, /hdd, /nvme)	미완료 - 위 항목 전부 끝난 뒤 진행
[ ] 외부(Ceph 독립) 위치로 rsync 반출	미완료 - 전체 작업의 마지막 단계

 

=====================================================================

[6. 조사 중 바로잡은 사항 (참고용)]

• /data/ssd/postgresql, /data/ssd/mongo → mat-001 아닌 mat-002 소속으로 정정 (CephFS라 여러 호스트에서 보였음)
• /data/ssd/elasticsearch(791GiB) → mat-001 단독 인스턴스가 아니라 mat-002~006 5노드 클러스터(mat-es-cluster)로 정정 (mat-001의 ES는 NVMe의 별도 클러스터 mat-es-podman-nvme)
• mat-101 vllm-gemma4.service는 "설치되어 있음"일 뿐 실제로는 3주째 실패 상태로 정정
  => "돌고 있는 서비스"로 착각하면 안 됨. 백업 우선순위에서 제외 가능.