初日からJellyfinのバックアップ、復元、拡張を設計する方法

エヴァ・ウォン

IceWhale author

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

How to Design Jellyfin Backup, Restore, and Expansion From Day One - Zima Store Online

Jellyfinを、ブート、アプリケーションの状態、メディア、キャッシュ、バックアップ、復旧という6つの独立した役割として設計し、限界に近づいた役割だけを拡張します。

小規模なインストールでは、複数の役割を1台のマシンに配置しても構いませんが、それぞれのライフサイクルを曖昧にしてはいけません。変更される状態はスナップショットしやすく、メディアは安定した論理パスの背後に置き、キャッシュは破棄可能にし、少なくとも1つの復旧コピーは稼働中の障害ドメインの外部に保持します。保持期間の自動化やディスクの追加を行う前に、クリーンなターゲットへ復元して設計を検証します。

ディスクを選ぶ前に6つのデータ役割を整理する

ドライブベイではなく、成果から始めます。ブートおよびランタイムファイルは再現可能である必要があります。Jellyfinのデータベース、設定、ユーザー、視聴履歴、整理したメタデータは永続状態です。メディアは容量の大きいユーザーデータ、トランスコードと画像キャッシュは再構築可能なデータ、バックアップは復旧への入力データであり、復旧ターゲットはそれらの入力データを検証する場所です。

この分離により、費用のかかる2つのミスを防げます。変化するデータベースと同じ頻度で、廃棄可能なキャッシュのテラバイトまでバックアップしてしまうこと、またはデータベースを保護する一方で、かけがえのないホームビデオを2つ目のコピーなしで放置することです。独立したUbuntuおよびDockerの復元手順でも、永続的な設定と再構築可能なキャッシュを区別しています。

役割	代表的な内容	設計ルール
ブート／システム	OS、パッケージ、ランタイム定義	文書化または画像化し、再構築できることを前提にする
アプリケーションの状態	データベース、ユーザー、設定、メタデータ	高速なローカルストレージと、一貫性のあるバックアップ
ユーザーメディア	映画、音楽、家族のファイル	安定したパスと個別の保護ポリシー
キャッシュ	トランスコード、サイズ変更済み画像、一時作業	スループット用に配置し、再構築を許容
バックアップ	バージョン管理された復旧コピー	稼働中の障害ドメインの外部に保持
復旧	クリーンなテストホストまたは分離された名前空間	本番データの保存ではなく、復元の証明に使う

どのプラグイン、証明書、字幕、カスタムアセットにもまだ所有者が割り当てられていないなら、ここで止めてください。分類されていない永続パスは、元のサーバーが失われた後になって初めて発見されるファイルになります。

状態をローカルに保持し、メディアパスを安定させる

アプリケーションの状態は、空き容量を監視できる信頼性の高いローカルSSDストレージに配置します。メディアは、ディスク、エンクロージャ、またはプールを変更しても維持できる論理パスに、別途マウントします。背後のストレージ層が変わっても、拡張の前後でJellyfinサービスから同じパスが見えるようにします。

キャッシュは復旧の依存先ではなく、スループットを消費するものとして扱います。軽いワークロードならシステムSSDと共有してもよいですが、書き込み量、容量、または摩耗が測定可能な問題になったら、専用の高速ボリュームに移します。両方とも小さいという理由だけで、データベースとキャッシュを一緒に移動しないでください。

起動するたびに、メディアと状態のマウントが存在し、実行時のIDで書き込み可能であることを必須条件にします。ネットワークマウントが見つからず、空のローカルディレクトリとして暗黙に扱われると、誤ったパスに対してスキャンや書き込みが実行される可能性があります。関連する権限とIDの復旧ガイドでは、パス変更後の所有権の境界について説明しています。

復旧オブジェクトを中心にバックアップを構築する

アプリケーションの状態を、整合性のある1つの復旧オブジェクトとしてバックアップします。最も単純な構成では、短いコピー時間の間Jellyfinを停止します。ストレージスナップショットは、すべての状態コンポーネントを復元可能な1つの時点で取得できる場合に限り適切です。データベースの移行によって、安易なイメージのダウングレードが危険になる可能性があるため、各チェックポイントの横にJellyfinのバージョンを記録します。

メディアは異なる頻度で保護します。購入したメディアは入手元から再取得できる場合がありますが、家族の録画は再現できないかもしれません。レプリケーション、オフラインコピー、オフサイトストレージのいずれかを選ぶ前に、これらのサブセットを分類してください。次に保持期間と復旧ウィンドウのガイドで、状態の世代をいくつ保持するかを決めます。

アクティブなホストと接続ストレージの損失または破損に耐えられる、使用可能なコピーを少なくとも1つ残す必要があります。ミラープールはデバイス障害後の可用性を高めますが、同期された削除やデータベースの破損はすべてのミラーに及ぶ可能性があります。冗長化とバックアップは、異なる障害に対応します。

Featured

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

ZimaCube2

自動化の前にクリーンな復元をリハーサルする

同じJellyfinバージョン（チェックポイントを作成したバージョン）を使用する隔離マシン、VM、またはコンテナに復元します。実行時のIDと論理マウントを再現し、新しいサーバーを本番クライアントに公開せずに起動します。その後、管理者ログイン、ユーザー履歴、ライブラリ数、アートワーク、Direct Playで再生できる項目を1つ、代表的なトランスコードを1つ確認します。

重要なのはダッシュボードが読み込まれることではありません。最近のTrueNASの移行事例は、アプリケーションの状態、チャートの世代、新しいコンテナ経路が衝突し得ることを示しています。古いインスタンスがまだ存在する間にクリーンなリハーサルを行うことで、こうした依存関係を明らかにできます。

ソースのバージョン、ランタイムのID、マウントマップ、バックアップのチェックサムを記録します。
クリーンで分離されたターゲットに状態を復元します。
ユーザー、ライブラリ、メタデータ、代表的な再生を検証します。
1度再起動し、主要なチェックを繰り返します。
手順にかかる時間を計測し、手動で必要になった項目をすべてランブックに反映します。

文書化されていない秘密情報、パスの書き換え、または稼働中の本番ファイルが必要になる場合は、そのドリルを失敗とします。自動化は、この手動シーケンスを2回成功させた後に導入し、その前には行いません。

ライブラリ名を変更せずに容量を拡張する

緊急の圧力なしにデータをコピーして検証できるよう、十分早い段階で拡張しきい値を決めます。使用可能なプールの約4分の3で利用率が持続することは計画上の目安であり、普遍的な規則ではありません。実際のトリガーは、取り込み速度、再構築時間、バックアップ所要時間、空き容量アラートの履歴を使って設定します。

可能な場合は、既存の論理メディアパスの背後で拡張します。新しいデバイスまたはプールを準備し、正常性と書き込み動作を検証し、最初の代表的なデータセットは移動ではなくコピーし、件数またはハッシュを比較してから、ライブラリスキャンと再生をテストします。その後、新しい容量を通常の書き込みに加えます。

拡張に新しいファイルシステム、ホスト、共有プロトコル、またはマウントパスも必要になる場合は、別々の変更に分けます。コンピュート、ストレージ、バックアップのトポロジーを使うと、1台のボックスを拡張するのではなく、容量の増加に応じて役割を分離すべきタイミングを判断できます。

トポロジー全体とその限界を検証する

設計をシステムとして運用します。管理されたシャットダウン後のコールドスタート、1つの依存先が利用できない状態での起動、テストボリュームをアラートしきい値まで埋める操作、状態チェックポイントの復元、拡張後のパスからのメディア読み取りを実行します。どの処理がフェイルクローズし、何が機能低下し、何にオペレーターの対応が必要かを記録します。

複数の役割を1台のホストにまとめたままにするのは、それらの合算した負荷、配線、電力、復旧時間が目標範囲内に収まる場合です。測定によって容量、保守、または障害ドメインの限界が明らかになった場合にのみ、メディアストレージ、バックアップ、または復旧を分離します。マシンを増やすと、それ自体にネットワークとライフサイクルの依存関係が生じます。

最後のルールはシンプルです。安定した論理パスを維持し、再構築できない状態を独立して保護し、トポロジーを変更するたびに復旧を実証します。復元できない容量は、完成した容量とは言えません。