So sichern Sie Plex, ohne eine inkonsistente Datenbank zu erfassen

Für eine vollständige Sicherung der Plex-App-Daten sollten Sie Plex vor dem Kopieren des Dateisystems oder dem Erstellen eines Snapshots stoppen. Für die reine Kerndatenbank ist die geplante Sicherung von Plex der anwendungsspezifische Weg.

Plex schreibt Datenbanken, Metadaten, Einstellungen und den Cache, während der Server ausgeführt wird. Daher kann ein allgemeiner Sicherungsauftrag Dateien aus unterschiedlichen Zeitpunkten erfassen. Das bedeutet nicht, dass jede Sicherung im laufenden Betrieb beschädigt ist, aber eine Rohkopie ist schwerer vertrauenswürdig einzuschätzen, sofern nicht die Anwendung oder die Speicherebene die Konsistenz koordiniert. Entscheiden Sie zunächst, ob Sie die Plex-Kerndatenbank oder den vollständigen Serverzustand benötigen. Verwenden Sie anschließend eine Methode, die zu diesem Umfang passt, und prüfen Sie einen Wiederherstellungsweg, bevor Sie die Sicherung als abgeschlossen betrachten.

Unterscheiden Sie zwischen der Sicherung der Kerndatenbank und einer vollständigen Sicherung der Serverdaten

Die geplanten Aufgaben von Plex können die Kerndatenbanken sichern, in denen Wiedergabestatus und Zuordnungsinformationen gespeichert sind. Das ist für die Wiederherstellung der Datenbank hilfreich, ersetzt laut Plex jedoch ausdrücklich nicht die Sicherung des gesamten Datenverzeichnisses von Plex Media Server. Betrachten Sie diese beiden Sicherungen als unterschiedliche Werkzeuge für die Wiederherstellung, statt anzunehmen, dass eine Datei alles abdeckt.

Die Plex-Dokumentation zur Datensicherung empfiehlt, das zentrale Serverdatenverzeichnis zu sichern, und weist darauf hin, dass der Cache auf einigen Plattformen ausgeschlossen werden kann. Legen Sie den Sicherungsumfang bewusst fest, damit temporäre Cache-Daten das Archiv nicht unnötig vergrößern, während wichtige Datenbank- und Metadaten geschützt bleiben.

Wenn Ihr Ziel lautet: „Den Server genau so wiederherstellen, wie er war“, sollten Sie den persistenten App-Datenbaum sowie alle plattformspezifischen Einstellungen einbeziehen, die Plex benötigt. Wenn Ihr Ziel lediglich lautet: „Wiedergabestatus und zentrale Bibliotheksdatenbank wiederherstellen“, kann die geplante Datenbanksicherung eine kleinere, gezieltere Ausweichlösung sein.

Versetzen Sie Plex vor einer Rohkopie des Dateisystems in einen ruhenden Zustand

Für eine einfache Sicherung auf Dateiebene sollten Sie den Plex-Container stoppen und bestätigen, dass er beendet wurde, bevor Sie den persistenten Datenpfad kopieren oder einen Snapshot erstellen. Halten Sie die Ausfallzeit kurz: stoppen, den konsistenten Stand erfassen, neu starten und anschließend die langsamere Kopie auf ein anderes Gerät vom Snapshot aus fortsetzen, sofern Ihr Dateisystem diesen Ablauf unterstützt.

Die Dokumentation der SQLite-Sicherungs-API zeigt, warum das Kopieren einer Live-Datenbank ein Koordinationsproblem und nicht einfach nur ein Problem der Dateigröße ist. Eine anwendungsbewusste Sicherung oder ein Snapshot im ruhenden Zustand liefert einen definierten Datenbankstand. Werden sich ändernde Datenbank-, WAL- und Metadatendateien blind kopiert, besteht weniger Gewissheit über den Wiederherstellungspunkt.

Stoppen Sie Plex nicht stundenlang, während eine große Sicherung langsamen Speicher durchsucht, wenn Ihr NAS einen sofortigen Snapshot erstellen kann. Das sicherere Vorgehen besteht aus einer kurzen Schreibpause zur Herstellung der Konsistenz, gefolgt von einem Snapshot- oder Archivierungsprozess, durch den der Dienst wieder verfügbar sein kann, während die Sicherung an einen anderen Ort übertragen wird.

Behandeln Sie Protokolle, Cache und persistente Daten nach unterschiedlichen Wiederherstellungsregeln

Cache und ausführliche Protokolle können sich schnell ändern und benötigen in der Regel nicht dieselbe Aufbewahrungsdauer wie die Plex-Datenbank und die Metadaten. Durch die Trennung dieser Pfade werden Sicherungen kleiner und die Grenze der Wiederherstellung klarer. Außerdem verhindert sie, dass ein umfangreicher Protokoll- oder Cache-Baum den für den Anwendungszustand reservierten Speicher aufbraucht.

Der ZimaSpace-Leitfaden zur Trennung von Container-Protokollen und App-Daten erklärt, warum Anwendungszustand, Protokolle und Cache unterschiedliche Lebenszyklen und Anforderungen an die Wiederherstellung haben. Plex profitiert von derselben Richtlinie, auch wenn alle drei Bereiche zunächst in einer einzigen Containerkonfiguration liegen.

Wenn Sie den Sicherungsumfang ändern, führen Sie einen Wiederherstellungstest mit einer wegwerfbaren Kopie oder einem isolierten Container durch. Eine Sicherungsrichtlinie ist nicht allein durch einen erfolgreichen Upload validiert, sondern erst dann, wenn Plex die wiederhergestellte Datenbank und die Metadaten mit dem erwarteten Serverzustand öffnen kann.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Überprüfen Sie die Sicherung durch die Wiederherstellung eines bekannten Zustands

Wählen Sie einige Fakten aus, die Sie nach einer Wiederherstellung überprüfen können: Servername, eine Bibliothek, ein vollständig angesehenes Element, ein teilweise angesehenes Element und eine Ihnen bekannte Einstellung. Bei einem Test der Wiederherstellung sollten diese Fakten wiederhergestellt werden, ohne dass Plex einen neuen Server anlegen oder die Bibliothek aus den Mediendateien neu aufbauen muss.

Plex beschreibt ein Verfahren zur Wiederherstellung einer über geplante Aufgaben gesicherten Datenbank, das mit dem Stoppen des Servers und dem Ersetzen der aktiven Datenbank durch eine Sicherung beginnt. Auch wenn sich Ihre Methode für die vollständige Sicherung unterscheidet, ist die Grenze „vor dem Ersetzen der Datenbank stoppen“ eine nützliche Wiederherstellungsregel.

Wenn der Wiederherstellungstest fehlschlägt, verbessern Sie zunächst die Sicherungsmethode, bevor Sie die Aufbewahrungsdauer erhöhen oder weitere Kopien automatisieren. Ziehen Sie eine Reparatur der Datenbank erst dann in Betracht, wenn sich eine nachweislich intakte Sicherung nicht wiederherstellen lässt. Überschreiben Sie die letzte wiederherstellbare Kopie nicht, während Sie mit einer beschädigten Live-Datenbank experimentieren.