Jellyfin용 SSD, HDD 및 백업 용량 선택 방법

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

Jellyfin 스토리지는 빠른 애플리케이션 및 스크래치 공간, 경제적인 미디어 용량, 독립적인 복구 용량이라는 세 가지 용량 문제로 나누어 구매해야 합니다. 매우 큰 드라이브 하나를 구매하고 이를 “Jellyfin 스토리지”라고 부르면 성능, 성장, 복구를 예측하기가 더 어려워집니다.

현재 라이브러리와 측정된 Jellyfin 데이터를 기준으로 시작하고, 가장 큰 임시 작업 피크를 더한 다음, 스토리지를 사용할 기간 동안의 미디어 증가량을 예상하고, 실제 운영 스토리지와 별도의 장애 영역에 백업 세대를 위한 공간을 산정하세요. 드라이브 라벨에 표시된 원시 용량이 아니라 중복성을 적용한 후의 사용 가능 용량을 기준으로 삼으세요.

앱 데이터와 임시 피크를 위한 SSD 용량 산정

Jellyfin의 데이터베이스, 메타데이터, 아트워크, 로그 및 기타 애플리케이션 파일은 낮은 지연 시간의 이점을 누리는 랜덤 I/O를 발생시킵니다. 트랜스코드 캐시는 동시에 여러 변환이 진행될 때 급증할 수 있는 또 다른 임시 용량 요구 사항을 만듭니다.

현재 Jellyfin 스토리지 지침에 따르면 적당한 규모의 데이터베이스도 수십 GB까지 커질 수 있으며, 트랜스코드 폴더는 변환 중인 원본 미디어 크기에 일시적으로 근접할 수 있습니다. 따라서 현재 데이터베이스 자체가 작더라도 지나치게 작은 부팅 SSD는 위험할 수 있습니다.

현재 앱 데이터 크기와 실제로 발생한 가장 큰 트랜스코드 피크를 측정하세요. SSD를 표시 용량까지 가득 채우지 말고 업데이트, 임시 파일, 증가분을 위한 여유 공간을 추가하세요.

미디어 증가량과 사용 가능한 중복성을 기준으로 HDD 용량 산정

대용량 미디어는 일반적으로 용량과 순차 처리량을 우선합니다. 현재 미디어 크기, 현실적인 연간 추가량, 그리고 스토리지 구성을 재구축하기 전까지 유지할 것으로 예상되는 기간을 계산하세요.

그런 다음 예상 목표 용량을 미러 또는 패리티 오버헤드를 적용한 사용 가능 용량으로 환산하세요. 12TB 드라이브 두 개를 미러 구성해도 사용 가능한 미디어 용량은 24TB가 아니며, 스냅샷이나 예약된 여유 공간으로 인해 안전한 작업 용량으로 간주해야 할 공간은 더 줄어들 수 있습니다.

미디어 파일을 제외한 Jellyfin 스토리지 오버헤드에 대한 ZimaSpace 분석은 이러한 분리를 뒷받침합니다. 영구 앱 데이터, 생성된 자산, 임시 트랜스코드, 원본 미디어는 같은 속도로 증가하지 않습니다.

기본적으로 SSD 속도가 아니라 작업 부하에 맞춰 미디어 용량 구매

대용량 영화와 에피소드의 경우 일반적으로 SSD의 지연 시간보다 순차 처리량이 더 중요합니다. 여러 독립 스트림과 동시 스캔은 탐색 부담을 높일 수 있지만, 상태가 양호한 HDD 풀도 상당한 미디어 대역폭을 제공할 수 있습니다.

지속적인 서버 쓰기와 예측 가능한 재구축 동작에 적합한 드라이브 모델과 기록 기술을 선택하세요. 무소음, 물리적 크기, 전력 소비 또는 측정된 혼합 I/O 동작이 훨씬 높은 TB당 비용을 정당화할 때만 대용량 미디어를 SSD로 옮기세요.

미디어 계층은 SSD가 항상 더 빠르다는 일반적인 주장보다 총 비트레이트와 유지 관리 작업 부하를 기준으로 선택해야 합니다.

RAID 용량과 별도로 백업 용량 계산

RAID, 미러, ZFS 중복성 또는 Btrfs 미러는 일부 드라이브 장애 후 가용성을 높여 주지만, 삭제된 메타데이터, 손상된 애플리케이션 상태, 잘못된 업그레이드, 랜섬웨어 피해 또는 관리자 실수를 보존해 주지는 않습니다.

3-2-1 모델은 서로 다른 미디어에 여러 복사본을 만들고 그중 최소 하나는 오프사이트에 보관할 것을 권장합니다. Jellyfin에서는 대체할 수 없는 미디어, 다시 확보할 수 있는 리핑 미디어, 애플리케이션 상태를 동일한 깊이로 백업해야 하는지 별도로 결정하세요.

애플리케이션 상태 백업은 수 TB 규모의 미디어 아카이브에 비해 작으므로 전체 미디어 라이브러리에 다른 백업 전략을 적용하더라도 사용자, 시청 진행률, 메타데이터, 구성을 자주 보호하는 것은 경제적일 수 있습니다.

드라이브 주문 전에 용량 워크시트 사용

스토리지 역할 측정할 입력값 용량 결정
SSD 앱 데이터 현재 데이터 + 증가량 영구 저지연 여유 공간
SSD 트랜스코드 스크래치 가장 큰 파일 × 동시 변환 수 임시 피크 + 여유 공간
HDD 미디어 현재 라이브러리 + 연간 증가량 중복성 적용 후 사용 가능 용량
로컬 백업 보호 범위 × 보존 세대 수 독립적인 복원 용량
오프사이트 백업 대체할 수 없는 범위 + 보존 기간 별도의 재해 복구 복사본

세 계층을 모두 같은 증가율로 구매하지 마세요. 트릭플레이를 활성화하거나, 백업 보존 기간을 변경하거나, 4K 리먹스를 추가하거나, 주로 Direct Play를 사용하던 환경에서 트랜스코딩을 자주 사용하는 환경으로 바꾼 후에는 다시 계산하세요.

FAQ

Jellyfin 미디어 라이브러리 전체를 SSD에 저장해야 하나요?

대부분의 경우 그렇지 않습니다. SSD는 Jellyfin 앱 데이터와 임시 랜덤 I/O 경로에 사용할 때 가장 큰 가치를 제공합니다. 총 처리량과 탐색 동작이 실제 스트림 조합을 충족한다면 HDD는 대용량 순차 미디어 읽기에 여전히 비용 효율적입니다.

Jellyfin에는 백업 공간이 얼마나 필요한가요?

무엇을 보호하고 복구 지점을 몇 개나 보존하는지에 따라 달라집니다. 애플리케이션 상태 백업은 미디어 아카이브와 별도로 용량을 산정한 다음, 원시 스토리지 풀 크기를 그대로 복사하지 말고 보호 범위에 현실적인 보존 기간을 적용해 계산하세요.

구매 가이드

더 읽어보기

비밀번호 보관함 서버 가용성 위험 가이드
Oct 03, 2026

비밀번호 보관함 서버 가용성 위험 가이드

캐시된 액세스, 독립적인 복구 자격 증명, 테스트된 복원 절차, 그리고 다른 운영자가 있어 장애로 인한 잠금을 방지할 수 있을 때만 비밀번호 보관함을 직접 호스팅하세요.

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.