Jellyfin 내장 백업과 파일 수준 백업: 어떤 것을 사용해야 할까요?

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

Jellyfin 내장 백업과 파일 수준 백업은 서로 겹치지만 복구 범위는 다릅니다. 내장 시스템은 Jellyfin 애플리케이션 데이터를 이해하고 서버가 온라인 상태인 동안 아카이브를 만들 수 있습니다. 수동 파일 수준 백업은 더 넓은 배포 상태를 캡처할 수 있지만, 실행 중인 애플리케이션 데이터를 안전하게 복사하려면 먼저 Jellyfin을 중지해야 합니다.

더 나은 계획은 대개 둘 중 하나만 선택하는 것이 아닙니다. 자주 발생하는 애플리케이션 복구 지점에는 내장 방식을 사용하고, 호스트 경로, 구성, 컨테이너 정의 또는 더 광범위한 서버 상태를 재현해야 할 때는 Jellyfin을 중지한 파일 수준 또는 파일 시스템 수준 방식을 사용하세요.

일상적인 온라인 복구 지점에는 내장 백업이 유리합니다

현재 Jellyfin 백업 시스템은 서버가 실행 중인 동안 데이터베이스를 보호할 수 있으며, 선택적으로 메타데이터, 자막 및 트릭플레이 데이터를 포함할 수 있습니다. 따라서 정상적인 재생을 의도적으로 중단하지 않고도 예약된 복구 지점을 만드는 데 실용적입니다.

Jellyfin의 백업 문서에 따르면 내장 백업은 온라인 상태에서 실행할 수 있지만 수동 데이터 디렉터리 백업을 수행하려면 서버를 중지해야 합니다. 온라인 방식이라도 같은 시간대에 라이브러리 스캔이 실행되지 않도록 활동량이 적은 시간에 수행하는 것이 좋습니다.

복구 목표가 “이 Jellyfin 인스턴스를 알려진 애플리케이션 상태로 되돌리는 것”이라면 이것이 가장 강력한 기본 선택입니다.

복구 범위에 호스트 구성이 포함된다면 파일 수준 백업이 유리합니다

파일 수준 복사에는 영구 애플리케이션 폴더, Compose 파일, 환경 파일, 리버스 프록시 구성, 서비스 유닛, 스크립트, 인증서 및 Jellyfin 전용 아카이브가 자동으로 파악하지 못하는 기타 배포 자산을 포함할 수 있습니다.

이처럼 더 넓은 범위는 시스템 디스크에 장애가 발생했거나 교체 호스트로 마이그레이션할 때 유용합니다. 단점은 일관성입니다. 일반적인 파일 복사 도구는 변경 중인 SQLite 데이터베이스를 이해하지 못하므로, 실행 중인 영구 상태를 복사하기 전에 Jellyfin을 정상적으로 중지하세요.

Jellyfin 복구 위험 저장소 구성에 관한 ZimaSpace 가이드도 같은 문제를 강조합니다. 복원된 서버에 필요한 경로, 마운트, 권한 및 외부 종속성을 아무도 재현할 수 없다면 백업은 불완전합니다.

데이터베이스 인식 백업은 실행 중인 SQLite 파일을 복사하는 것과 다릅니다

SQLite는 데이터베이스를 인식하는 인터페이스를 통해 일관된 온라인 백업을 지원하지만, Jellyfin이 파일을 변경하는 동안 파일을 읽는 일반 복사 도구가 동일한 보장을 자동으로 제공하지는 않습니다.

SQLite 백업 API는 조정된 데이터베이스 작업을 통해 활성 데이터베이스를 일관된 대상에 복사하도록 설계되었습니다. 따라서 “파일이 오류 없이 복사되었다”는 사실만으로는 실행 중인 Jellyfin의 수동 백업이 안전하다고 볼 수 없습니다.

수동 방식이 rsync, SMB 복사, zip 또는 일반 파일 시스템 복사뿐이라면, 애플리케이션 쓰기 작업과 조정된 스토리지 스냅샷을 사용하는 경우가 아닌 한 먼저 Jellyfin을 중지하세요.

편의성을 비교하기 전에 범위를 비교하세요

항목 내장 백업 파일 수준 백업
서버를 온라인 상태로 유지할 수 있음 예, 가급적 활동량이 적을 때 일반적인 복사 작업에서는 Jellyfin 중지 필요
Jellyfin 데이터베이스 포함됨 영구 경로를 올바르게 복사하면 포함됨
메타데이터/자막/트릭플레이 선택적으로 지원 복사한 경로에 포함되어 있으면 포함됨
Compose/호스트 스크립트/프록시 구성 자동으로 포함되지 않음 포함할 수 있음
호스트 교체 작업 흐름 Jellyfin 상태 복구에 적합 더 광범위한 배포 상태에 더 적합
일관성 위험 애플리케이션 인식 방식 작업 중지 또는 스냅샷 방식에 따라 달라짐

백업을 실행 중인 Jellyfin 장애 범위 밖에 보관하세요

실패한 파일 시스템 아래에 모든 백업이 저장되어 있다면 어느 방식도 풀 손실을 막아 주지 못합니다. 검증된 백업 아카이브 또는 중지 상태에서 만든 복구 세트를 다른 디스크, NAS 또는 오프사이트 위치로 복사하세요.

Jellyfin은 새 릴리스가 시작될 때 데이터 마이그레이션을 적용하며 일반적인 인플레이스 다운그레이드 경로를 제공하지 않으므로, 업그레이드 전 복구 지점을 최소 하나는 보관하세요.

두 방식이 모두 복구 계획에 포함되어 있다면 두 복원 방식을 모두 테스트하세요. 내장 아카이브는 애플리케이션 복구를 입증하고, 파일 수준 복구 훈련은 주변의 영구 경로와 권한을 포함한 환경을 재현할 수 있는지 입증합니다.

FAQ

내장 백업을 사용할 때 Jellyfin을 중지해야 하나요?

아니요. 내장 방식은 Jellyfin이 실행 중일 때 작동하도록 설계되었지만, 활동량을 낮추고 활성 라이브러리 스캔을 실행하지 않는 것이 좋습니다. 실행 중인 Jellyfin 데이터를 일반적인 수동 복사 방식으로 복사할 때는 서버를 중지하세요.

내장 백업으로 호스트 백업을 대체할 수 있나요?

항상 그런 것은 아닙니다. 내장 백업은 Jellyfin 애플리케이션 상태를 보호하지만, 전체 호스트 복구에는 Compose 파일, 프록시 설정, 인증서, 마운트, 권한, 스크립트 및 기타 외부 구성도 필요할 수 있습니다.

제품 비교

더 읽어보기

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.