Jellyfin 앱 데이터, 캐시 및 백업을 분리하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Separate Jellyfin App Data, Cache, and Backups - Zima Store Online

Jellyfin 앱 데이터, 캐시, 백업을 분리하려면 재구축 후에도 반드시 남아야 하는 것, 다시 생성할 수 있는 것, 라이브 상태 저장 장치가 고장 난 뒤에도 사용 가능해야 하는 것을 먼저 구분해야 합니다. 소형 서버에서는 이 세 가지 역할이 하나의 물리적 SSD를 공유할 수 있지만, 수명 주기와 복구 정책까지 같아서는 안 됩니다.

영구 애플리케이션 상태에는 데이터베이스, 구성, 사용자 및 재생 상태, 동일한 서버로 복원하는 데 필요한 기타 파일이 포함됩니다. 활성 작업에서 더 이상 필요하지 않은 캐시와 트랜스코딩 작업 데이터는 폐기할 수 있습니다. 백업은 복구용 사본이므로, 복구 대상과 동일한 저장 경계에 의존해서는 안 됩니다.

영구 앱 데이터를 신뢰할 수 있는 상태 역할로 지정하기

먼저 Jellyfin의 영구 상태를 관리하는 호스트 경로 또는 볼륨을 매핑합니다. 컨테이너 배포에서는 이미지를 교체할 수 있지만, 컨테이너를 다시 만든 뒤 다시 연결해야 하는 것은 마운트된 상태 데이터입니다. 호스트 경로, 컨테이너 경로, 소유권, 파일 시스템, 최소 여유 공간, 백업 방법을 기록하세요.

최신 Jellyfin Docker Compose 구성은 미디어를 마운트하기 전에 영구 구성 디렉터리와 캐시 디렉터리를 분리합니다. 처음에는 두 디렉터리가 같은 SSD에 있더라도 이러한 경로 구분은 운영상 유용합니다.

문제 해결 중 삭제해도 된다고 생각하는 위치에 신뢰할 수 있는 데이터베이스를 두지 마세요. 캐시를 성공적으로 정리하는 작업이 사용자, 라이브러리, 시청 상태 또는 서버 ID를 초기화할 수 있어서는 안 됩니다.

캐시와 트랜스코딩 공간을 다시 만들 수 있는 작업 데이터로 취급하기

캐시는 반복 작업을 줄이거나 임시 처리 결과를 보관하기 위해 존재합니다. 캐시의 가치는 성능과 편의성이지 서버의 정체성이 아닙니다. 일반적인 백그라운드 작업과 트랜스코딩이 최고조에 달할 때를 감당할 만큼 용량을 확보하되, 전체 서버를 복원하지 않고도 다시 만들 수 있도록 하세요.

사용량 변동이 큰 캐시 또는 트랜스코딩 작업이 데이터베이스의 백업 정책을 좌우하지 않도록 하세요. 동일한 고속 장치에 두 역할이 있다면 별도의 할당량과 모니터링을 적용한 별도 디렉터리 또는 데이터셋을 사용하세요. 이렇게 하면 일시적인 폭증으로 데이터베이스 쓰기나 향후 복원에 필요한 여유 공간이 소진되는 것을 막을 수 있습니다.

탐색, 메타데이터, 상태 작업은 느려졌지만 순차적인 미디어 읽기는 정상이라면, ZimaSpace의 대화형 미디어 서버 상태를 SSD에 유지하는 방법 분석을 다음 테스트의 참고 자료로 활용할 수 있습니다. 대용량 미디어 라이브러리를 동일한 저장 작업으로 취급할 필요는 없습니다.

컨테이너는 폐기할 수 있지만 상태 데이터와 재구축 절차는 그렇지 않습니다

컨테이너는 다시 가져올 수 있지만, 배포 절차와 영구 데이터가 자동으로 다시 나타난다고 가정해서는 안 됩니다. Compose 또는 서비스 정의, 이미지 버전이나 태그 정책, 마운트 매핑, 서비스 ID, 필요한 시크릿 참조, 영구 Jellyfin 상태 데이터를 저장하세요.

이 Docker 볼륨 백업 절차의 실질적인 원칙은 유용한 복구 데이터가 폐기 가능한 컨테이너 자체가 아니라 볼륨, 바인드 마운트, 앱 데이터, 서비스 정의에 있다는 것입니다.

실행 중인 데이터베이스에서는 서비스가 작업 중일 때 모든 바이트를 복사하는 것보다 일관성이 중요합니다. 임의의 라이브 파일 복사본을 검증된 복구 지점으로 간주하지 말고, 배포 환경에 적합한 애플리케이션 지원 백업 경로 또는 제어된 중지/스냅샷 방식을 사용하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

라이브 상태 옆에 둔 백업만으로는 호스트 장애를 보장할 수 없습니다

라이브 데이터베이스 옆에 둔 백업은 실수로 인한 변경에 도움이 될 수 있지만, 운영 데이터를 제거할 수 있는 모든 풀 장애, 호스트 장애, 랜섬웨어, 도난 또는 정전에서 살아남지는 못합니다. 다른 장치나 관리 경계에 복구 사본을 보관하고, 이를 읽는 데 필요한 키 또는 자격 증명도 보호하세요.

셀프 호스팅 백업 계획은 상태 데이터, 시크릿, 복구 사본, 복원 지침을 함께 매핑해야 합니다. 이 셀프 호스팅 복구 감사는 스냅샷을 완전한 계획으로 간주하기보다 명백한 장애 범위를 벗어난 사본과 문서화된 재구축 입력값을 강조합니다.

백업 대상이 라이브 앱 풀과 동일한 캐시 보존 규칙이나 정리 명령으로 삭제되지 않도록 하세요. 섀시를 잠시 공유하더라도 백업은 별도의 역할입니다.

드라이브를 구매하거나 이동하기 전에 저장 역할을 매핑하기

역할	예시	다시 만들 수 있나요?	주요 정책
영구 앱 상태	데이터베이스, 구성, 사용자, 시청 상태, 플러그인/설정	저렴하게는 불가능	낮은 지연 시간, 여유 공간, 일관된 백업
캐시 / 임시 데이터	캐시, 트랜스코딩 임시 공간, 폐기 가능한 중간 결과	예	용량, 성능, 제한된 정리
백업	버전 관리 상태 사본, 배포 절차, 복구 메타데이터	아니요. 복구 원본입니다	독립적인 장애 도메인, 보존 정책, 복원 테스트
미디어	영화, 드라마, 가족 동영상	원본에 따라 다름	용량 및 별도의 보호 정책

이 매핑은 흔히 발생하는 재설계 실수를 막아 줍니다. 앱 상태 지연만 문제가 되었는데 모든 데이터를 가장 빠른 디스크로 옮기거나, 컨테이너를 재구축하는 데 필요한 서비스 정의는 빠뜨린 채 모든 임시 파일을 백업하는 실수를 방지할 수 있습니다.

폐기 가능한 복원으로 분리를 검증하기

Jellyfin 상태 데이터를 새 경로 또는 격리된 호스트에 복원하고, 복사한 배포 정의가 해당 위치를 가리키도록 설정한 뒤, 대표적인 미디어에 비파괴적으로 접근할 수 있게 하고, 원래 캐시 없이 서비스를 시작하세요. 캐시는 비어 있는 상태에서 시작하더라도 서버 ID, 라이브러리, 사용자, 설정이 예상대로 복원되어야 합니다.

이 구분은 백업을 격리된 대상에 복원하고 운영 상태를 빌리지 않은 채 검증할 때 비로소 측정할 수 있습니다. 테스트 Jellyfin 인스턴스는 복구 사본에서 시작하고, 필요한 경로를 다시 연결하며, 라이브 볼륨이 복원을 몰래 완료하고 있지 않다는 사실을 입증해야 합니다.

캐시를 삭제해도 ID를 잃지 않고, 라이브러리를 처음부터 다시 분석하지 않아도 런타임을 재생성할 수 있으며, 라이브 앱 데이터 장치를 사용할 수 없다고 가정한 상황에서 하나 이상의 백업으로 서비스를 복원할 수 있다면 이 구성이 제대로 작동하는 것입니다.