업그레이드 중 Jellyfin 구성 손실을 방지하는 방법
애플리케이션 상태와 교체 가능한 런타임을 서로 별개의 복구 대상으로 취급하여 업그레이드 중 Jellyfin 구성 손실을 방지하세요.
패키지 수준의 업그레이드는 성공하더라도 변경된 마운트, 사용자 ID, 장치 매핑 또는 마이그레이션으로 인해 Jellyfin이 새로 설치된 것처럼 보일 수 있습니다. 예방 조치는 막연히 “백업을 수행하는 것”이 아니라, 상태가 정확히 어디에 저장되는지 파악하고 일관되게 캡처하며 실행 중인 정의를 기록하고 복원할 수 있는지 검증하는 것입니다.
업그레이드 전에 실제 영구 경로를 매핑하세요
컨테이너 내부에 표시되는 경로가 백업되는 호스트 경로라고 가정하지 마세요. 데이터베이스, 구성, 메타데이터 및 플러그인 상태가 실제로 포함된 바인드 마운트 또는 명명된 볼륨을 확인하세요.
볼륨 정의와 서비스 경계가 배포 구성에 명시되어 있으면 컨테이너 스토리지를 이식 가능한 상태로 유지할 수 있습니다.
모든 영구 마운트에 대해 호스트 경로, 컨테이너 경로, 소유권 및 파일 시스템을 기록하세요. 상태 위치를 확실하게 식별할 수 없다면 업그레이드를 연기하세요.
변경 전에 일관된 복사본을 생성하세요
가장 유용한 복구 지점은 새 버전이 데이터베이스를 수정하기 전에 생성한 복구 지점입니다. 쓰기가 진행 중일 때 생성한 파일 복사본은 중지된 서비스의 백업이나 일관된 스냅샷보다 신뢰하기 어려울 수 있습니다.
별도의 Jellyfin 구성 백업은 다시 만들기 어려운 상태를 보존하면서 대용량 미디어는 자체 보호 경로에 그대로 둘 수 있게 합니다.
백업을 생성하여 운영 중인 구성 장치 외부에 저장하고, 타임스탬프와 버전을 함께 기록하세요. 영구 앱 데이터 레이아웃을 사용하면 이미지 자체를 복사하지 않고도 상태를 백업할 수 있어야 합니다.
데이터만큼 신중하게 런타임 정의를 기록하세요
완벽한 데이터베이스 백업이 있어도 재생성한 컨테이너 정의에 해당 설정이 없으면 하드웨어 가속, 포트, DNS, 장치 또는 권한을 복원할 수 없습니다. Compose 또는 플랫폼 구성도 복구 세트의 일부로 취급하세요.
안정적인 서비스 ID로 컨테이너를 실행하려면 업그레이드와 호스트 파일 시스템 전반에서 예측 가능한 UID 및 GID 매핑이 필요합니다.
비밀 정보를 제외한 실제 배포 정의를 내보내거나 커밋하세요. 롤백이 기억에 의존하지 않도록 이미지 다이제스트와 장치 매핑을 기록하세요.
이전 버전을 제거하기 전에 복구 경로를 테스트하세요
새 버전이 재시작을 견디고 백업을 찾아 열 수 있는지 확인한 후에 정리 작업을 수행해야 합니다. 롤백을 한 번도 연습하지 않았다면 이전 이미지와 스냅샷을 삭제하는 순간 가장 저렴한 복구 옵션이 사라집니다.
테스트된 복원 경로는 백업을 단순히 복구에 사용할 수 있다고 가정하는 상태에서 실제로 사용 가능한 애플리케이션 상태를 재구축할 수 있는 상태로 바꿔 줍니다.
사용자, 라이브러리, 메타데이터, 재생 한 건 및 재시작 한 번을 검증하세요. 새 버전이 예상된 마이그레이션과 정상적인 백그라운드 작업을 완료할 때까지 업그레이드 전 복구 세트를 유지하세요.
추천 제품
지원 및 팁
더 읽어보기
Jellyfin을 실행한 채로 백업해야 할까요, 아니면 먼저 서비스를 중지해야 할까요?
간편하게 사용하려면 서비스가 중지된 상태에서 백업하는 것을 우선하세요. 애플리케이션 상태가 일관되게 캡처되고 복원이 테스트된 경우에만 라이브 스냅샷을 사용하세요.
아무도 스트리밍하지 않을 때 Jellyfin이 뜨겁거나 시끄럽게 작동하는 이유_久久爱
유휴 상태에서 발생하는 발열은 대개 백그라운드 작업이나 공유 호스트 워크로드를 의미하므로, 냉각이나 하드웨어를 변경하기 전에 활성 프로세스와 예약된 작업을 확인하세요.
Jellyfin을 복구하는 대신 언제 다시 구축해야 할까요?
런타임 드리프트가 문제이고 영구 상태가 백업되어 있다면 수리보다 재구축을 선택하세요. 유일하게 정상인 데이터베이스를 삭제하는 것을 “재구축”이라고 해서는 안 됩니다.
