コンテナの更新に失敗した後に Plex を復元する方法

別のイメージをプルする前に、失敗したPlexコンテナと自動アップデーターを停止してください。まず現在のログと実際のPlex設定パスを保護します。壊れたコンテナが自動的に自分自身を置き換えたり、アプリケーションの状態に書き込んだりできない状態にしておくと、復旧ははるかに安全になります。

ホームNASでは、コンテナの更新は複数の異なる層で失敗する可能性があります。新しいイメージが起動しない場合もあれば、再作成されたサービスでボリュームやネットワーク設定が失われる場合もあり、新しいPlexビルドが既存のアプリケーションデータを異なる方法で開く場合もあります。重要な境界は、永続化されたPlex設定、特に`/config`配下のデータベースとメタデータです。この手順では、いずれかを変更する前に、イメージ、コンテナ定義、マウント、データベースを分離し、その後、失敗した最小限の層を復元して、元のサーバーID、ライブラリ、再生を検証します。ログがデータベースの破損や元に戻せない移行を示している場合は、状態の唯一のコピーに古いイメージを強制的に適用する前に停止してください。

更新ループを停止し、失敗した状態を記録する

Plexの自動アップデーターを無効にし、頻繁な再起動ループを停止してください。Plexが連携停止を必要とするデータベースを共有していない限り、他の正常なサービスは稼働させておきます。目的はアプリスタック全体を再起動してタイムラインを消すことではなく、障害を調査できるよう、十分な時間その状態を維持することです。

失敗したコンテナの正確なイメージタグ、イメージID、利用可能な場合はダイジェストを記録してください。実効的なマウント、環境変数、公開ポート、ネットワークモード、ネットワークエイリアス、デバイスマッピング、追加されたグループ、再起動ポリシー、ヘルス状態を保存します。`latest`のようなタグだけでは、時間の経過とともに異なるイメージ内容を指す可能性があるため、信頼できるロールバック記録にはなりません。

次に起動を試みる前に直近のログをエクスポートし、最後の終了コードだけでなく、最初に発生した致命的なメッセージを記録してください。ファイルの欠落、権限拒否、データベースエラー、サポートされていない命令、アドレス競合のいずれが発生したかによって、復旧の進め方は異なります。また、更新を実行した時刻と、コンテナを再作成したかどうかも記録してください。プルだけでは既存のコンテナは変更されませんが、再作成すると実効的な定義が変わる可能性があります。

障害を再現でき、どのイメージが実行され、どの永続パスが使用され、どのランタイム設定が渡され、どのエラーが最初に発生したかという4つの質問に答えられる状態になれば、続行できます。これらがまだ不明なままでは、再度プルや再起動を行ってもノイズが増えるだけで、復旧の安全性は高まりません。

Plexの設定を再作成する前に保護する

コンテナは交換可能なもの、Plexの設定は永続的なものとして扱います。重要な状態は通常、`/config`にマウントされたホストパスまたは名前付きボリュームに保存されます。メディアライブラリは別のマウントに保持してください。サービスの再作成が低リスクなのは、空のディレクトリではなく、同じ永続状態に再接続する場合だけです。

ホストからマウントを確認し、プラットフォームが対応している場合は、一時的な読み取り専用コンテキストからも確認します。想定されるデータベース、設定、メタデータ、プラグインデータ、ログが存在することを確認します。マウント元、ファイルシステム、所有者、権限、空き容量、読み取り専用になっていないかを記録します。想定パスに空のディレクトリがある場合は、停止すべき警告であり、Plexにそこで新しいサーバーを作成させてよいという意味ではありません。

ロールバックを試す前に、想定している設定パス全体をバックアップし、そのバックアップを一覧表示できるか、隔離した場所に復元できるかを確認します。ファイルシステムがスナップショットに対応している場合、復旧を短縮できますが、同じストレージデバイスが故障している可能性があるときは、それだけを唯一のコピーにしないでください。サーバーの動作を確認するまで、障害発生時の状態と最後に正常だったバックアップの両方を保持します。

古いイメージを起動させるために、設定ファイル、データベースファイル、メタデータを削除しないでください。設定を一貫して読み取れない、所有者が不明確、またはコピーを検証できない場合は、直ちにストレージまたはデータベースの復旧に進みます。信頼できない状態ソースを、コンテナの再作成で修復することはできません。

イメージ、定義、マウント、データベースのどれが失敗したのかを判断する

修復方法を選ぶ前に、取得したコンテナを最後に正常に動作していたデプロイと比較します。まず最初に出た致命的なログ行と実効コンテナ定義を確認し、障害を次の4つの分岐のいずれかに分類します。新しいイメージを実行できない、コンテナ定義が変わった、永続パスを利用できない、またはPlexが既存のアプリケーション状態を使用できない、のいずれかです。

Plexが`/config`を開く前に、イメージまたはランタイムの障害が発生することがよくあります。アーキテクチャのエラー、サポートされていないCPU命令、ランタイムライブラリの不足、またはコンテナ定義を変更していないのにプロセスが直ちに終了するといった症状です。バージョンに依存する再生障害は、サーバーを以前のPlexイメージに戻すと解消しました。同じ定義が以前は動作しており、マウントや権限に変更がない場合、ロールバックは有効な切り分け手段です。

Plexの起動時にメディアが欠落している、サーバーが空になっている、ファイルアクセスが拒否される、ウェブエンドポイントがない、またはハードウェアアクセスが失われるなどの状態が再作成後に現れた場合は、定義またはマウントの失敗が疑われます。保存されたボリュームソースと実際に適用されたボリュームソース、UID/GID、グループ、ポート、ネットワークモード、デバイス、環境変数を比較します。すべての項目を一度に変更するのではなく、最初に確認できた不一致を修正してください。

データベースと移行に関するメッセージは、別の切り分けが必要です。新しいビルドがスキーマ変更を開始した場合、古いイメージでは変更後の状態を読み取れないことがあります。現在の設定をもう一度バックアップし、ログを保持し、複数のバージョンにまたがる起動を繰り返して強制しないでください。この分岐では、互換性のあるイメージ、更新前に取得した検証済みのバックアップ、またはデータベースを考慮した修復が必要です。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

最後に正常だったPlexイメージにロールバックする

最後に正常に動作した正確なイメージを選択します。移動するタグよりも、保持されているイメージダイジェスト、不変のバージョン参照、またはローカルイメージIDを優先します。アップデーターがロールバック直後に置き換えないよう、自動更新は無効にしておきます。

保存した定義からPlexサービスだけを再作成します。ネットワークに影響する場合は、同じプロジェクトまたはコンテナIDを維持し、同じ`/config`とメディアソース、同じポート、ネットワークモード、環境変数、UID/GID、グループ、デバイスを使用します。ボリュームを削除せず、古いイメージをテストする前にシステム全体のクリーンアップを実行しないでください。

最初の起動をリアルタイムで確認します。イメージのロールバックが成功すると、元の構成が開き、同じサーバーIDが維持され、既存のライブラリが表示され、以前の致命的なエラーが解消されるはずです。基本的なログインとメディアアクセスが機能するまで、オプションのハードウェアトランスコードとバックグラウンドスキャンは後回しにします。

古いイメージが、データベースが新しい、互換性がない、または移行途中であると報告した場合は停止します。バージョンの切り替えを繰り返すと、復旧ポイントの把握が難しくなります。検証済みの更新前構成コピーを分離したパスに復元するか、安全でないダウングレードを強行せず、互換性のあるPlexイメージに進めます。

ロールバックだけでは不十分な場合に、元のコンテナ定義を復元する

既知の正常なイメージでも失敗する場合は、定義の比較に戻ります。不足している設定を一度に1つずつ復元し、変更するたびにPlexだけを再起動します。これにより証拠を読み取りやすくできます。サーバーが復旧したとき、どのランタイム依存関係が原因だったのかが分かります。

まず`/config`とメディアのマウントを確認します。コンテナが意図したパスを認識し、設定されたユーザーとして読み取れることを確認します。更新によってPlexが別のUIDまたはGID、補助グループ、またはセキュリティコンテキストで再作成された場合は、最後に動作していたIDを復元するか、ストレージの所有権を意図的に修正します。近道としてappdataツリー全体を書き込み可能にしてはいけません。

次に、Web経路とオプションのデバイスを確認します。ファイアウォールルールを変更する前に、以前のホストネットワークまたは公開ポート、ネットワークエイリアス、リバースプロキシのメンバー設定を復元します。まず、サーバーへの直接経路でWebインターフェースを確認します。Plexが起動し、ライブラリを読み込み、ソフトウェア互換の基本的なストリームを提供できるようになってから、GPUデバイスとレンダーグループへのアクセスを追加します。

定義修復が成功した状態は明確です。コンテナが意図した構成とメディアを認識し、Plexエンドポイントに到達でき、ログに選択した依存関係エラーが表示されなくなっていることです。これらを確認しても同じデータベースエラーが残る場合は、コンテナの再作成をやめ、保護されたアプリケーション状態のブランチに戻ります。

更新を再有効化する前に、Plexのデータベース、ライブラリ、再生を確認する

稼働中のプロセスは、復旧確認の最初の一歩にすぎません。直接のPlexエンドポイントからサインインし、空の構成ディレクトリを使って新しく作成されたサーバーではなく、元の認証済みサーバーであることを確認します。データベースの破損、移行の繰り返し試行、予期しないライブラリの初期化がないか、起動ログを確認します。

既存のライブラリ項目をいくつか開き、ポスター、メタデータ、視聴状態、ファイルパスが存在することを確認します。アップデート前と同じストレージにある、既知の正常な小さなメディアファイル1つにアクセスできることをテストしてください。メタデータが存在するのにメディアを利用できない場合、データベースは正常で、メディアのマウントまたは権限だけを修復する必要がある可能性があります。

既知のファイルをまずローカルクライアントで再生し、該当する場合は障害が発生したクライアントでも再生します。再生モードを記録し、シークが機能することを確認してください。基本的な再生に成功した場合、GPUアクセラレーションの欠落、リモートアクセス、字幕の挙動は別のフォローアップ項目として扱います。これらを、復旧したサーバーの保全を妨げる要因にしてはいけません。

最後に、アップデーターを無効にしたまま、Plexサービスを制御下で1回再起動します。同じサーバーID、データベース、ライブラリ、メタデータ、メディアアクセス、基本的な再生が再起動後に戻った場合にのみ、復旧成功とみなします。この完全な結果を再現できるようになるまで、取得した障害時のログとバックアップを保持してください。

停止すべきタイミングを見極め、次回のPlexアップデートを復旧可能にする

ログでデータベースの破損が繰り返し報告される、設定ファイルシステムがI/Oエラーを返す、唯一の状態コピーが一部移行済みである、または互換性のあるイメージで開けない場合は、ローカルでのコンテナ修復を中止してください。イメージ識別子、実際に適用されている定義、ログ、設定バックアップを保持します。その時点では、コンテナをさらに入れ替え続けるより、データベースを考慮した復元またはストレージ修復の方が安全です。

Plexが安定したら、復元したイメージのダイジェスト、コンテナ定義、永続パス、実行時ID、ネットワークモード、デバイス、検証結果を記録します。より広範な単一サービスの復旧プロセスは、Plexが共有データベース、プロキシネットワーク、その他のスタックサービスにも依存している場合に役立ちますが、Plexの障害だけを理由に、それらの正常な依存サービスまで復元する必要はありません。

次回のアップデートでは、新しい`/config`バックアップを作成して検証し、現在のイメージを保持し、自動プルーニングを無効にしてから、Plexを手動で更新します。その後、自動化を再有効化する前に、ID、ライブラリ、再生、再起動の各チェックをもう一度実行してください。アップデートは、動作する新バージョンだけでなく、テスト済みのロールバック先も保持できて初めて完了とします。