Welche Backup-Aufbewahrungsdauer benötigt Jellyfin für eine sichere Wiederherstellung?

Eva Wong ist die technische Redakteurin und begeisterte Tüftlerin bei ZimaSpace. Als lebenslanger Geek mit einer Leidenschaft für Homelabs und Open-Source-Softwarehat sie sich darauf spezialisiert, komplexe technische Konzepte in verständliche, praxisnahe Anleitungenzu übersetzen. Eva ist überzeugt, dass Self-Hosting Spaß machen sollte und nicht einschüchternd sein darf. Mit ihren Tutorials hilft sie der Community dabei, Hardware-Setups zu durchschauen, vom Bau des ersten NAS bis zum sicheren Umgang mit Docker-Containern.

Für Jellyfin gibt es keine allgemeingültige Anzahl von Sicherungen, die aufbewahrt werden sollte. Eine sichere Aufbewahrungsrichtlinie bewahrt genügend unabhängige Wiederherstellungspunkte auf, um Änderungen rückgängig machen zu können, die den Zustand am ehesten beeinträchtigen – insbesondere Upgrades, Konfigurationsänderungen, Plugin-Änderungen und Fehler von Administratoren – und stellt zugleich sicher, dass sich mindestens eine ältere Kopie tatsächlich wiederherstellen lässt.

Denken Sie bei einem Heimserver in Wiederherstellungszeiträumen statt an eine magische Anzahl: Bewahren Sie eine aktuelle, fortlaufend erneuerte Auswahl für alltägliche Fehler auf, sichern Sie einen Wiederherstellungspunkt von vor dem Upgrade, bis die neue Version für Ihren Haushalt lange genug stabil gelaufen ist, und bewahren Sie mindestens eine ältere Generation außerhalb derselben Fehlergrenze auf. Testen Sie anschließend eine Wiederherstellung in einem entbehrlichen Verzeichnis oder auf einer Standby-Instanz, bevor Sie die Kopie löschen, die Ihre einzige Möglichkeit zur Rückkehr wäre.

Beginnen Sie mit den Ereignissen, durch die der Zustand von gestern wertvoll werden kann

Führen Sie die Änderungen auf, die den Jellyfin-Status beeinflussen können: Server-Upgrades, Plugin-Updates, Änderungen an Bibliothekspfaden, Änderungen an Benutzern oder Berechtigungen, Metadatenbearbeitung und Speichermigrationen. Ihr Aufbewahrungszeitraum muss weit genug zurückreichen, um eine fehlerhafte Änderung abzudecken, die möglicherweise nicht sofort bemerkt wird.

Jellyfins Upgrade-Anleitung macht die Grenze für ein Rollback deutlich: Für die Rückkehr zu einer älteren Serverversion ist die Wiederherstellung einer vor dem Upgrade erstellten Sicherung erforderlich. Damit ist die Sicherung vor dem Upgrade ein besonderer Wiederherstellungspunkt und nicht bloß eine weitere tägliche Kopie.

Wenn Sie nur selten Upgrades durchführen, kann die wichtige Sicherung schon mehrere Wochen alt sein, wenn Sie eine schwer erkennbare Regression entdecken. Löschen Sie sie nicht einfach, weil ein Zähler für die tägliche Aufbewahrung sie als veraltet einstuft, solange das Upgrade noch geprüft wird.

Gestaffelte Aufbewahrung statt jede Kopie für immer aufzubewahren

Eine praktische Richtlinie bewahrt für den jüngsten Zeitraum viele Wiederherstellungspunkte auf und reduziert die Zahl älterer Generationen schrittweise. Beispielsweise könnten Sie mehrere aktuelle tägliche Kopien und anschließend wöchentliche und monatliche Sicherungspunkte aufbewahren. Passen Sie die Anzahl an Ihr Speicherbudget und die Häufigkeit von Änderungen an, statt einen starren Unternehmensplan zu kopieren.

Sicherungstools wie restic setzen dieses Prinzip mit einer gestaffelten Aufbewahrung von Schnappschüssen für aktuelle, tägliche, wöchentliche, monatliche und jährliche Schnappschüsse um. Dieser Ansatz ist nützlich, weil er mehrere Zeiträume abdeckt, ohne jede historische Sicherung unbegrenzt aufzubewahren.

Wenden Sie auf Jellyfin-Konfiguration und -Status eine separate Aufbewahrungsrichtlinie an, wenn sich deren Wiederherstellungsbedarf von dem Ihrer unersetzlichen Medien unterscheidet. Erneut herunterladbare Metadaten benötigen möglicherweise keine ebenso lange Aufbewahrung wie Benutzer, Wiedergabeverlauf, sorgfältig gepflegte Bibliotheksdaten oder einzigartige Untertitel.

Sicherungen vor dem Upgrade aufbewahren, bis die neue Version sich bewährt hat

Erstelle vor einem Jellyfin-Upgrade eine benannte oder markierte Sicherung, die nicht sofort durch deinen normalen Ausdünnungsauftrag gelöscht wird. Notiere dazu die Jellyfin-Version und das Datum, damit du weißt, welche Serverversion zu diesem Zustand gehört.

Prüfe nach dem Upgrade mehr als nur, ob sich die Startseite öffnen lässt. Teste die Anmeldung, das Durchsuchen der Bibliothek, geplante Aufgaben, Metadatenänderungen, einen normalen Wiedergabeweg und alle hardwaretranscodierten Wiedergabewege, auf die dein Haushalt angewiesen ist. Bewahre den Prüfpunkt von vor dem Upgrade während dieses Beobachtungszeitraums auf.

Für einen umfassenderen Schutz deines Home-Servers wird derselbe Unterschied zwischen Arbeitsdaten und unabhängigen Wiederherstellungskopien im 3-2-1-Backup-Modell beschrieben. Entscheidend ist, dass die Aufbewahrung nur dann nützt, wenn ein anderer Ausfall nicht alle Generationen auf einmal vernichten kann.

Mindestens eine Generation außerhalb des primären Hosts schützen

Ein Sicherungsordner innerhalb desselben Jellyfin-Datenvolumes ermöglicht eine bequeme schnelle Wiederherstellung, unterliegt aber denselben Grenzen bei Host, Speicherpool und Verwaltungsfehlern. Bewahre eine weitere Kopie auf separatem Speicher oder extern auf, wenn dir der Zustand wichtig ist.

Verwechsle Snapshots nicht mit unabhängigen Sicherungen, wenn beide beim Ausfall desselben Speicherpools, bei einem Ransomware-Vorfall, versehentlichem Ausdünnen oder Verlust des Hosts verloren gehen. Snapshots eignen sich hervorragend als kurzfristige Rollback-Punkte, während ein zweites Gerät oder eine externe Kopie vor einer anderen Art von Ausfall schützt.

Nachdem du eine ältere Generation an einen anderen Ort kopiert hast, prüfe, ob du ihren Inhalt auflisten kannst und ob deine Wiederherstellungsnotizen die passende Jellyfin-Version angeben. Eine Sicherung, die sich keinem brauchbaren Wiederherstellungsverfahren zuordnen lässt, bietet nur schwachen Schutz durch Aufbewahrung, selbst wenn viele Kopien vorhanden sind.

Erst nach einem erfolgreichen Wiederherstellungstest ausdünnen

Stelle vor dem Löschen älterer Generationen eine aktuelle Sicherung und einen älteren Prüfpunkt an einem temporären Speicherort oder auf einer Standby-Instanz wieder her. Damit soll nachgewiesen werden, dass sich das Archiv öffnen lässt, der erwartete Zustand vorhanden ist und deine Wiederherstellungsschritte nach Änderungen an Pfaden oder Bereitstellungsmethoden weiterhin funktionieren.

Wenn der Test fehlschlägt, stelle das Ausdünnen ein. Behebe den Sicherungsprozess, solange die älteren Generationen noch vorhanden sind, denn wenn du sie löschst, wird aus einem Aufbewahrungsproblem ein Wiederherstellungsproblem.

Die Aufbewahrungsdauer ist ausreichend, wenn sie den wahrscheinlichen Zeitraum bis zur Fehlererkennung abdeckt, benannte Prüfpunkte vor Änderungen bewahrt, mindestens eine unabhängige Fehlergrenze überschreitet und regelmäßige Wiederherstellungstests besteht. Erhöhe sie bei häufigen Änderungen oder spät entdeckten Fehlern; verkürze sie nur, wenn die verbleibenden Generationen weiterhin diese Wiederherstellungsziele erfüllen.

Support und Tipps

Mehr zum Lesen

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.