Jellyfin은 ARM과 x86에서 동일한 데이터로 실행할 수 있나요?

일반적으로는 그렇습니다. 하지만 ARM에서 x86으로의 이전은 모든 Jellyfin 구성 요소가 아키텍처에 관계없이 작동한다는 증명이 아니라, 통제된 호스트 마이그레이션으로 처리해야 합니다. 현재 Jellyfin 릴리스에서 관련 ARM 대상은 ARM64이며, x86 대상 역시 지원되는 64비트 플랫폼이어야 합니다. 대상 호스트가 재시작 및 재생 확인을 통과할 때까지 소스 호스트를 그대로 유지하세요.

중요한 경계는 운영 방식입니다. 영구 상태를 복사하기 전에 소스 호스트를 중지하고, 서로 다른 호스트에서 실행되는 두 Jellyfin 인스턴스가 동일한 활성 데이터 디렉터리에 쓰도록 해서는 안 됩니다. Jellyfin은 ARM64에서 x86-64로의 이전을 특별히 위험이 전혀 없는 마이그레이션 경로로 문서화하지 않았으므로, 롤백용 사본을 보관하고 FFmpeg 패키지, 하드웨어 가속 장치 매핑, 네이티브 플러그인 종속성, 권한, 호스트 경로처럼 플랫폼에 종속된 요소는 별도로 다시 구성하세요.

대상 아키텍처가 실제로 지원되는지 확인하기

먼저 대상이 현재 지원되는 64비트 Jellyfin 플랫폼인지 확인하세요. Linux 자체가 여전히 부팅된다는 이유만으로 오래된 ARM 보드, 32비트 운영 체제 또는 구형 x86 시스템을 사용할 수 있다고 가정하지 마세요.

Jellyfin 10.11은 ARM32 지원을 공식적으로 제거했으며, ARM 플랫폼에서는 이제 ARM64 운영 체제가 필요합니다. 소스가 여전히 이전 32비트 ARM 빌드를 실행하고 있다면, 기존 런타임을 현재의 마이그레이션 대상으로 취급하기보다 먼저 지원되는 64비트 대상을 계획하세요.

x86에서는 사용하려는 Jellyfin 버전의 요구 사항을 충족하는 지원되는 x86-64 호스트를 사용하세요. 대상이 비공식 패키지, 지원되지 않는 운영 체제 또는 오래된 CPU에 의존한다면 영구 상태를 옮기기 전에 해당 플랫폼 문제를 해결하세요.

저장된 상태는 이식 가능하지만 배포 환경은 플랫폼별로 다르다고 보기

일반적인 Jellyfin 배포에서는 데이터베이스와 구성 및 메타데이터 파일에 서버의 영구 상태가 저장됩니다. SQLite를 사용하는 설치의 경우 디스크 데이터베이스 형식은 프로세서 아키텍처 간 이식성을 고려해 설계되었으므로, CPU 제품군이 다르다는 이유만으로 마이그레이션 전에 데이터베이스를 바이트 단위로 변환할 필요는 없습니다.

SQLite는 파일 형식을 크로스 플랫폼 데이터베이스 형식으로 문서화하고 있으며, 32비트와 64비트 시스템 간 및 엔디언 차이를 넘어선 이식성도 포함합니다. 이는 데이터베이스 형식 측면의 이전을 뒷받침하지만, 모든 Jellyfin 플러그인, 외부 실행 파일, 드라이버 또는 배포 환경별 경로가 변경 없이 유지된다는 보장은 아닙니다.

다음과 같은 구분을 명확히 유지하세요. 저장된 레코드의 이식성은 여러 계층 중 하나일 뿐입니다. Jellyfin 버전 호환성, 데이터 및 구성의 완전한 이전, 미디어 경로의 일관성, 플러그인 종속성, 권한, 하드웨어 장치 접근성이 모두 대상이 소스처럼 작동할지를 결정합니다.

활성 상태를 옮기기 전에 Jellyfin 중지하기

통제된 아키텍처 이전을 위해 마이그레이션 사본을 만들기 전에 소스 Jellyfin 프로세스를 종료하세요. 이렇게 하면 파일을 복사하는 동안 활성 데이터베이스나 쓰기 미리 기록 상태가 변경되는 것을 방지하고, 일관된 롤백 지점을 확보할 수 있습니다.

jellyfin.db만 선택하지 말고 전체 데이터 및 구성 범위를 복사하세요. 부분적으로 복사하면 사용자는 보존되더라도 대상이 필요로 하는 구성, 플러그인, 메타데이터 또는 기타 상태가 손실될 수 있습니다.

다중 사본 백업 계획에 사용되는 동일한 보호 모델을 여기에도 적용하세요. 대상이 실제 복원 및 재생 검증을 통과할 때까지 소스를 그대로 유지하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

새 호스트에서 아키텍처별 요소 다시 구성하기

대상 호스트에 맞는 네이티브 Jellyfin 패키지를 설치하거나 올바른 멀티 아키텍처 컨테이너 이미지를 사용하세요. 기존 아키텍처의 바이너리를 복사하지 말고 GPU 장치 매핑, 그룹 권한, FFmpeg 패키지 및 호스트별 경로를 다시 구성하세요.

첫 실행 후 플러그인을 검토하세요. 네이티브 라이브러리, 번들 바이너리 또는 외부 실행 파일에 의존하는 플러그인은 새 아키텍처에 맞는 빌드가 필요할 수 있습니다. 문제가 있는 플러그인이 시작을 방해한다면 첫 검증 중에는 비활성화한 다음, 호환성을 확인한 후에만 다시 추가하세요.

호스트 간 미디어 경로가 다르다면 가능한 경우 마운트를 통해 동일한 경로를 유지하세요. 그렇지 않다면 Jellyfin 내부 데이터베이스 레코드를 수동으로 편집하기보다 지원되는 경로 마이그레이션을 계획하세요.

소스를 재사용하기 전에 마이그레이션 검증하기

대상 인스턴스만 시작하고 사용자, 라이브러리, 시청 상태, 아트워크, 예약된 작업, Direct Play 한 건 및 필요한 트랜스코딩 한 건을 확인하세요. 누락된 네이티브 라이브러리, 권한 오류 또는 이전 호스트를 여전히 참조하는 경로가 로그에 나타나는지 확인하세요.

대상 호스트를 두 번 재시작하고 재생 테스트를 반복하여 성공이 일회성 시작이 아니라 지속적인 상태인지 확인하세요. 대상이 실패하면 이를 중지하고 마이그레이션 사본을 복원하거나 변경되지 않은 소스로 돌아가세요. 두 인스턴스가 동일한 상태에 쓰도록 방치해서는 안 됩니다.

새 호스트가 재시작과 일반적인 가정 내 사용을 견뎌낼 때에만 이전이 완료됩니다. 기존 시스템을 계속 사용할 수 있게 보관하려면 별도로 복원한 사본을 제공하거나 전원을 꺼 두세요. 하나의 라이브 Jellyfin 데이터 디렉터리를 ARM 서버와 x86 서버 간의 공유 활성 저장소로 사용하지 마세요.