Plex 구성 vs 캐시 vs 사용자 데이터: 실제로 영구 보존해야 하는 것은 무엇일까요?

서버와 라이브러리를 정의하는 Plex 상태 데이터는 영구 보존하고, 복구 설계상 필요하지 않다면 임시 캐시와 트랜스코딩 데이터는 다시 생성할 수 있는 데이터로 취급하세요.

핵심은 폴더 크기가 아니라 복구 가능성입니다. 구성, 데이터베이스, 메타데이터, 아트워크, 시청 상태 참조 정보와 서버 식별 정보는 일관되게 다시 만드는 일이 어렵거나 번거롭지만, 임시 트랜스코딩 파일과 많은 캐시 아티팩트는 재생성할 수 있습니다. 각 경로를 어디에 둘지 결정하기 전에 삭제 후 어떤 일이 발생하는지 기준으로 분류하세요.

서버 상태는 설정 파일 하나보다 훨씬 많습니다

Plex 배포 환경은 웹 인터페이스에 표시되는 환경설정뿐 아니라 여러 영구 파일로 정의됩니다. 라이브러리 데이터베이스와 메타데이터 디렉터리에는 복원된 인스턴스가 기존 인스턴스와 동일하게 보이도록 하는 관계 정보와 서버 상태가 저장됩니다.

Plex 메타데이터 저장소에는 데이터베이스, 아트워크, 인덱스 및 기타 서버 상태 파일이 포함됩니다.

마운트된 모든 Plex 경로를 나열하고, 동일한 라이브러리와 메타데이터를 새 호스트에서 재현하는 데 필요한 경로를 표시하세요. 경로에 서버 데이터베이스나 메타데이터 상태가 포함되어 있다면 영구 백업 세트에 추가하세요. 교체 가능한 런타임 외부에 영구 컨테이너 데이터를 보관하는 것은 다시 만들 수 있는 계층과 컨테이너 교체 후에도 보존해야 하는 상태를 분리하는 데 도움이 됩니다.

캐시는 유용하지만 대개 다시 만들 수 있습니다

캐시는 라이브러리의 기준 사본이 아니어도 지연 시간을 줄일 수 있습니다. 캐시가 예열된 상태를 잃으면 서버가 한동안 느리게 느껴질 수 있지만, 데이터베이스를 잃는 것과 동일하게 취급해서는 안 됩니다.

Linux 페이지 캐싱은 데이터가 메모리에 예열된 후 반복적인 스토리지 액세스를 줄일 수 있습니다.

삭제해도 되는 것으로 확인된 캐시만 지운 상태로 테스트 인스턴스를 다시 시작하고, 정상 서버와 예열 동작을 비교하세요. 서버에서 라이브러리 식별 정보나 설정이 사라진다면, 제거한 경로는 단순한 폐기 가능 캐시가 아니었던 것입니다.

데이터베이스 무결성에 따라 백업 우선순위가 달라집니다

백업한 데이터베이스가 내부적으로 일관된 상태일 때만 영구 데이터가 유용합니다. 쓰기 작업 중에 복사한 데이터베이스는 쓰기를 통제한 유휴 상태에서 만든 백업보다 신뢰하기 어려울 수 있습니다.

SQLite 쓰기 안전성을 위해서는 쓰기를 통제해야 하므로, 실행 중인 Plex 데이터베이스를 권한 확인용으로 사용해서는 안 됩니다.

가능한 경우 쓰기 작업을 일시 중지하거나 중단하는 백업 시간을 예약한 다음, 복사한 데이터베이스를 열 수 있는지 확인하세요. 파일은 정상적으로 복사되었는데 복원 테스트가 실패한다면 보존 기간을 늘리기 전에 백업 일관성 문제부터 해결하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

임시 트랜스코딩 공간은 다른 복구 등급에 속합니다

트랜스코딩 출력은 재생 경로를 위해 생성되는 작업 데이터이지, 신뢰할 수 있는 라이브러리 원본이 아닙니다. 속도와 용량을 고려해 배치할 수 있지만 Plex 데이터베이스와 동일한 내구성 정책을 적용할 필요는 없습니다.

Plex 트랜스코딩이 필요하면 클라이언트 호환성에 따라 디코딩 및 인코딩 작업이 서버로 이동합니다.

배포 파일에서 트랜스코딩 및 캐시 마운트를 영구 Plex 데이터 마운트와 별도로 문서화하세요. 임시 경로가 고유한 설정이나 데이터베이스 파일이 존재하는 유일한 위치라면 다음 마이그레이션 전에 해당 경로의 등급을 다시 분류하세요.