성장하는 Jellyfin 설정에 필요한 저장 공간은 얼마나 될까요?

현재 라이브러리와 예상 증가량, 운영 여유 공간을 고려해 충분한 실사용 미디어 용량을 구매한 다음, Jellyfin 앱 데이터와 백업은 별도의 스토리지 요구 사항으로 산정하세요.

드라이브 개수보다 용량 산정 공식부터 시작하세요

간단한 계획 모델을 사용하세요. 목표 실사용 미디어 용량 = 현재 라이브러리 + 계획 기간 동안 예상되는 추가 데이터 + 작업 여유 공간입니다. 첫 번째 항목은 현재 스토리지에서 측정하고, 추가 데이터는 최근 6~12개월의 실제 증가량을 기준으로 추정하세요. 또한 드라이브를 추가하거나 교체할 의향이 있는 주기에 맞춰 계획 기간을 정하세요.

이 모델은 “사용자당 XTB”보다 낫습니다. 사용자는 예측 가능한 속도로 스토리지를 소비하지 않기 때문입니다. 해상도, 코덱 효율, 리먹스 파일과 압축 파일의 차이, 홈 비디오 캡처, 보관 정책에 따라 연간 증가량은 가구원 수보다 훨씬 크게 달라질 수 있습니다.

기록이 없다면 보수적으로 시작하고 몇 달 후 다시 측정하세요. 목표는 완벽한 5년 예측이 아니라, 이미 용량이 부족한 제품을 구매하는 일을 피하면서도 실제로 사용할 근거가 없는 용량에 큰 추가 비용을 지불하지 않는 것입니다.

미디어 용량과 Jellyfin 앱 데이터 용량을 분리하세요

Jellyfin 자체에도 운영체제, 데이터베이스, 메타데이터, 캐시, 생성 이미지, 임시 트랜스코딩 데이터용 공간이 필요합니다. 이러한 파일은 비디오 라이브러리보다 훨씬 작지만 성능 요구 사항은 다릅니다.

Jellyfin 공식 하드웨어 가이드는 운영체제, Jellyfin 파일, 트랜스코딩 캐시를 위한 계획 기준으로 약 100GB의 SSD 공간을 권장하며, 원본 파일이 크거나 동시 트랜스코딩이 발생하면 임시 공간 요구량이 늘어날 수 있다고 설명합니다.

이 SSD 용량을 미디어 라이브러리 용량으로 사용하지 마세요. 미디어 용량은 수TB에 달할 수 있지만, 앱 데이터는 낮은 지연 시간의 스토리지에서 이점을 얻습니다. 모든 데이터를 하나의 초대형 SSD에 저장하는 것은 적당한 고속 스토리지 계층과 경제적인 대용량 스토리지를 함께 구성하는 것과는 대개 다른 선택입니다.

향후 영화뿐 아니라 운영을 위한 여유 공간도 확보하세요

여유 공간은 운영 용량입니다. 가져오기, 파일 이동, 임시 복사, 파일 시스템 유지 관리, 패리티 재구축, 스냅샷, 트랜스코딩 세그먼트는 풀이 거의 가득 차면 모두 더 어려워집니다. 스토리지 기술과 유지 관리 방식에 맞는 여유 공간을 남기고, 사용률 100%를 목표로 계획하지 마세요.

증가량은 한꺼번에 발생할 수도 있습니다. 카메라 아카이브, 가족 비디오 디지털화 프로젝트, 일회성 컬렉션 이전으로 인해 한 주말에 평소 한 달 동안 추가되는 미디어보다 더 많은 데이터가 생길 수 있습니다. 이러한 프로젝트가 예정되어 있다면 일반적인 비율에 숨기지 말고 명시적으로 포함하세요.

교체할 수 없는 개인 미디어의 경우, ZimaSpace의 홈 미디어 서버 가이드는 가족 비디오를 앱 캐시나 가져오기 영역에 의존하지 않고, 독립적으로 백업할 수 있는 명확한 미디어 폴더에 보관할 것을 권장합니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

중복성을 백업 용량으로 계산하지 마세요

패리티, 미러링, RAID는 드라이브 고장 후 가용성을 높일 수 있지만, 삭제, 손상, 랜섬웨어, 인클로저 고장에 대비한 독립적인 복구 사본을 만들어 주지는 않습니다. 백업 용량은 기본 어레이의 디스크 수가 아니라 복구해야 하는 데이터의 양을 기준으로 산정하세요.

교체 가능한 모든 미디어 파일을 반드시 두 번째 전체 사본으로 보관할 필요는 없습니다. 라이브러리를 분류하세요. 교체할 수 없는 홈 비디오와 엄선한 개인 콘텐츠는 전체 백업이 적합할 수 있지만, 교체 가능한 미디어에는 다른 정책을 적용할 수 있습니다. Jellyfin 앱 상태는 용량이 작기 때문에 별도 백업을 자주 수행하기가 일반적으로 어렵지 않습니다.

Jellyfin 백업 기능은 데이터베이스와 선택한 메타데이터 관련 데이터를 보호할 수 있습니다. 백업 대상에도 충분한 여유 공간이 필요하며, 활성 앱 데이터 볼륨과 동일한 장애 영역 외부에 저장해야 합니다.

더 큰 용량이 있다는 이유가 아니라 증가 기준에 도달했을 때 업그레이드하세요

예상 실사용 여유 공간이 다음 유지 관리 시점까지 필요한 공간보다 줄어들거나, 현재 섀시가 다음으로 적절한 드라이브를 추가할 수 없을 때 업그레이드가 정당화됩니다. 이는 성능 기준이 아니라 용량 기준입니다.

현재 풀이 측정 결과 수년간 사용할 여유가 있다면, 더 큰 인클로저를 구매하거나 정상적으로 작동하는 드라이브를 조기에 교체해도 일상적인 이점은 거의 없을 수 있습니다. 반대로 모든 베이가 사용 중이고 연간 증가량을 예측할 수 있다면, 현재 TB당 최저 비용을 선택하는 것보다 확장 유연성이 더 중요할 수 있습니다.

ZimaCube 2와 같은 다중 베이 플랫폼은 측정된 증가량, 백업 구성 또는 추가 서비스에 이러한 스토리지 폼 팩터가 필요할 때만 적합합니다. 먼저 실사용 용량과 복구 사본을 계산하는 일을 대신해 주지는 않습니다.

구매를 확정하기 전에 이 점검표를 사용하세요

스토리지를 구매하기 전에 현재 미디어 크기, 연간 순증가량, 계획 기간, 최소 여유 공간, 독립적인 백업이 필요한 데이터의 양 등 다섯 가지 수치를 기록하세요. 그런 다음 선택한 중복성 구성 후 남는 실사용 용량이 얼마인지 확인하세요.

또한 드라이브 인터페이스, 베이 수, 파일 시스템 또는 스토리지 풀 확장 방식, 소음, 전력 소비, 교체 절차를 확인하세요. TB당 가격은 저렴하지만 실제 서버에서 추가, 냉각 또는 교체가 까다로운 드라이브는 전체 소유 비용을 높일 수 있습니다.

계획 기간을 운영 여유 공간과 현실적인 백업 경로를 갖춘 상태로 충족하면 설계를 마무리하세요. 그 이후의 추가 용량은 선택적인 보험일 뿐 Jellyfin 성능 업그레이드는 아닙니다.