クリーンな復元によって必要なユーザー、パス、再生、権限、再起動時の動作が再現できることを確認するまで、古いJellyfinサーバーを廃止しないでください。
新しいインスタンスはダッシュボードを開けるだけですか?それとも、以前のホストと同じクライアントおよびストレージの負荷に耐えられましたか?テスト中は、古いサーバーを停止したまま復旧可能な状態にしておいてください。ログインに成功しただけでは最初の確認にすぎません。復元によって、家庭内で実際に使用している状態とデータパスが再現されることを証明する必要があります。
再生前に永続状態を確認する
復元した設定とデータベースに、想定したユーザー、ライブラリ、視聴済み状態、プラグイン、権限が含まれていることを確認してください。Jellyfinサービスのコンテキストから各ライブラリパスを確認し、すべてのストレージ場所からサンプルファイルを1つずつ読み取ります。マウント漏れや所有者の誤りは、スキャンや再生要求を行うまで発覚しないことがあります。
キャッシュやダウンロード済みアートワークなど、意図的に再構築したものを記録しておき、差異を復元失敗と取り違えないようにしてください。次の判定が完了するまで、バックアップと古いアプリケーションデータのコピーは変更せずに保管します。
復元したアイテム数と、既知の視聴状態レコードを1件、古いサーバーの最終インベントリと比較してください。データベースが正常に起動しただけでは、すべてのメディアパスやユーザー権限が維持されたことの証明にはなりません。
元のクライアント負荷を実行する
ローカルでのDirect Playを1回、強制トランスコードを1回、字幕、使用している場合はリモートアクセス、さらに制限付きユーザーアカウントをテストしてください。再生モード、音声、字幕表示、ライブラリの可視性、起動時間を、古いサーバーで確認済みの動作と比較します。
1台のクライアントだけが失敗する場合は、復元全体を変更する前に、そのクライアントの機能またはパスを切り分けてください。移行手順はチェックリストとして役立ちますが、受け入れの判断は、自宅で実際に行う負荷テストの結果に基づいてください。
サービスが通常の起動タスクを完了するのに十分な時間稼働した後、同じセッションをもう一度実行してください。これにより、短時間のログインでは見逃す可能性がある、遅延したマウント、プラグイン、メタデータの障害を検出できます。
コールド再起動と復旧の判定を通過させる
Jellyfinを停止し、ホストを再起動して、ストレージのマウントとネットワークサービスが起動するまで待ち、同じクライアントテストを繰り返してください。復元したアプリケーション状態の新しいバックアップを作成するか、既存のものを確認します。次に、2回目の復元テストを実施するか、少なくともバックアップに、復旧に必要な正確なデータディレクトリと権限が含まれていることを確認してください。
復元したホストが、状態、パス、ユーザー、再生、コールド再起動、バックアップ場所の各確認を2回通過した場合にのみ、古いサーバーを廃止してください。データベースを開けない場合、元のクライアント負荷に失敗する場合、または復旧用コピーを独立して読み取れない場合は、停止してロールバックします。
合格した正確な復元ポイント、ファイル所有権、パスマッピングを記録してください。新しいホストが廃止期間中に故障した場合、これらの詳細が復旧手順になります。
廃止期間を安全に終了する
復元したホストが2回目のコールドスタートテストに合格し、新しいバックアップを独立して見つけられるようになるまで、古いサーバーは停止したまま復旧可能な状態にしておいてください。
ローカル再生、必要に応じてリモート再生、ユーザーアクセス、ライブラリスキャン、復元ドキュメントのすべてに合格した後でのみ、古いホストを廃止してください。保持期間が終了するまで、古いアプリケーションデータを保管します。
必要なクライアントのいずれかが失敗した場合、復元したデータベースが予期せず変更された場合、またはバックアップによってテスト済みの状態を再現できない場合は、停止してロールバックしてください。
サポートとヒント
もっと読む

同時実行コンテナ向けにJellyfinのデータベース接続を最適化する方法
まずは1人のデータベース所有者と、SQLiteのロック動作を測定することから始め、同時実行性と復旧性の観点から複雑さが正当化される場合にのみ、別のバックエンドを追加します。

Jellyfinでジョブやインポートの重複を防ぐ方法
重複作業は通常、スケジューラーの重複や複数の書き込み担当者によって発生します。担当者を1人、経路を1つ、完了確認を1つに決めてください。

データベースボリュームがいっぱいになった後にJellyfinを修復する方法
書き込みを停止し、データベースとWALファイルを保持したまま、状態を無闇に削除せずに空き容量を確保し、その後、整合性と元のワークロードを検証します。

