保護されていないデータを残さずにJellyfinを廃止する方法

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

保持する状態を決定し、復元可能なバックアップを確認し、サービスが使用していたすべてのパスや認証情報を棚卸ししてから、アクセスを削除してJellyfinを廃止します。先にコンテナを削除すると、Jellyfinのインターフェースが消えた後も、メディアのマウント、バックアップ、APIキー、リバースプロキシのルート、永続ボリュームが残る可能性があります。

安全な廃止には2つの目的があります。後で必要になる可能性があるものを保存することと、データを公開または変更できるすべての経路を削除することです。外側から内側へ進めます。リモートからの入口を無効にし、新しい書き込みを停止し、最終バックアップを取得してテストし、アプリケーションを削除したうえで、ボリューム、バインドマウント、DNS、ファイアウォールルール、認証情報を慎重に確認します。どの永続データをアーカイブまたは意図的に破棄したかを把握するまでは、広範囲のpruneコマンドを使用しないでください。

削除前にデータ、マウント、アクセス経路を棚卸しする

Jellyfinのデータ/設定ディレクトリ、キャッシュ、メディアマウント、トランスコード先、バックアップフォルダー、リバースプロキシ、VPNまたはトンネル、DNS名、ファイアウォールルール、APIキーやサービス認証情報を一覧にします。それぞれを「保持」「再利用」「ローテーション」「削除」に分類します。

この棚卸しにより、アプリケーションコンテナをサービス全体と見なしてしまう、廃止時によくあるミスを防げます。ホームサーバーでは、重要な状態がバインドマウントや名前付きボリュームに保存されている一方、公開入口はまったく別のプロキシやDNS設定に存在することがよくあります。

サーバーにリモートからアクセスできた場合は、リモートアクセスのレイヤーを追跡する際と同じ構成を確認してください。パブリックDNS、プロキシ/VPN、ファイアウォール、ローカルサービスはそれぞれ別のレイヤーであり、各レイヤーを意図的に廃止する必要があります。

最後に正常動作しているインスタンスを停止する前に最終バックアップを作成する

サーバーが正常な状態にある間にJellyfinの最終バックアップを作成し、その後、Jellyfinホストやボリュームを削除しても残る保存先にコピーします。アーカイブにはJellyfinのバージョンと廃止日を記載します。

Jellyfinの公式バックアップ方法では、組み込みのバックアップ方法と手動バックアップ方法の両方が説明され、復元可能なサーバー状態を保持する方法が示されています。データベースと設定ファイルの整合性のないライブコピーを作成するのではなく、インストール環境に合ったドキュメント記載の方法を使用してください。

簡単な復元テストを行うか、少なくともアーカイブの内容を確認してから先に進みます。最終バックアップが不完全な場合は、稼働中のサーバーがまだ存在する間に問題を修正できるよう、廃止作業を中止してください。

アプリケーションを削除する前に外部アクセスを無効にする

Jellyfinを公開しているパブリックDNSレコード、リバースプロキシのルート、ポートフォワーディング、トンネル共有、VPN ACLを削除または無効にします。最初にこれを行うことで、最終確認のためにサーバーへローカルアクセスできる状態を保ちながら、公開経路を閉じられます。

外部ネットワークから、以前の公開Jellyfin URLまたはトンネルがサービスに到達しなくなったことを確認します。その後、バックアップと棚卸しを完了できる程度の時間、ローカルアクセスがまだ機能することを確認します。この両側からのテストにより、復元可能な状態を早まって破壊することなく、公開状態を閉じたことを検証できます。

Jellyfin専用だったAPIキーや認証情報をローテーションします。特に、サービス削除後も残るプロキシ設定、自動化スクリプト、監視システムに保存されていたものは必ず対象にしてください。

コンテナとボリュームを意図的に削除する

最終バックアップを確認してから、Jellyfinコンテナを停止して削除します。その後、すべてのバインドマウントと名前付きボリュームを確認し、それがJellyfin専用なのか、別のサービスと共有されているのかを判断します。

Dockerのドキュメントでは、ボリュームはコンテナの削除後も保持されると説明されています。コンテナを削除しても、すべての永続ボリュームが自動的に削除されるわけではありません。この永続性は復元に役立ちますが、明示的に処理するまで、不要になったアプリケーションデータがディスクに残ることも意味します。

複数のアプリケーションを稼働させているホストでは、最初のクリーンアップ手順としてdocker volume pruneを実行しないでください。確実に特定できたボリュームだけを削除し、最終アーカイブはそのクリーンアップ対象外の場所に保管します。

保護されていないJellyfinの状態が残っていないことを確認する

ホスト上で、以前のJellyfinデータパス、残存するComposeファイル、環境ファイル、プロキシの設定断片、バックアップアーカイブ、認証情報を検索します。残っている各項目について、通常のバックアップ/アクセス方針に従って保護するか、意図的に削除します。

残存するサービスのメディア権限が適切な状態であることを確認します。Jellyfin専用のユーザーやACLが不要になっている可能性はありますが、削除によって、同じグループや読み取り専用メディアマウントを意図的に共有していた別のコンテナを壊さないようにしてください。

古い公開経路が閉鎖され、最終バックアップが復元可能で、アプリケーションが稼働しておらず、残っているすべてのファイルや認証情報に明確な管理者が割り当てられていれば、廃止は完了です。ボリュームやバックアップの用途を確認できない場合は、無闇に削除せず隔離してください。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.