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

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Jellyfin benötigt keine einheitliche Aufbewahrungsdauer für Backups. Eine sichere Aufbewahrungsrichtlinie bewahrt genügend unabhängige Wiederherstellungspunkte auf, um Änderungen zurückzusetzen, die den Zustand am ehesten beschädigen können – insbesondere Upgrades, Konfigurationsänderungen, Plugin-Änderungen und Fehler von Administratoren – und stellt gleichzeitig sicher, dass mindestens eine ältere Kopie tatsächlich wiederhergestellt werden kann.

Denken Sie bei einem Heimserver eher in Wiederherstellungszeiträumen als an eine magische Anzahl: Bewahren Sie für alltägliche Fehler eine aktuelle rollierende Sammlung auf, halten Sie einen Wiederherstellungspunkt vor einem Upgrade so lange vor, bis die neue Version in Ihrem Haushalt ausreichend stabil läuft, und bewahren Sie mindestens eine ältere Generation außerhalb derselben Fehlergrenze auf. Testen Sie anschließend eine Wiederherstellung an einem temporären Pfad oder auf einer Bereitschaftsinstanz, bevor Sie die Kopie löschen, die Ihre einzige Rückkehrmöglichkeit wäre.

Beginnen Sie mit den Ereignissen, die den Zustand von gestern wertvoll machen können

Listen Sie die Änderungen auf, die den Zustand von Jellyfin beeinflussen können: Server-Upgrades, Plugin-Updates, Änderungen an Bibliothekspfaden, Benutzer- oder Berechtigungsänderungen, Metadatenbearbeitung und Speichermigrationen. Ihr Aufbewahrungszeitraum muss weit genug zurückreichen, um eine möglicherweise erst spät bemerkte fehlerhafte Änderung abzudecken.

Jellyfins Upgrade-Hinweise machen die Rücksetzgrenze ausdrücklich deutlich: Für die Rückkehr zu einer älteren Serverversion ist die Wiederherstellung eines vor dem Upgrade erstellten Backups erforderlich. Dadurch wird das Backup vor dem Upgrade zu einem besonderen Wiederherstellungspunkt und nicht nur zu einer weiteren täglichen Kopie.

Wenn Sie nur selten upgraden, kann das wichtige Backup bereits mehrere Wochen alt sein, wenn Sie eine schleichende Regression entdecken. Löschen Sie es nicht nur deshalb, weil ein Zähler für die tägliche Aufbewahrung es als alt einstuft, solange das Upgrade noch geprüft wird.

Verwenden Sie eine abgestufte Aufbewahrung, statt jede Kopie für immer zu behalten

Eine praktikable Richtlinie bewahrt für den jüngsten Zeitraum dichte Wiederherstellungspunkte auf und danach schrittweise weniger ältere Generationen. Sie könnten beispielsweise mehrere aktuelle tägliche Kopien sowie anschließend wöchentliche und monatliche Prüfpunkte aufbewahren. Passen Sie die Anzahl an Ihr Speicherbudget und die Häufigkeit von Änderungen an, statt einen festen Unternehmenszeitplan zu übernehmen.

Backup-Tools wie restic setzen dieses Konzept mit einer abgestuften Snapshot-Aufbewahrung für aktuelle, tägliche, wöchentliche, monatliche und jährliche Snapshots um. Dieser Ansatz ist nützlich, weil er mehrere Zeitskalen abdeckt, ohne jeden historischen Lauf unbegrenzt aufzubewahren.

Wenden Sie die Aufbewahrung getrennt auf die Jellyfin-Konfiguration und den Zustand sowie auf Ihre unersetzlichen Medien an, wenn ihre Wiederherstellungsanforderungen unterschiedlich sind. Erneut herunterladbare Metadaten benötigen möglicherweise nicht dieselbe lange Aufbewahrung wie Benutzer, Wiedergabeverlauf, sorgfältig gepflegte Bibliotheksdaten oder einzigartige Untertitel.

Bewahren Sie Backups vor dem Upgrade auf, bis die neue Version bewährt ist

Erstellen Sie vor einem Jellyfin-Upgrade ein benanntes oder markiertes Backup, das Ihr gewöhnlicher Bereinigungsauftrag nicht sofort löscht. Vermerken Sie darin die Jellyfin-Version und das Datum, damit Sie wissen, welche Serverversion zu diesem Zustand gehört.

Öffnen Sie nach dem Upgrade nicht nur die Startseite. Testen Sie die Anmeldung, das Durchsuchen der Bibliothek, geplante Aufgaben, Metadatenänderungen, eine normale Wiedergabe und alle hardwaretranskodierten Wiedergabepfade, auf die Ihr Haushalt angewiesen ist. Bewahren Sie den Punkt vor dem Upgrade während dieses Beobachtungszeitraums auf.

Für einen umfassenderen Schutz von Heimservern beschreibt das 3-2-1-Backup-Modell dieselbe Unterscheidung zwischen Arbeitsdaten und unabhängigen Wiederherstellungskopien. Entscheidend ist, dass die Aufbewahrung nur dann nützlich ist, wenn ein weiterer Ausfall nicht alle Generationen gleichzeitig löschen kann.

Schützen Sie mindestens eine Generation vor dem primären Host

Ein Backup-Ordner innerhalb desselben Jellyfin-Datenvolumes ist für eine schnelle Wiederherstellung praktisch, teilt jedoch die Fehlergrenze des Hosts, des Speicherpools und der Administration. Bewahren Sie eine weitere Kopie auf einem separaten Speicher oder extern auf, wenn der Zustand für Sie wichtig ist.

Verwechseln Sie Snapshots nicht mit unabhängigen Backups, wenn beide bei einem Ausfall desselben Pools, einem Ransomware-Angriff, einer versehentlichen Bereinigung oder dem Verlust des Hosts verschwinden. Snapshots können hervorragende kurzfristige Rücksetzpunkte sein, während ein zweites Gerät oder eine externe Kopie vor einer anderen Fehlerklasse schützt.

Nachdem Sie eine ältere Generation an einen anderen Ort kopiert haben, prüfen Sie, ob Sie deren Inhalt auflisten können und ob Ihre Wiederherstellungsnotizen die passende Jellyfin-Version nennen. Ein Backup, das sich keinem nutzbaren Wiederherstellungsverfahren zuordnen lässt, ist trotz vieler Kopien eine schwache Aufbewahrung.

Löschen Sie alte Generationen erst, nachdem ein Wiederherstellungstest die verbleibende Sammlung bestätigt hat

Stellen Sie vor dem Löschen alter Generationen ein aktuelles Backup und einen älteren Prüfpunkt an einem temporären Ort oder auf einer Bereitschaftsinstanz wieder her. Damit soll nachgewiesen werden, dass sich das Archiv öffnen lässt, der erwartete Zustand vorhanden ist und Ihre Wiederherstellungsschritte auch nach Änderungen an Pfaden oder der Bereitstellungsmethode noch gültig sind.

Wenn der Test fehlschlägt, beenden Sie die Bereinigung. Beheben Sie den Backup-Prozess, solange die älteren Generationen noch vorhanden sind, denn deren Löschung würde aus einem Aufbewahrungsproblem ein Wiederherstellungsproblem machen.

Die Aufbewahrung ist ausreichend, wenn sie Ihr wahrscheinliches Erkennungsfenster abdeckt, benannte Prüfpunkte vor Änderungen bewahrt, mindestens eine unabhängige Fehlergrenze überwindet und regelmäßige Wiederherstellungstests besteht. Erhöhen Sie sie, wenn Änderungen häufig auftreten oder Fehler erst spät entdeckt werden; reduzieren Sie sie nur, wenn die verbleibenden Generationen diese Wiederherstellungsziele weiterhin erfüllen.

Support & 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.