# test GPU 재발 방지·재부팅 전 백업 안내

상태: **사용자 수동 재부팅 준비 완료 / 실제 재부팅·새 드라이버 Runtime 검증 미실행**

- 작업일: 2026-10-12 KST, test / ltb1021.
- 백업 검증 완료: 2026-10-12 11:26:55 KST. 이후 생성·변경 자료는 이 백업에 포함된다고 보장하지 않는다.
- 사용자가 Proxmox/물리 콘솔 접근 가능을 확인했다. 에이전트는 재부팅을 실행하지 않았다.
- 기존 SSIMS 수동4채널 정상 확인은 595.84 임시 복구 상태의 사용자 수용이다. 새595.99.02 검증은 아니다.

## 1. 다른 세션이 먼저 읽을 내용

이 문서는 대화 원문이 아니라 파일 위치와 재개 경계를 연결하는 공통 안내문이다.
기존 세션의 목표·결정은 해당 세션 checkpoint를 계속 따른다. 백업에서 필요한 문서를 직접
읽을 수 있으며, 원래 /tmp 경로로 복구하는 것은 실행에 꼭 필요한 파일만 별도 검토한다.

| 원래 경로/내용 | 현재 보존 위치 |
| --- | --- |
| /tmp 아래 일반 파일·디렉터리·symlink | 이 디렉터리의 files/tmp/ 아래 같은 상대 경로 |
| /tmp/codex/ltb1021/<run>/... | files/tmp/codex/ltb1021/<run>/... |
| 선별한 /run 참고 설정2개 | files/run-selected/ 아래 같은 상대 경로, 자동 복원 금지 |
| 복사 목록·제외 목록·파일 메타데이터 | reports/tmp-final.json |
| 요약·중요 checkpoint/manifest/batch SHA256 | manifest.json |
| 원본/적용 후 호스트 설정 | host-config/before/, host-config/after/ 아래 절대 경로 구조 |
| 부팅 준비 검사와 서비스 보존 확인 | reports/host-validation.json, reports/final-preservation.json |
| 부팅 후 복붙 요청문 | POST_REBOOT_PROMPT.ko.txt |

다른 세션 전달 문장:

> test 재부팅 전 임시자료 백업 안내문을 먼저 읽고, 기존 /tmp 자료가 없으면 안내된 백업 경로에서 필요한 자료만 조회해 주세요. /tmp·/run 전체 복원, 기존 파일 덮어쓰기, 예전 PID/잠금/인증자료/임시 GPU 설정의 재적용은 하지 마세요.

## 2. 백업 범위와 검증

- 일반 파일29,896개, 디렉터리8,751개, symlink20개. 일반 파일의 논리 크기 합15,910,795,299바이트다.
  hardlink·희소 파일 등에 따라 실제 디스크 사용량과 다르다. 백업 후 /data 여유는 약620GiB였다.
- 원본을 삭제·이동하지 않았다. symlink를 따라가지 않고 링크 자체를 보존했으며 하위 mount를 확장하지 않았다.
- 낮은 CPU/I/O 우선순위와 약50MiB/s 전송 제한을 사용했다. 최초 복사와 마지막 변경분 확인 모두 returncode0.
- 마지막 checksum dry-run returncode0, 차이0. reports/rsync-verify.log가 비어 있는 것이 해당 비교 결과다.
- 중요한 checkpoint/manifest/batch 파일230개의 백업 SHA256도 기록했다.
- 제외: 알려진 credential 이름49개, 서비스 전용 임시 영역13개, 소켓/FIFO/device5개.
  정확한 목록은 보호된 reports/tmp-final.json의 excluded를 본다. 이름 기반 제외가 모든 비밀정보를
  탐지했다는 뜻은 아니다. 전체 백업은 root 전용(mode700)으로 유지하며 Git·외부 공유에 넣지 않는다.
- 실행 중 파일 복사이며 원자적인 filesystem snapshot·프로세스 메모리·실행 세션 복원이 아니다.
- /run은 tmpfs다. PID·소켓·잠금·namespace·sudo 인증 상태를 보존/복원하는 용도로 사용하지 않는다.
  제외된 임시 비밀번호 파일이 필요하면 사용자에게 안전하게 재준비를 요청한다.
- /workspace·/root의 일반 지속 파일과 Git 저장소 전체를 백업한 것은 아니다. 이번 작업에서 수정하지 않았다.

## 3. 확인 원인과 적용 설정

10월11일 unattended-upgrades가 호스트 NVIDIA595.84를595.99.02로 바꿨지만,
실행 중 kernel6.8.0-117에는595.84가 남았다. CDI 기본 ExecCondition은 .ko만 검사해
설치된 .ko.zst 모듈을 놓쳤다. Contextra와 SSIMS의 개별 요구 버전 충돌로 확인된 문제가 아니다.

새로 추가한 영구 설정은 아래3개뿐이며 기존 package-owned 파일은 수정하지 않았다.

1. /etc/apt/apt.conf.d/52test-gpu-maintenance
   - NVIDIA 드라이버·라이브러리·toolkit과 커널 계열의 무인 갱신을 제외한다.
   - 다른 보안 업데이트/패키지 목록 갱신은 유지한다. 자동 재부팅과 오래된 커널 자동 삭제는 막는다.
   - apt-mark hold는 추가하지 않았다. 수동 apt 업그레이드는 별도 유지보수 절차로 관리해야 한다.
2. /etc/systemd/system/nvidia-cdi-refresh.service.d/20-test-gpu-readiness.conf
   - 기존 ExecCondition을 modinfo 기반으로 대체해 압축 모듈을 지원한다.
   - 정상 서비스 시작 때 modprobe nvidia → 최대20초 nvidia-smi → 기존 CDI 생성 순서다.
   - 서비스 시작 전체 상한45초. GPU를 unload/reload하거나 살아 있는 프로세스를 종료하지 않는다.
3. /etc/systemd/system/docker.service.d/20-test-gpu-cdi-order.conf
   - Docker가 CDI 준비 시도 이후 시작하도록 Wants/After를 추가했다.
   - Requires로 연결하지 않아 GPU 준비 실패가 비GPU Docker 서비스까지 필수 실패로 이어지지 않는다.
     단, 실패 시 GPU 컨테이너는 정상 기동을 보장하지 않으며 이를 후속 확인한다.

systemctl daemon-reload만 실행했다. 서비스/컨테이너 재시작·채널 조작·패키지 설치·모듈 reload·
실제 재부팅은0회다. 전후19개 컨테이너의 PID/기동시각/image/상태/재시작 정책과 두 Git 상태가 동일하다.

## 4. 부팅 준비 결과와 남은 검증

- 기존 GRUB 기본0번은6.8.0-146-generic이다. 기존 선택을 변경하지 않았고 next_entry override도 없다.
- 디스크의117/146용 NVIDIA 모듈은 모두595.99.02다. 의존성 dry-run과146용 vermagic/firmware 확인 PASS.
- Secure Boot disabled 상태를 보존했다. GRUB 문법·initramfs 읽기·dpkg audit PASS.
- initramfs에는 NVIDIA GPU DKMS 모듈이 들어 있지 않다. root filesystem의 설치 모듈을
  udev/modprobe로 적재하는 경로를 확인했으며 initramfs를 임의 재생성하지 않았다.
- /data는 fstab에 필수 mount로 등록돼 있고 nofail이 아니다. SSH socket과 Docker/CDI unit은 enabled다.
- APT 정책은 차단 대상17예시·비대상9예시로 확인했다. 다른 보안 업데이트는 활성 상태다.
- systemd verify PASS. 원래 vendor unit의 정규식 escape 경고는 남지만 해당 ExecCondition은
  override로 대체됐음을 실제 effective unit에서 확인했다. package 원본을 경고 제거 목적으로 수정하지 않았다.
- 현재 메모리에 로드된595.84와 임시 CDI는 그대로다. 현재 host nvidia-smi mismatch가 사라졌다고
  판정하지 않는다.595.99.02 GPU 접근과 실제 재부팅/컨테이너 재기동 수용은 다음 단계다.

## 5. 기존 기동 정책과 임시 설정

- ssimsai의 triton-server/rtsp-repeter는 always지만 ai-worker/API/fileserver/Flower/Redis/relay는 no다.
- Contextra analytics는 on-failure, Gateway/sidecar는 no, DB/Redis는 unless-stopped다.
  재부팅 후 일부 컨테이너가 정지 상태여도 기존 정책에 따른 결과일 수 있다. 정책을 바꾸지 않았다.
- 재개 때 기존 컨테이너/image와 실제 상태를 먼저 비교한다. compose up/recreate, 새 image 적용,
  ct의 pending transaction 활성화와 카메라 자동 Start는 이번 사전 준비 승인에 포함되지 않는다.
- /run/cdi/ssims-emergency-59584.json은 재부팅 시 사라지는 임시595.84 등록이다.
  새595.99.02 환경 위에 복원하지 않는다. 구 파일과 driver-root는 기존 GPU 복구 디렉터리에 보존돼 있다.
- /run/systemd/system/docker.service.d/90-contextra-export-temp.conf도 사라진다.
  DOCKER_TMPDIR=/data/docker-export-tmp 용도의 기존 임시 설정이며 이번에 영구 승격하지 않았다.
  나중에 대형 image export를 재개한다면 root 공간과 이 설정의 필요성을 따로 확인한다.
- root 여유는 약14GiB다. 이번 큰 백업은 /data에 저장했고 prune·원본 정리는 하지 않았다.

## 6. 사용자 수동 재부팅과 재개

1. 다른 세션의 미저장 편집을 저장하고, 진행 중인 중요한 작업을 멈춘다. 필요하면 사용 중인 채널도 Web에서 정상 Stop한다.
2. 위 백업 시각 이후 중요한 /tmp 자료를 만들었다면 바로 재부팅하지 말고 해당 자료 보존을 먼저 요청한다.
3. 이 작업의 최종 답변을 받은 뒤 test 호스트 터미널에서 sudo reboot를 실행한다. 컨테이너 내부가 아니다.
4. SSH 재접속이 되지 않으면 확인된 Proxmox/물리 콘솔로 부팅 상태를 확인한다. 반복 전원 차단을 하지 않는다.
5. 재접속 뒤 POST_REBOOT_PROMPT.ko.txt로 재개한다. 먼저 실제 커널·nvidia-smi·CDI·서비스 상태를 읽는다.
6. 필요한 기존 서비스 기동은 실제 상태와 영향 확인 후 진행하며, 실제 채널 Start/Stop·화면 수용은 사용자 단계다.

## 7. 설정 복구 경계

변경 전 세 신규 파일은 존재하지 않았다. 되돌릴 때는 reports/final-preservation.json의
new_configuration_hashes와 현재 파일을 비교하고, 사용자 후속 편집이 없을 때만 위3개 파일을
제거한 뒤 daemon-reload한다. 서비스 재시작은 별도 승인 대상이다. package 원본이나 디렉터리를
통째로 지우지 않는다. 이 복구는 설정 복구이며 NVIDIA 패키지/커널/DB/미디어 rollback이 아니다.

부팅 실패 시 GRUB Advanced options의117은 대체 커널 후보다.117용 NVIDIA 모듈도595.99.02이므로
이를595.84 드라이버 rollback이라고 표현하지 않는다. 콘솔에서 원인을 확인한 뒤 필요한 복구만 한다.

백업과 복구 파일은 사용자 확인 없이 자동 삭제하지 않는다. 정상 부팅과 두 프로그램 수용 후
임시 GPU 자료의 RETAIN/정리 여부를 다시 정한다. 새 호스트 설정3개는 승인된 지속 정책이다.