So reparieren Sie Jellyfin, nachdem das Datenbank-Volume vollgelaufen ist

Eva Wong

IceWhale author

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.

How to Repair Jellyfin After Its Database Volume Fills Up - Zima Store Online

Wenn das Datenbankvolume von Jellyfin voll ist, stoppen Sie neue Schreibvorgänge, bewahren Sie die Datenbank- und WAL-Dateien auf, schaffen Sie sicher Speicherplatz und überprüfen Sie die Datenbank, bevor Sie reguläre Aufgaben neu starten.

Startet Jellyfin nicht, meldet SQLite-Fehler oder öffnet es sich mit fehlenden Benutzern, nachdem auf dem Volume kein freier Speicherplatz mehr vorhanden war? Löschen Sie Datenbankdateien nicht sofort und führen Sie keine Bereinigungsaufgaben aus. Erfassen Sie zunächst das Volume, die freien Bytes, die Dateinamen der Datenbank, den Containerstatus und das letzte bekannte fehlerfreie Backup.

Verhindern Sie, dass der Fehler zu einer Schreibflut wird

Stoppen Sie Jellyfin sowie alle Importeure, Scanner oder Sidecar-Dienste, die auf dasselbe Volume schreiben. Prüfen Sie, welches Mount einschließlich der Inodes voll ist, und bewahren Sie die Hauptdatenbank sowie alle zugehörigen `-wal`- oder `-shm`-Dateien auf. Ein voller Datenträger kann Konfigurationsdateien leer oder nur teilweise geschrieben hinterlassen; ein versionsbezogener Vorfall zeigt, dass das Freigeben von Speicherplatz allein den Start möglicherweise nicht wiederherstellt (Fall zur Wiederherstellung nach einem vollen Volume).

Geben Sie Speicherplatz durch entbehrliche Protokolle, abgeschlossene Transcodierungsdateien oder bekanntermaßen wiederherstellbaren Cache erst frei, nachdem Sie den persistenten Zustand kopiert haben. Entfernen Sie die Datenbank niemals als ersten Schritt.

Erfassen Sie vor der Bereinigung die Größe der Datenbank, die WAL-Dateien, Protokolle, den Cache und den verbleibenden freien Speicherplatz. So lässt sich feststellen, ob das Volume durch das Wachstum der Datenbank, die Transcodierungsausgabe, Protokolle oder einen anderen Container vollgelaufen ist.

Überprüfen Sie die Datenbankintegrität, bevor Sie eine Reparatur versuchen

Arbeiten Sie auf einer Kopie der Datenbank, während Jellyfin weiterhin gestoppt ist. Führen Sie mit den in Ihrer Umgebung verfügbaren SQLite-Tools eine Integritätsprüfung durch und untersuchen Sie die Protokolle auf Fehler wie „disk full“, ein fehlerhaftes Image oder „unable to open“. Wenn die Prüfung erfolgreich ist, stellen Sie freien Speicherplatz wieder her, starten Sie einmal neu und überprüfen Sie Benutzer, Bibliotheken und die Wiedergabe.

Wenn die Datenbank fehlerhaft ist, stellen Sie zuerst das letzte bekannte fehlerfreie Backup wieder her. Ein kontrollierter Wiederherstellungsprozess kann SQLite-Reparaturtools auf einer Kopie verwenden, ersetzt jedoch kein überprüftes Backup und sollte nicht gegen eine aktive Datenbank ausgeführt werden (Wiederherstellungsverfahren auf einer Kopie).

Nachdem Sie ausschließlich wiederherstellbare Daten entfernt haben, bestätigen Sie, dass die Datenbankdateien zusammen verbleiben und lesbar sind. Ein Neustart vor dieser Prüfung kann aus einem unvollständigen Schreibvorgang einen zweiten Fehler machen.

Verhindern Sie, dass das Volume erneut diesen Grenzwert erreicht

Verschieben Sie Cache- und Transcodierungsausgaben auf einen überwachten Pfad, richten Sie Warnmeldungen oberhalb des Mindestgrenzwerts für freien Speicherplatz ein und überprüfen Sie die Aufbewahrungsdauer von Protokollen sowie die Scanzeitpläne. Halten Sie den Anwendungszustand getrennt von umfangreichen Mediendaten, damit eine wachsende Bibliothek das Datenbankvolume nicht aufbrauchen kann.

Starten Sie zweimal neu, führen Sie den ursprünglichen Scan oder die Wiedergabe aus und bestätigen Sie, dass das nächste Backup abgeschlossen wird. Leiten Sie den Fall weiter, wenn Integritätsprüfungen fehlschlagen, die Datenbank nicht wiederhergestellt werden kann oder sich das Volume erneut füllt, ohne dass ein sichtbarer Schreibprozess vorhanden ist.

Wenn die Integritätsprüfung erfolgreich ist, starten Sie einmal neu und führen Sie die ursprüngliche Benutzer- und Bibliotheksauslastung aus. Wenn sie fehlschlägt, arbeiten Sie mit einer Kopie oder stellen Sie ein Backup wieder her, anstatt die beschädigte Datenbank wiederholt zu öffnen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Beweisen Sie die Wiederherstellung und verhindern Sie ein weiteres volles Volume

Führen Sie nach der Reparatur einen Kaltstart, einen Scan, eine Wiedergabesitzung und ein Backup durch. Bestätigen Sie, dass das Datenbankvolume während der aktiven Auslastung über einen überwachten Puffer an freiem Speicherplatz verfügt.

Behalten Sie die Reparatur bei, wenn Benutzer, Bibliotheken, geplante Aufgaben und die Wiedergabe vollständig zurückkehren. Richten Sie Warnmeldungen für Speicherplatz und Inodes ein und verschieben Sie Cache oder Protokolle auf eine Rolle, die das Datenbankvolume nicht aufbrauchen kann.

Leiten Sie den Fall weiter, wenn sich das Volume erneut füllt, ohne dass ein sichtbarer Schreibprozess vorhanden ist, Integritätsprüfungen fehlschlagen oder die wiederhergestellte Datenbank Benutzer oder Zustand verliert.