安全に復旧するには、Jellyfinのバックアップをどれくらいの期間保持する必要がありますか？

Jellyfinに一律のバックアップ保持期間はありません。安全な保持ポリシーでは、状態を損なう可能性が最も高い変更、特にアップグレード、設定編集、プラグインの変更、管理者のミスより前に戻せるだけの、独立した復元ポイントを十分に確保します。同時に、古いコピーの少なくとも1つが実際に復元できることも確認してください。

ホームサーバーでは、決まった数ではなく復旧期間を基準に考えてください。日常的なミスに備えて直近のバックアップを一定期間保持し、アップグレード前の復元ポイントは、新バージョンが家庭で十分安定したと判断できるまで残し、同じ障害の影響を受けない場所に少なくとも1世代前のバックアップを保管します。そして、唯一の復旧手段となるコピーを削除する前に、使い捨てのパスか待機系インスタンスで復元をテストしてください。

昨日の状態が貴重になるきっかけから考える

Jellyfinの状態を変える可能性がある変更を挙げてください。サーバーのアップグレード、プラグインの更新、ライブラリパスの編集、ユーザーや権限の変更、メタデータの作業、ストレージの移行などです。すぐには気付かない不適切な変更より前までさかのぼれるよう、保持期間を設定してください。

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

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

すべてのコピーを永久に残すのではなく、階層型の保持を使う

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

resticなどのバックアップツールでは、階層型スナップショット保持によって、最近、日次、週次、月次、年次のスナップショットを管理できます。この仕組みは、過去の実行分をいつまでもすべて保持せずに、複数の時間軸のバックアップを残せるため便利です。

Jellyfinの設定と状態は、復旧に必要な期間が異なる場合、かけがえのないメディアとは分けて保持期間を設定してください。再ダウンロードできるメタデータは、ユーザー情報、視聴履歴、丁寧に整備したライブラリの状態、固有の字幕と同じ長さで保持する必要がない場合があります。

新しいバージョンの動作を確認するまでアップグレード前のバックアップを保持する

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

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

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

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

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

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

古い世代を別の場所にコピーした後、その内容を一覧表示できることと、復旧メモに対応するJellyfinのバージョンが記載されていることを確認してください。何世代も残っていても、使える復元手順と対応付けられないバックアップでは、十分な保持とは言えません。

復元テストで残す世代を確認してから整理する

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

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

保持期間が適切なのは、想定される検知期間をカバーし、変更前のチェックポイントとして名前を付けたバックアップを保持し、少なくとも1つの独立した障害境界を越えて保管され、定期的な復元テストに合格する場合です。変更の頻度が高い場合や、障害の発見が遅れる場合は保持期間を延ばしてください。残す世代で復旧目標を満たせると確認できた場合にのみ、短縮してください。