컨테이너 업데이트에 실패한 후 런타임을 교체하거나 롤백하거나 다시 생성하기 전에 영구 상태를 보호하여 Jellyfin을 복원하세요.
업데이트 실패의 원인은 이미지 문제, 환경 변수 변경, 디바이스 매핑 손실, 볼륨 설정 오류 또는 애플리케이션 마이그레이션 문제일 수 있습니다. 실패한 상태를 캡처하고 어떤 계층이 변경되었는지 확인하세요. 런타임과 데이터 중 실제로 실패한 항목을 파악하기 전까지 구성 디렉터리를 그대로 두는 것이 가장 안전합니다.
다시 이미지를 가져오기 전에 실패한 상태 고정
자동 업데이트와 재시작 루프를 비활성화하여 새로 시도할 때마다 로그, 이미지 태그 또는 애플리케이션 상태가 변경되지 않도록 하세요. 적용 중인 컨테이너 정의와 최초의 치명적 오류를 저장하세요.
이미 변경 전 Jellyfin 백업이 있다면 실패한 업그레이드를 훨씬 쉽게 되돌릴 수 있습니다. 백업이 없으면 런타임 장애가 상태 복구 문제로 이어질 수 있습니다.
이미지 다이제스트, 마운트, 디바이스, 환경 변수, 네트워크 모드 및 최근 로그를 기록하세요. 복구 대상이 아직 파악되지 않은 상태에서는 정리 또는 prune 명령을 실행하지 마세요.
무엇이든 다시 생성하기 전에 구성과 데이터베이스 보호
교체 가능한 이미지는 영구 Jellyfin 데이터베이스, 구성, 메타데이터 및 플러그인과 분리해야 합니다. 이전 또는 최신 바이너리가 해당 상태를 다시 열기 전에 읽기 전용 복사본이나 스냅샷을 생성하세요.
Jellyfin 구성 백업은 미디어 라이브러리 자체와 별도로 사용자 계정, 라이브러리 설정, 시청 기록 및 메타데이터를 보호합니다.
영구 경로를 두 번째 위치에 복사하고 소유권을 유지하세요. 컨테이너 영속성 경계는 깨끗한 런타임이 빈 서버를 생성하지 않고 다시 연결될 때만 올바른 것입니다.
실패한 계층 중 가장 작은 범위 복원
동일한 상태와 마운트에서 이전 이미지가 작동한다면 문제는 라이브러리가 아니라 업데이트 경로에 있습니다. 두 버전 모두 실패한다면 이미지 교체를 반복하지 말고 데이터 또는 권한을 별도로 조사하세요.
버전별 Jellyfin 시작 실패는 일반적인 스토리지 및 네트워크 변경 문제와 분리해서 확인해야 합니다.
복사한 상태 세트에 롤백 버전 하나 또는 정상 작동이 확인된 이미지 하나를 사용해 테스트하세요. 데이터베이스의 유일한 복사본에 마이그레이션을 반복해서 강제로 적용하지 마세요.
자동화를 재개하기 전에 ID, 라이브러리 및 재생 하나를 확인
컨테이너가 “실행 중” 상태에 도달했다고 해서 완전히 복원된 것은 아닙니다. 예상한 사용자, 라이브러리, 시청 상태, 경로 및 재생 동작이 돌아와야 합니다. 스캔과 연동 자동화는 새로운 쓰기 작업을 만들 수 있으므로 검증하는 동안 일시 중지해 두세요.
적절한 복원 테스트는 파일을 성공적으로 추출했다는 사실만으로 판단하지 않고 복구 후 애플리케이션 동작을 검증합니다.
서버 ID, 라이브러리 하나의 탐색, Direct Play 하나, 사용하는 경우 트랜스코딩 하나 및 재시작 하나를 확인하세요. 그 후에만 예약된 스캔과 자동 업데이트를 다시 활성화하세요.
지원 및 팁
더 읽어보기

Jellyfin을 실행한 채로 백업해야 할까요, 아니면 먼저 서비스를 중지해야 할까요?
간편하게 사용하려면 서비스가 중지된 상태에서 백업하는 것을 우선하세요. 애플리케이션 상태가 일관되게 캡처되고 복원이 테스트된 경우에만 라이브 스냅샷을 사용하세요.

아무도 스트리밍하지 않을 때 Jellyfin이 뜨겁거나 시끄럽게 작동하는 이유_久久爱
유휴 상태에서 발생하는 발열은 대개 백그라운드 작업이나 공유 호스트 워크로드를 의미하므로, 냉각이나 하드웨어를 변경하기 전에 활성 프로세스와 예약된 작업을 확인하세요.

Jellyfin을 복구하는 대신 언제 다시 구축해야 할까요?
런타임 드리프트가 문제이고 영구 상태가 백업되어 있다면 수리보다 재구축을 선택하세요. 유일하게 정상인 데이터베이스를 삭제하는 것을 “재구축”이라고 해서는 안 됩니다.

