미디어 서버를 마이그레이션할 때 시청 기록을 유지할 수 있나요?

예. 마이그레이션 과정에서 사용자 데이터베이스, 미디어 식별 정보, 호환되는 애플리케이션 상태를 새 서버로 옮기면 시청 기록을 보존할 수 있습니다.

영화 파일만 복사하면 시청 완료 표시, 재생 위치, 즐겨찾기, 사용자 계정 또는 트랙별 선택 사항은 이전되지 않습니다. 이러한 기록은 미디어 서버의 영구 데이터베이스에 저장되며 사용자 및 미디어 식별자와 연결됩니다. 가장 안전한 방법은 서버를 중지한 상태에서 일관된 백업을 생성하고, 버전을 맞추며, 컨테이너 경로를 안정적으로 유지한 뒤, 대상 서버를 활성 서버로 전환하기 전에 격리된 복원 테스트를 진행하는 동일 플랫폼 인스턴스 전체 마이그레이션입니다.

인스턴스를 이전하는지 플랫폼을 변경하는지 정의하세요

한 호스트에서 다른 호스트로 동일한 애플리케이션을 마이그레이션하면 일반적으로 전체 서버 상태를 보존할 수 있습니다. Plex에서 Jellyfin으로, Emby에서 Jellyfin으로 또는 다른 플랫폼으로 이전하는 경우에는 데이터베이스의 스키마와 식별자가 다르므로 내보내기, 동기화 서비스, 플러그인 또는 API 기반 변환이 필요합니다.

Jellyfin 사용자는 계정, 시청 기록, 사용자 설정을 더 쉽게 내보낼 수 있는 기능을 요청해 왔습니다. 이는 사용자 데이터가 단순한 미디어 폴더 복사로 이전되지 않기 때문입니다.

시작하기 전에 한 가지 경로를 선택하세요. 동일한 미디어 서버라면 전체 인스턴스 복원을, 플랫폼을 변경한다면 문서화된 시청 상태 이전을 사용합니다. 데이터베이스 일부만 새로 스캔한 대상에 복사하는 식으로 두 방법을 함께 사용하지 마세요.

영구 서버 상태 전체를 백업하세요

구성, 데이터베이스, 사용자, 플러그인, 메타데이터, 인증서, 예약 작업 설정 및 컨테이너 환경을 목록화하세요. 실행 중인 애플리케이션 버전, 이미지 태그, 데이터베이스 위치, 모든 영구 마운트 경로를 기록합니다.

시청 상태에는 단순한 불리언 값보다 많은 정보가 포함될 수 있습니다. Jellyfin 토론에서는 사용자 데이터 레코드에 시청 완료 상태, 재생 횟수, 재생 위치, 마지막 재생 날짜, 즐겨찾기 및 선택한 스트림과 같은 필드가 포함된다고 설명합니다.

전체 복원 경로가 없는 경우를 제외하고는 하나의 테이블만 내보내지 말고 지원되는 영구 데이터 전체를 백업하세요. 데이터베이스 일부만 이식하면 특정 필드는 보존되더라도 사용자 ID, 미디어 참조, 스키마 요구 사항 또는 최신 마이그레이션 기록이 손상될 수 있습니다.

서버를 중지하거나 데이터베이스 일관성이 보장되는 스냅샷을 사용하세요

최종 백업을 생성하는 동안 재생, 스캔, 메타데이터 새로 고침 및 사용자 변경이 발생하지 않도록 하세요. 스토리지와 애플리케이션이 일관된 온라인 백업 방식을 지원하지 않는 한 SQLite 파일을 복사하기 전에 미디어 서버 프로세스를 중지합니다.

Jellyfin 백업 토론에서는 일반적인 파일 시스템 백업 중에 데이터베이스가 사용 중일 수 있기 때문에 활성 SQLite 파일을 복사하면 일관되지 않은 상태가 캡처될 수 있다고 경고합니다.

서비스가 중지된 후 체크섬과 파일 크기를 기록하고, 대상 서버가 검증을 통과할 때까지 소스 서버를 변경하지 않은 상태로 유지하세요. 전환 중에는 두 서버가 동일한 데이터베이스나 시청 상태 동기화 대상에 쓰도록 하지 마세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

애플리케이션 버전과 업그레이드 방향을 통제하세요

가능하면 먼저 동일한 애플리케이션 버전으로 복원하세요. 대상 서버를 업그레이드하기 전에 플러그인, 데이터베이스 스키마 및 컨테이너 경로가 일치하는지 확인합니다.

데이터베이스 마이그레이션은 되돌릴 수 없는 경우가 있으며, 기록된 마이그레이션 상태와 실제 스키마가 일치하지 않으면 복원된 인스턴스가 제대로 작동하지 않을 수 있습니다. 현재 Jellyfin 이슈에는 복원된 마이그레이션 상태 충돌이 기록되어 있습니다.

복원된 서버는 외부 클라이언트의 접근을 차단한 상태에서 시작하고, 마이그레이션 로그를 확인한 다음 업그레이드하기 전에 다시 스냅샷을 생성하세요. 데이터베이스의 유일한 사본에 최신 릴리스를 먼저 적용한 뒤 이전 서버 버전에서 다시 열 수 있을 것이라고 기대하지 마세요.

안정적인 미디어 경로와 항목 식별 정보를 보존하세요

호스트 디스크가 바뀌더라도 컨테이너에서 보이는 경로는 동일하게 유지하세요. 예를 들어 대상 서버에 완전히 새로운 라이브러리 루트를 지정하는 대신 새 스토리지 풀을 기존의 /media/movies 및 /media/tv 경로에 매핑합니다.

경로를 변경하면 새 미디어 레코드가 생성되거나 복원된 레코드 옆에 오래된 항목이 남을 수 있습니다. Jellyfin 이슈에서는 라이브러리 경로 삭제와 지속적인 오래된 메타데이터 및 중복 이어보기 동작의 연관성을 다룹니다.

전체 스캔을 시작하기 전에 영화 한 편과 에피소드 한 편의 파일 경로 및 내부 항목 식별 정보를 확인하세요. 대상 서버가 모든 파일을 새 항목으로 인식한다면 중지하고, 중복 레코드로 시청 상태 연결이 분산되기 전에 경로 매핑을 수정합니다.

사용자와 사용자 식별자를 일관되게 유지하세요

동일한 표시 이름으로 계정을 수동 재생성하지 말고 데이터베이스와 함께 사용자를 복원하세요. 화면에 표시되는 사용자 이름이 같다고 해서 대상 서버의 내부 식별자까지 동일하다는 의미는 아닙니다.

수동으로 기록을 복원할 때는 일반적으로 사용자 데이터 테이블을 대상으로 하지만, 해당 레코드는 사용자 및 미디어 참조 모두에 의존합니다. 따라서 메타데이터를 잃지 않고 라이브러리 위치를 옮기려면 이동한 파일을 무작정 다시 스캔하는 방식이 아니라 경로와 데이터베이스를 신중하게 처리해야 합니다.

복원 후 각 대표 사용자의 계정으로 로그인하여 시청 완료 표시, 시청 중인 항목, 재생 위치, 즐겨찾기, 오디오 선택 및 자막 선택을 비교하세요. 관리자 계정만으로 성공 여부를 판단하지 마세요.

플랫폼 간 이전에는 동기화 또는 내보내기 경로를 사용하세요

소스와 대상 애플리케이션이 서로 다르면 지원되는 플러그인, API 도구 또는 시청 기록 추적 플랫폼과 같은 중립 서비스를 통해 기록을 내보내세요. 전체 라이브러리를 동기화하기 전에 소규모 샘플로 테스트합니다.

사용자와 제목을 명시적으로 연결하고, 에피소드, 에디션, 대체 편집본 및 이름이 변경된 파일은 식별자 충돌 가능성이 있는 항목으로 취급하세요. 여러 연도나 버전이 같은 이름을 공유할 수 있으므로 영화 제목만으로는 식별 기준이 부족합니다.

첫 번째 가져오기가 성공한 후에도 소스 기록의 내보내기 파일을 보관하세요. 누락된 사용자와 일치하지 않는 제목을 처음부터 마이그레이션하지 않고 수정할 수 있도록 이전 과정은 반복 가능하거나 감사 가능한 형태여야 합니다.

격리된 복원을 실행하고 검증 후에만 전환하세요

예약 스캔, 웹훅 및 외부 동기화를 비활성화한 임시 포트에서 대상 서버를 시작하세요. 사용자, 라이브러리 수, 시청 완료 항목 수, 재생 위치, 재생 목록, 컬렉션 및 무작위로 선택한 여러 제목을 확인합니다.

ZimaSpace의 NAS 데이터 마이그레이션 워크플로는 더 일반적인 원칙을 제시합니다. 대상에서 복사된 상태를 검증할 때까지 소스를 보존해야 한다는 것입니다.

복원된 인스턴스가 재시작 후에도 정상적으로 작동하고, 경로가 안정적으로 유지되며, 대표 사용자들이 기록을 그대로 보유하고, 새 재생 기록이 대상 서버에 올바르게 업데이트될 때에만 마이그레이션이 완료됩니다. 새 서버가 며칠간 정상적으로 작동하고 새로운 백업이 생성될 때까지 소스 서버는 오프라인 상태로 유지하되 복구 가능한 상태로 보관하세요.