メディアサーバーの移行中に視聴履歴を引き継げますか？

はい。移行時にユーザーデータベース、メディアの識別情報、互換性のあるアプリケーション状態を新しいサーバーへ引き継げば、視聴履歴を保持できます。

映画ファイルだけをコピーしても、再生済みフラグ、再生位置、お気に入り、ユーザーアカウント、トラックごとの選択内容は移行されません。これらの記録はメディアサーバーの永続データベースに保存され、ユーザーおよびメディアの識別子に関連付けられています。最も安全な方法は、同一プラットフォームのインスタンスを完全に移行することです。サービスを停止した状態で整合性のあるバックアップを作成し、バージョンを一致させ、コンテナ内のパスを安定させたうえで、移行先を本番サーバーにする前に分離環境で復元テストを行います。

インスタンスを移行するのか、プラットフォームを変更するのかを決める

同じアプリケーションを別のホストへ移行する場合、通常はサーバーの完全な状態を保持できます。PlexからJellyfin、EmbyからJellyfinなど、異なるプラットフォームへ移行する場合は、データベースのスキーマと識別子が異なるため、エクスポート、同期サービス、プラグイン、またはAPIベースの変換が必要です。

Jellyfinユーザーがアカウント、視聴履歴、ユーザー設定を簡単にエクスポートできる機能を求めているのは、まさにユーザーデータが単純なメディアフォルダーのコピーではないからです。

開始前に、どちらか一方の方法を選択してください。同じメディアサーバーの場合は完全なインスタンス復元、プラットフォームを変更する場合は文書化された視聴状態の移行を行います。データベースの一部だけを新しくスキャンした移行先へコピーするなど、両方の方法を組み合わせないでください。

永続的なサーバー状態全体をバックアップする

設定、データベース、ユーザー、プラグイン、メタデータ、証明書、スケジュールタスクの設定、コンテナ環境を一覧化します。稼働中のアプリケーションバージョン、イメージタグ、データベースの場所、すべての永続マウントを記録してください。

視聴状態には、単なる真偽値以上の情報が含まれる場合があります。Jellyfinの議論では、再生済み状態、再生回数、再生位置、最終再生日、お気に入り、選択したストリームなどのフィールドがユーザーデータの記録に含まれると説明されています。

完全な復元方法が存在しない場合を除き、1つのテーブルだけをエクスポートするのではなく、サポート対象の永続データ一式をバックアップしてください。データベースの一部だけを移行すると、あるフィールドは保持できても、ユーザーID、メディア参照、スキーマ要件、新しい移行履歴が壊れる可能性があります。

サーバーを停止するか、データベース整合性のあるスナップショットを使用する

最終バックアップの作成中は、再生、スキャン、メタデータの更新、ユーザーによる変更を防止します。ストレージとアプリケーションが整合性のあるオンラインバックアップ方式に対応していない限り、SQLiteファイルをコピーする前にメディアサーバーのプロセスを停止してください。

Jellyfinのバックアップに関する議論では、通常のファイルシステムバックアップ中にデータベースが使用中である可能性があるため、アクティブなSQLiteファイルをコピーすると整合性のない状態が取得される場合があると警告されています。

サービス停止後にチェックサムとファイルサイズを記録し、移行先の検証が完了するまで、移行元サーバーを変更せずに維持します。切り替え中に、両方のサーバーから同じデータベースまたは視聴状態の同期先へ書き込ませないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

アプリケーションのバージョンとアップグレード方向を管理する

可能であれば、まず同じアプリケーションバージョンへ復元します。移行先をアップグレードする前に、プラグイン、データベーススキーマ、コンテナパスが一致していることを確認してください。

データベースの移行は一方向の場合があり、記録された移行状態と実際のスキーマが一致しないと、復元したインスタンスが起動に失敗することがあります。Jellyfinの最近の問題では、復元後の移行状態の競合が報告されています。

復元したサーバーは公開クライアントからアクセスできない状態で起動し、移行ログを確認したうえで、アップグレード前にもう一度スナップショットを取得してください。データベースの唯一のコピーで新しいリリースをテストし、その後に旧バージョンのサーバーで再び開けると期待することは避けてください。

安定したメディアパスとアイテムの識別情報を保持する

ホスト側のディスクが変わっても、コンテナから見えるパスは同じに保ちます。たとえば、移行先にまったく新しいライブラリルートを設定するのではなく、新しいストレージプールを既存の/media/moviesおよび/media/tvに割り当てます。

パスを変更すると、新しいメディアレコードが作成されたり、復元済みのレコードと並んで古いエントリが残ったりすることがあります。Jellyfinの問題では、ライブラリパスの変更が永続的な古いメタデータや、継続視聴項目の重複につながるケースが示されています。

完全スキャンを開始する前に、映画1本とエピソード1本について、ファイルパスと内部アイテム識別情報を確認します。移行先がすべてのファイルを新規として認識する場合は停止し、重複レコードに視聴状態が分散する前にパスマッピングを修正してください。

ユーザーと識別子の整合性を維持する

表示名が同じアカウントを手動で作り直すのではなく、データベースとともにユーザーを復元してください。表示されるユーザー名が同じでも、移行先のユーザーが同じ内部識別子を持つとは限りません。

手動で履歴を復元する場合、通常はユーザーデータテーブルを対象にしますが、記録はユーザーとメディアの両方の参照情報に依存します。そのため、メタデータを失わずにライブラリの場所を移動するには、移動したファイルを無条件に再スキャンするのではなく、パスとデータベースを慎重に扱う必要があります。

復元後は、代表的な各ユーザーでログインし、視聴済みフラグ、視聴途中の項目、再生位置、お気に入り、音声の選択、字幕の選択を比較します。管理者アカウントだけで成功を判断しないでください。

プラットフォーム間の移行では同期またはエクスポートを利用する

移行元と移行先のアプリケーションが異なる場合は、対応プラグイン、APIツール、または視聴履歴追跡サービスなどの中立的なサービスを通じて履歴をエクスポートします。ライブラリ全体を同期する前に、少量のサンプルでテストしてください。

ユーザーとタイトルを明示的に対応付け、エピソード、エディション、別カット、改名されたファイルを識別情報の競合候補として扱います。複数の年またはバージョンが同じ名前を持つ場合、映画のタイトルだけでは識別情報として不十分です。

最初のインポートが成功した後も、移行元の履歴をエクスポートした状態で保存してください。ユーザーの不足やタイトルの不一致を、移行を最初からやり直すことなく修正できるよう、転送は繰り返し実行できるか、監査可能であるべきです。

分離環境で復元を実行し、検証後にのみ切り替える

移行先は一時ポートで起動し、スケジュールスキャン、Webhook、外部同期を無効にします。ユーザー、ライブラリ数、視聴済み総数、再生位置、プレイリスト、コレクション、無作為に選んだ複数のタイトルを確認してください。

ZimaSpaceのNASデータ移行ワークフローでは、より一般的な原則として、移行先からコピーされた状態の検証が完了するまで移行元を保持することが示されています。

復元したインスタンスが再起動後も正常に動作し、パスが安定し、代表的なユーザーの履歴が保持され、新しい再生によって移行先が正しく更新されて初めて、移行は完了です。新しいサーバーが数日間通常運用され、新しいバックアップを取得できるまで、移行元はオフラインにして復旧可能な状態で保管してください。