安全な復旧に必要な Jellyfin のバックアップ保持期間は？

エヴァ・ウォン

IceWhale author

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

What Backup Retention Does Jellyfin Need for Safe Recovery? - Zima Store Online

Jellyfinに普遍的に適用できるバックアップ保持数はありません。安全な保持ポリシーでは、状態に深刻な影響を与える可能性が高い変更、特にアップグレード、設定編集、プラグイン変更、管理者のミスより前の状態へ戻せるよう、十分な数の独立した復元ポイントを保持します。同時に、少なくとも1つの古いコピーを実際に復元できることも確認します。

ホームサーバーでは、決まった数字ではなく復旧期間で考えましょう。日常的なミスに備えて最近のコピーをローリング方式で保持し、新しいバージョンが家庭で十分安定するまでアップグレード前の復元ポイントを保存します。また、同じ障害範囲の外に少なくとも1世代古いコピーを保管します。そのうえで、唯一の復旧手段となるコピーを削除する前に、使い捨てのパスや待機インスタンスで復元テストを行います。

昨日の状態に価値が生じる可能性のあるイベントから始める

Jellyfinの状態を変える可能性のある変更を一覧にします。サーバーのアップグレード、プラグインの更新、ライブラリパスの編集、ユーザーや権限の変更、メタデータの編集、ストレージの移行などです。保持期間は、すぐには気付けない不具合のある変更より前までさかのぼれる長さにする必要があります。

Jellyfinのアップグレードに関するガイダンスでは、ロールバックの境界が明確に示されています。古いサーバーバージョンへ戻すには、アップグレード前に取得したバックアップを復元する必要があります。そのため、アップグレード前のバックアップは単なる日次コピーではなく、特別な復元ポイントとして扱います。

アップグレードの頻度が低い場合、微妙な退行に気付いた時点で重要なバックアップが数週間前のものになっていることがあります。アップグレードの評価が続いている間は、日次保持のカウンター上で古くなったからといって削除しないでください。

すべてのコピーを永久に保持せず、階層化した保持を使う

実用的なポリシーでは、最近の期間には復元ポイントを密に保持し、古い世代ほど数を段階的に減らします。たとえば、最近の日次コピーを数個保持し、その後に週次および月次のチェックポイントを残す方法があります。固定された企業向けスケジュールをそのまま使うのではなく、ストレージ容量と変更頻度に合わせて数を調整します。

resticなどのバックアップツールは、最近、日次、週次、月次、年次のスナップショットに対する階層化されたスナップショット保持によって、この考え方を実装しています。この仕組みは、過去のすべての実行結果を無期限に保持せず、複数の時間スケールを維持できる点で便利です。

Jellyfinの設定と状態には、復旧要件が異なる場合、かけがえのないメディアとは別に保持ポリシーを適用します。再ダウンロード可能なメタデータは、ユーザー、視聴履歴、丁寧に整理したライブラリの状態、固有の字幕ほど長期保持する必要がないかもしれません。

新しいバージョンの信頼性が確認できるまでアップグレード前のバックアップを保持する

Jellyfinをアップグレードする前に、通常の削除ジョブですぐに削除されないよう、名前またはタグを付けたバックアップを作成します。そのバックアップにJellyfinのバージョンと日付を記録し、どのサーバーバージョンに対応する状態なのか分かるようにします。

アップグレード後は、ホームページを開くだけで済ませないでください。ログイン、ライブラリの閲覧、スケジュールタスク、メタデータの編集、通常の再生経路、そして家庭で利用しているハードウェアトランスコードの経路をテストします。この確認期間中は、アップグレード前の復元ポイントを保持します。

より広範なホームサーバー保護については、稼働中のデータと独立した復旧コピーの違いが、3-2-1バックアップモデルで説明されています。重要なのは、別の障害によってすべての世代が同時に消去されない場合にのみ、保持が役立つということです。

Featured

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

ZimaCube2

少なくとも1世代をプライマリホストから隔離して保護する

同じJellyfinデータボリューム内にバックアップフォルダーを置くと迅速な復元には便利ですが、ホスト、ストレージプール、管理上の障害範囲を共有します。状態が重要であれば、別のストレージまたはオフサイトにも別のコピーを保管します。

同じプール、ランサムウェア被害、誤った削除、ホスト喪失によって両方とも消える場合、スナップショットを独立したバックアップと混同しないでください。スナップショットは短期的なロールバックポイントとして非常に優れていますが、別のデバイスやオフサイトコピーは異なる種類の障害から保護します。

古い世代を別の場所へコピーした後、その内容を一覧表示できることと、復旧手順のメモで対応するJellyfinのバージョンを特定できることを確認します。コピーが多数あっても、使用可能な復元手順に結び付けられないバックアップは、保持としては不十分です。

復元テストで残すセットを確認してから削除する

古い世代を削除する前に、最近のバックアップを1つと古いチェックポイントを1つ、使い捨ての場所または待機インスタンスへ復元します。目的は、アーカイブを開けること、想定した状態が存在すること、パスやデプロイ方法の変更後も復元手順が有効であることを確認することです。

テストに失敗した場合は、削除を中止します。古い世代がまだ存在するうちにバックアッププロセスを修正してください。それらを削除すると、保持の問題が復旧の問題に変わってしまいます。

保持が十分なのは、想定される発見までの期間をカバーし、変更前の名前付きチェックポイントを保存し、少なくとも1つの独立した障害範囲をまたぎ、定期的な復元テストを通過する場合です。変更頻度が高い場合や障害の発見が遅れる場合は保持期間を延ばします。残した世代がこうした復旧目標を満たしていることを確認した後にのみ、短縮してください。