Jellyfin을 복구하는 대신 언제 다시 구축해야 할까요?
런타임을 새로 배포하는 것보다 신뢰하기 어려워졌다면 Jellyfin을 재구축하되, 시작하기 전에 영구 상태를 보존하고 검증하세요.
마운트 또는 권한 오류처럼 원인을 알고 되돌릴 수 있다면 복구가 더 낫습니다. 이미지 이력, 패키지, 임시 수정, 알 수 없는 구성 드리프트 때문에 수정할 때마다 또 다른 변수가 생긴다면 런타임을 새로 구축하는 편이 좋습니다. 판단 기준은 문제가 발생한 계층을 특정할 수 있고, 유지하려는 상태를 증명할 수 있는지 여부입니다.
단일 종속성 문제가 명확하다면 복구하세요
누락된 마운트, 잘못된 UID, 만료된 인증서 또는 손상된 플러그인 하나는 정상적인 서버를 새로 구성하는 것보다 기존 환경에서 복구하는 편이 대개 저렴합니다. 근본 원인이 이미 격리된 상태라면 재구축은 마이그레이션 위험만 높입니다.
USE 방법은 하드웨어나 아키텍처를 변경하기 전에 리소스 또는 오류 경계에서 진단할 것을 권장합니다.
재현 가능한 단일 장애를 수정한 뒤 원래 워크플로를 다시 테스트하세요. 데이터베이스 상태를 건드리지 않고 같은 증상이 사라진다면 재구축은 불필요했던 것입니다.
런타임 드리프트가 가장 큰 미지수라면 재구축하세요
오래 실행된 호스트에는 패키지 변경, 수동 수정, 오래된 환경 변수, 변경되는 태그에서 재생성된 컨테이너가 누적될 수 있습니다. 선언적인 클린 런타임은 또 다른 패치보다 감사하기 쉬울 수 있습니다.
서비스 정의와 영구 볼륨을 명시하면 클린 재구축을 예측 가능한 방식으로 진행할 수 있습니다.
현재 정의를 내보내고, 영구 경로를 식별한 다음, 복사한 상태 세트를 기준으로 클린 런타임을 생성하세요. 런타임을 교체하는 동안에도 영구 앱 데이터 경계는 변경되지 않아야 합니다.
데이터를 삭제하면서 재구축하지 마세요
애플리케이션이 고장 났다고 데이터베이스를 삭제하는 것은 런타임 재구축이 아니라 상태 초기화입니다. 손상이 입증되고 복구 계획이 마련된 경우가 아니라면 사용자, 시청 상태, 메타데이터 및 구성을 보존하세요.
변경 전 백업은 롤백과 재구성을 가르는 차이가 될 수 있습니다. 한 업그레이드 복구 경험에서도 새 버전이 사용할 수 없을 정도로 느려지기 전에 백업을 확보해 둔 것이 중요했습니다.
무엇을 폐기할지 결정하기 전에 장애 상태를 백업하고 데이터베이스 무결성을 테스트하세요. 교체 인스턴스의 검증이 끝날 때까지 원본 증거를 보존하세요.
클린 복원을 승인 테스트로 사용하세요
가장 확실한 재구축 검증은 문서화되지 않은 호스트 수정 없이 새로 설치한 환경이 알려진 상태와 미디어에 다시 연결되는지 확인하는 것입니다. 이 과정이 성공하면 기존 런타임을 자신 있게 폐기할 수 있습니다.
테스트된 복구 계획은 “파일이 복사되었다”는 단계에서 멈추지 않고 복원 후 서비스를 실제로 사용할 수 있는지 확인합니다.
사용자, 라이브러리 수, 시청 기록, Direct Play 한 번, 트랜스코딩 한 번, 예약 작업 및 재시작을 검증하세요. 재구축에 여전히 필요했던 모든 수동 단계를 문서화하세요.
추천 제품
지원 및 팁
더 읽어보기
Jellyfin을 실행한 채로 백업해야 할까요, 아니면 먼저 서비스를 중지해야 할까요?
간편하게 사용하려면 서비스가 중지된 상태에서 백업하는 것을 우선하세요. 애플리케이션 상태가 일관되게 캡처되고 복원이 테스트된 경우에만 라이브 스냅샷을 사용하세요.
아무도 스트리밍하지 않을 때 Jellyfin이 뜨겁거나 시끄럽게 작동하는 이유_久久爱
유휴 상태에서 발생하는 발열은 대개 백그라운드 작업이나 공유 호스트 워크로드를 의미하므로, 냉각이나 하드웨어를 변경하기 전에 활성 프로세스와 예약된 작업을 확인하세요.
Jellyfin은 백그라운드 작업을 위해 얼마나 많은 여유 저장 공간을 유지해야 하나요?
Jellyfin에 모든 경우에 적용되는 보편적인 여유 공간 비율은 없습니다. 지속적인 증가량과 일시적인 최대 사용량을 따로 측정한 다음, 두 수치보다 여유 있게 공간을 확보하세요.
