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

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

小規模な環境では、複数の役割を1台のマシンに置いてもかまいませんが、それぞれのライフサイクルを混同してはいけません。変更される状態は簡単にスナップショットできるようにし、メディアには安定した論理パスを使い、キャッシュは破棄可能にして、少なくとも1つの復旧用コピーを稼働中の障害ドメインの外に保管します。保持期間を自動化したりディスクを追加したりする前に、クリーンな復元先で復元して設計を検証してください。

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

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

プラグイン、証明書、字幕、カスタムアセットのいずれかに保存先が決まっていない場合は、ここで作業を止めてください。永続パスを分類しないままにすると、元のサーバーがなくなってから初めて見つかるファイルが生まれます。

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

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

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

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

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

少なくとも1つの使用可能なコピーは、稼働中のホストと接続ストレージの損失や破損を乗り越えられる場所に保管する必要があります。ミラープールはデバイス故障時の可用性を高めますが、同期された削除やデータベースの破損はすべてのミラーに及ぶ可能性があります。冗長化とバックアップは、異なる障害に対応するものです。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

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

1. ソースのバージョン、実行時の識別情報、マウント構成、バックアップのチェックサムを記録します。
2. クリーンな隔離環境のターゲットに状態を復元します。
3. ユーザー、ライブラリ、メタデータ、代表的な再生を確認します。
4. 1回再起動して、主要なチェックを繰り返します。
5. 手順にかかる時間を計測し、手作業で必要だった依存項目をすべてランブックに反映します。

文書化されていないシークレット、パスの書き換え、本番ファイルの使用が必要なら、その訓練は失敗とします。この手順を手動で2回成功させてから、自動化に進みます。

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

緊急に追われることなくデータをコピーして検証できるよう、早めに拡張のしきい値を決めます。使用可能なプール容量の約4分の3を継続的に使用している状態は、計画を立てるための目安であり、普遍的な法則ではありません。実際のトリガーは、データ取り込み速度、再構築時間、バックアップ所要時間、空き容量アラートの履歴に基づいて設定します。

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

トポロジー全体とその制約を検証する

設計全体をシステムとして運用しましょう。計画的なシャットダウン後のコールドスタート、依存要素が1つ使えない状態での起動、テストボリュームをアラートしきい値まで埋めること、状態チェックポイントの復元、拡張後のパスからのメディア読み取りを行います。どの処理が安全側に停止するか、何が劣化するか、どの処理にオペレーターの対応が必要かを記録します。

合計負荷、配線、電力、復旧時間が目標範囲内である限り、1台のホストに複数の役割を持たせましょう。測定した容量、メンテナンス、障害ドメインの制約が現れた場合に限り、メディアストレージ、バックアップ、復旧機能を分離します。マシンを増やすと、それ自体がネットワークやライフサイクルへの依存関係を生みます。

最終的なルールはシンプルです。安定した論理パスを維持し、再構築できない状態を個別に保護し、トポロジーを変更するたびに復旧を実証します。復元できない容量は、利用可能な容量とは言えません。