Jellyfin 데이터 경로 설명: 반드시 유지해야 하는 것과 다시 구축할 수 있는 것

데이터베이스 상태, 구성, 메타데이터, 캐시, 임시 트랜스코딩 파일, 미디어를 서로 다른 데이터 역할로 취급하면 Jellyfin을 더 안전하게 운영할 수 있습니다.

모든 디렉터리에 동일한 스토리지 계층이나 백업 정책을 적용할 필요는 없습니다. 사용자 계정과 시청 상태는 런타임을 교체해도 유지되어야 하지만, 캐시와 트랜스코딩용 임시 작업 영역은 대개 다시 생성할 수 있으며 미디어는 별도의 원본 저장소에서 관리됩니다. 이러한 역할을 매핑하면 컨테이너 업데이트나 디스크 정리가 실수로 서버 초기화로 이어지는 일을 방지할 수 있습니다. 데이터가 깨끗한 런타임 재구성 이후에도 유지되어야 하는지에 따라 영속성을 정의하세요.

데이터베이스와 구성은 서버 상태를 정의합니다

데이터베이스와 구성에는 사용자, 라이브러리 정의, 환경설정, 시청 상태 및 기타 서버 식별 정보가 포함됩니다. 이를 잃어버리면 미디어 파일은 그대로 남아 있어도 서버 자체는 사실상 처음부터 시작하게 될 수 있습니다.

Jellyfin의 구성 상태에는 사용자 계정, 라이브러리 설정, 시청 기록, 메타데이터가 포함되며, 이러한 데이터는 대규모 미디어 파일과 별도로 보호해야 합니다.

이 상태는 교체 가능한 이미지나 패키지 외부의 영속 경로에 보관하세요. 영속적인 앱 데이터 레이아웃을 사용하면 런타임을 다시 생성한 후에도 서비스가 안정적인 위치에 다시 연결할 수 있습니다.

메타데이터는 중요하지만 데이터베이스와 동일하지 않습니다

일부 원본 정보를 복구할 수 있더라도 아트워크와 생성된 메타데이터는 규모가 커지면 다시 만드는 데 많은 비용이 들 수 있습니다. 복구 우선순위는 수작업으로 정리한 내용과 처리된 데이터가 얼마나 포함되어 있는지에 따라 달라집니다.

대용량 미디어는 HDD에 두고 컨테이너 데이터는 SSD에 보관하면 SSD 앱 데이터와 HDD 미디어를 분리하는 명확한 구조를 만들 수 있으며, 탐색 상태의 지연 시간과 대용량 미디어 저장소를 분리할 수 있습니다.

모든 백업 계층에 메타데이터를 포함할지 결정하기 전에 메타데이터의 용량과 재생성 비용을 측정하세요. 직접 편집했거나 재생성하기 어려운 자산은 폐기 가능한 캐시와 다르게 취급해야 합니다.

캐시와 트랜스코딩용 임시 작업 영역에는 만료 정책이 필요합니다

캐시와 진행 중인 트랜스코딩 출력은 장기적인 서버 식별 정보를 정의하는 것이 아니라 현재 작업을 가속하거나 지원하기 위해 존재합니다. 이를 무조건 보존하면 백업 용량이 늘어나고 오래된 임시 상태가 복원될 수 있습니다.

미디어 서버 스토리지 설계에서는 높은 빈도로 변경되는 임시 작업이 요구하는 지연 시간과 내구성이 다르므로 로컬 캐시와 영속 미디어를 분리합니다.

임시 작업 영역은 빠른 경로에 배치하고 여유 공간을 명시적으로 모니터링하세요. 백업에서 제외하기 전에 파일을 삭제한 후에도 서비스가 해당 영역을 다시 생성할 수 있는지 확인하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

미디어는 별도의 원본 저장 계층으로 유지해야 합니다

라이브러리 파일은 로컬 디스크나 NAS에 저장할 수 있으며 애플리케이션 상태보다 몇 배나 더 큰 용량을 차지할 수 있습니다. 따라서 데이터베이스 정책을 그대로 적용하지 말고 별도의 이중화 및 백업 정책을 결정해야 합니다.

백업의 용량과 변경량은 데이터셋에 따라 달라지므로 앱 상태와 대용량 미디어에 하나의 보존 모델을 적용하기는 어렵습니다.

각 역할에서 어떤 경로가 원본인지 문서화하고, Jellyfin 상태가 변경되지 않은 미디어 라이브러리에 다시 연결되는 복원 작업을 테스트하세요. 역할을 명확히 매핑해 두면 향후 스토리지 마이그레이션도 훨씬 덜 모호해집니다.