ZFS, Btrfs, ext4는 모두 Plex 데이터를 저장할 수 있지만, 어떤 선택이 더 나은지는 통합 무결성 기능, Linux 네이티브 스냅샷, 또는 복구를 다른 계층에서 처리하는 더 단순한 파일 시스템 중 무엇을 중시하는지에 따라 달라집니다.
호환성과 복구 모델부터 확인하세요
Plex 성능만 보고 파일 시스템을 선택하지 마세요. 호스트 운영 체제, 풀 설계, 스냅샷 워크플로, 메모리 예산, 복구 도구, 백업 방식에 따라 스토리지 계층을 쉽게 운영할 수 있는지가 결정됩니다.
유용한 파일 시스템 선택 기준은 Plex 전용 벤치마크 점수가 아니라 Copy-on-Write, 체크섬, 스냅샷, 리소스 사용량입니다.
호스트 플랫폼이나 복구 프로세스가 확실하게 지원하지 못하는 옵션은 제외하세요. 더 많은 기능을 제공하더라도 운영자가 복원할 수 없는 파일 시스템은 Plex에 적합하지 않습니다.
스토리지 풀이 무결성 시스템의 핵심이라면 ZFS
ZFS는 체크섬 데이터, 스냅샷, 스크럽, 풀 스토리지, 다중 디스크 보호가 설계의 핵심일 때 가장 강력합니다. 그 대신 풀을 생성하기 전에 계획해야 하는, 더 명확한 설계 철학을 가진 스토리지 계층이라는 점을 고려해야 합니다.
ZFS 풀 수준 스토리지는 파일 시스템과 통합 무결성 및 풀 관리 기능을 결합하므로, 서버에서 이러한 기능을 실제로 활용할 때 가장 적합합니다.
무결성과 스냅샷에 대한 책임을 파일 시스템과 풀이 상당 부분 맡도록 하고, 해당 스택을 운영하는 데 익숙하다면 ZFS를 선택하세요.
Linux 네이티브 스냅샷 및 CoW 워크플로에는 Btrfs
Btrfs는 ZFS와 동일한 풀 모델을 요구하지 않으면서 체크섬, Copy-on-Write, 스냅샷, 압축, 서브볼륨을 Linux 파일 시스템 계층에 제공합니다. 컨테이너 및 스냅샷 워크플로가 이미 Btrfs를 중심으로 구성된 Linux 호스트에 적합할 수 있습니다.
Btrfs 스냅샷과 데이터 체크섬은 복구 및 무결성 도구를 제공하지만, 하드웨어, 이중화 구성, 복원 방식은 여전히 별도로 결정해야 합니다.
통합 Linux 기능이 실제 워크플로 문제를 해결하고, 계획한 이중화 모드를 직접 운영하고 복구할 준비가 되어 있다면 Btrfs를 선택하세요.
통합 기능보다 단순성이 중요하다면 ext4
성숙하고 복잡도가 낮은 파일 시스템을 원하며 스냅샷, 이중화, 체크섬, 백업을 다른 계층에서 처리할 의향이 있다면 ext4가 가장 강력한 기본 선택지입니다.
더 단순한 Linux 서버에서는 Plex 워크로드에 필요하지 않은 파일 시스템 기능을 추가하는 것보다 ext4의 저널링과 낮은 운영 부담이 더 유용할 수 있습니다.
Plex 상태 데이터와 대용량 미디어에 이미 검증된 백업 계획이 있다면 ext4로 충분할 수 있습니다. 또한 미디어 서버 스토리지 구성에서는 모든 장치에 하나의 파일 시스템을 강제하는 대신 스토리지 역할을 서로 다르게 구성할 수도 있습니다.
제품 비교
더 읽어보기

Plex용 쿼드 코어와 옥타 코어 CPU 비교: 혼합 클라이언트 동시 접속에는 어떤 제품이 적합할까요?
4코어는 주로 직접 재생에 적합하고, 소프트웨어 트랜스코딩이나 동시 호스트 작업이 측정된 기준치를 넘을 때 8코어가 비용만큼의 가치를 발휘합니다.

전용 Jellyfin 서버와 공유 앱 호스트: 어떤 경계가 적합할까요?
예측 가능한 미디어 처리와 복구를 원한다면 전용 호스팅을 선택하고, 워크로드가 가볍고 격리 수준을 측정할 수 있다면 공유 호스트를 선택하세요.

다중 사용자 홈 스트리밍에서 Jellyfin과 Plex 비교: 클라이언트 지원 범위와 제어 기능 중 무엇을 중시할까?
클라이언트 지원 범위가 관건이라면 Plex가 우세하고, 제어 권한이 관건이라면 Jellyfin이 우세합니다. 사용자가 명확하게 나뉜다면 둘 다 적합할 수 있습니다.

