Plex에는 백업 복사본의 보편적인 개수가 정해져 있지 않습니다. 장애가 발생하기 전에 확인된 정상 상태로 돌아갈 수 있을 만큼 충분히 검증된 기록이 필요합니다.
보존 기간은 Plex 상태가 얼마나 자주 변경되는지, 손상을 얼마나 빨리 발견하는지, 업데이트나 실수로 인한 라이브러리 작업 후 얼마나 이전 상태로 되돌아가야 할 수 있는지를 기준으로 정해야 합니다. 검증되지 않은 복사본을 많이 쌓아도 모든 버전이 같은 문제가 발생한 후에 생성되었다면 실패할 수 있습니다. 먼저 복구 시점과 복구 시간을 정의한 다음, 이를 기준으로 일일·주간·스냅샷 계층을 선택하세요.
되돌려야 하는 장애부터 파악하세요
실수로 인한 삭제, 잘못된 업데이트, 조용히 발생한 데이터베이스 손상, 디스크 전체 손실은 각각 발견되는 시점이 다릅니다. 가장 최신 백업 하나만으로는 빠르게 발견되는 장애만 보호할 수 있습니다.
보존 기간은 단순히 최신 복사본을 보존하는 것이 아니라, 장애가 발생하기 전에 확보된 확인된 정상 복구 지점까지 포함해야 합니다.
대응하려는 장애를 나열하고, 발견까지 현실적으로 걸릴 수 있는 가장 긴 시간을 추정하세요. 먼저 복사본 개수를 정하기보다 해당 기간을 넘어서 버전 기록을 보존해야 합니다.
둘 이상의 시간 단위를 사용하세요
최근의 자주 생성된 복사본은 현재 시청 상태와 설정을 보호하고, 오래된 드문 복사본은 늦게 발견되는 문제로부터 보호합니다. 계층화된 일정이라면 모든 스냅샷을 영구적으로 보존하지 않고도 두 가지를 모두 처리할 수 있습니다.
시점별 버전을 사용하면 매 순간의 전체 중복 복사본을 보존하지 않고도 최근 및 오래된 복구 지점을 유지할 수 있습니다.
최근 복사본은 짧은 간격으로 생성하고, 오래된 복사본은 사용 가능한 저장 공간에 맞춰 더 긴 간격으로 생성하세요. 각 계층이 언제 만료되는지와 어떤 장애를 대상으로 하는지 문서화하세요.
보존 정책으로 오프디바이스 보호를 대신하지 마세요
같은 고장 난 디스크에 복사본을 열 개 보관해도 여전히 하나의 장애 도메인에 속합니다. 보존과 중복성은 서로 다른 문제를 해결합니다.
백업 용량과 변경량은 Plex의 활성 상태 경로와 별도로 계획해야 합니다. 그래야 보존 데이터가 하나의 장애 도메인 안에만 남지 않습니다.
최소한 하나의 복구 복사본은 활성 앱 데이터 장치 외부에 보관하고, 해당 복사본을 독립적으로 테스트하세요. 홈 서버 토폴로지는 백업 장애 도메인을 같은 풀 안에 숨기지 않고 명확하게 드러내야 합니다.
복원 테스트를 통과한 후에만 정리하세요
오래된 복사본으로 예상한 데이터베이스, 메타데이터, 식별 정보를 실제로 복원할 수 있을 때만 보존 정책이 의미를 가집니다. 정기적으로 테스트해야 하는 대상이 순환 작업 하나뿐이어서는 안 됩니다.
정리하기 전에 최근 복사본과 오래된 복사본을 모두 임시 Plex 인스턴스에 복원하세요. 복원 테스트를 통해 완료된 백업이 실제로 복구 가능한지 확인할 수 있습니다.
오래된 백업이 반복해서 실패하거나 문서화되지 않은 경로에 의존한다면 보존 기간을 줄이기 전에 캡처 방식을 수정하세요. 보존 정책은 단순히 타임스탬프가 아니라 신뢰할 수 있는 복구 선택지를 보존해야 합니다.
지원 및 팁
더 읽어보기

Jellyfin이 다른 컨테이너와 GPU 또는 가속기를 안전하게 공유할 수 있나요?
GPU 공유는 조건부로 지원됩니다. 먼저 장치가 표시되는지와 드라이버가 지원되는지 확인한 다음, 두 워크로드를 모두 실행하고 소프트웨어 폴백이 발생하는지 지켜보세요.

Jellyfin 오류가 클라이언트에서 발생했는지 서버에서 발생했는지 확인하는 방법
Jellyfin 오류는 한 기기에서만 발생하면 클라이언트 문제이고, 동일한 경로에서 여러 클라이언트가 실패하며 로그 내용도 일치하면 서버 문제입니다.

Jellyfin 캐시 및 임시 저장소 구성 방법
지속적인 상태 데이터, 재구축 가능한 캐시, 임시 트랜스코딩 저장 공간을 분리한 다음 실제 재생 테스트로 용량과 권한을 확인하세요.

