So reparieren Sie Immich, 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 Immich After Its Database Volume Fills Up - Zima Store Online

Wenn sich das Immich-Datenbankvolume füllt, stoppen Sie neue Immich-Schreibvorgänge, bewahren Sie das PostgreSQL-Datenverzeichnis auf und schaffen Sie sicheren Arbeitsbereich, bevor Sie eine Wiederherstellung versuchen. Löschen Sie keine Dateien aus pg_wal oder anderen PostgreSQL-internen Verzeichnissen, nur weil sie groß sind.

Ein vollständig belegtes Datenbankdateisystem kann Checkpoints oder die Crash-Wiederherstellung unterbrechen. Daher können wiederholte Neustarts weiterhin fehlschlagen, selbst wenn die Fotoanwendung selbst einen gesunden Eindruck macht. Stellen Sie zunächst fest, welches Dateisystem voll ist – PostgreSQL-Daten, Docker-Root-Speicher, Shared Memory oder ein anderer Mount – und stellen Sie diese Ebene wieder her, ohne Beweise zu zerstören, die Sie möglicherweise für ein Rollback benötigen.

Bestätigen, welches Dateisystem voll ist, und weitere Schreibvorgänge stoppen

Prüfen Sie die Verfügbarkeit von Speicherplatz und Inodes für den PostgreSQL-Mount, das Docker-Datenverzeichnis, das Root-Dateisystem des Hosts sowie jeden im Fehler genannten tmpfs-/Shared-Memory-Pfad. Gleichen Sie den Zeitpunkt mit den PostgreSQL-Logs ab. Eine Meldung „no space left on device“ aus pg_wal bedeutet etwas anderes als ein voller Image-Cache oder eine volle Thumbnail-Partition.

Eine Diskussion zur Datenbankwiederherstellung von Immich zeigt, dass PostgreSQL die Wiederherstellung abbricht, weil nach dem Auffüllen des Speichers keine temporäre WAL-Datei geschrieben werden konnte. Der Fall ist alt und deploymentspezifisch, zeigt aber, warum das Ändern von Dateiberechtigungen oder ein Neustart des Stacks keinen Kapazitätsfehler behebt.

Pausieren Sie Uploads und Hintergrundaufgaben und stoppen Sie anschließend die Anwendungskomponenten, die neue Datenbankoperationen erzeugen. Bewahren Sie den ersten fehlerhaften Logabschnitt und die Mount-Übersicht auf. Wenn das volle Dateisystem tatsächlich nicht das PostgreSQL-Datenverzeichnis ist, beheben Sie den tatsächlichen Engpass, statt die Datenbank unnötig zu verschieben.

PostgreSQL-Zustand bewahren, bevor Sie Speicherplatz schaffen

Erstellen Sie bei gestopptem PostgreSQL, sofern Speicherplatz und Werkzeuge dies erlauben, einen Dateisystem-Snapshot oder eine vollständige Kopie des Datenverzeichnisses. Beziehen Sie das WAL-Verzeichnis und alle nicht standardmäßigen Tablespaces als einen gemeinsamen Zustand ein. Diese Sicherheitskopie ermöglicht es Ihnen, zum Ausgangspunkt des Vorfalls zurückzukehren, falls der nächste Wiederherstellungsversuch die Situation verschlimmert.

Die Anleitung zur Wiederherstellung bei vollem PostgreSQL-Speicher formuliert die entscheidende Regel ausdrücklich: WAL ist Teil der Datenbankkonsistenz und kein gewöhnlicher Protokollmüll. Das manuelle Löschen kann die Datenbank beschädigen. Schaffen Sie stattdessen Kapazität, indem Sie das Volume erweitern oder verschieben beziehungsweise andere sichere, nicht zusammengehörige Daten entfernen. Überschreiben Sie die fehlerhafte Datenbank nicht sofort mit dem letzten Backup, es sei denn, Sie haben entschieden, dass der aktuelle Zustand nicht wiederherstellbar ist, und akzeptieren den Verlust der Änderungen seit diesem Backup. Wenn Sie die volle Instanz bewahren, verfügen Sie sowohl über einen Rollback-Punkt als auch über Belege dafür, warum der Speicherplatz verschwunden ist.

PostgreSQL zuerst wiederherstellen und anschließend entscheiden, ob Immich repariert werden muss

Sobald ausreichend Speicherplatz vorhanden ist, starten Sie PostgreSQL allein oder mit dem minimal erforderlichen Stack und beobachten Sie die Wiederherstellungslogs. Ein sauberer Start, eine erfolgreiche Zustandsprüfung und normaler Lesezugriff sind aussagekräftigere Signale als ein Containerstatus „running“. Erstellen Sie so bald wie möglich ein frisches datenbankeigenes Backup, sobald die Datenbank stabil genug dafür ist.

Der ZimaSpace-Leitfaden zu Wartung oder Austausch einer Immich-Datenbank beschreibt die nächste Abgrenzung: Gewöhnliche Größen- oder Leistungsprobleme sollten keinen Neuaufbau auslösen, während wiederholbare Integritäts- oder Wiederherstellungsfehler die Wiederherstellung einer verifizierten Datenbankkopie rechtfertigen können.

Starten Sie Immich erst, wenn PostgreSQL dauerhaft gesund bleibt.

Prüfen Sie Benutzer, Zeitleiste, mehrere Originale, Alben, die Suche und einen kontrollierten neuen Upload. Wenn die Datenbank startet, aber Anwendungsabfragen wiederholt fehlschlagen, bewahren Sie die neuen Logs auf und ermitteln Sie, ob nun die Kompatibilität von Schema und Version oder die Datenintegrität – nicht der freie Speicherplatz – das eigentliche Problem ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Wachstumsursache beheben und nachweisen, dass sich das System wieder sicher füllen lässt

Messen Sie, welcher Bereich gewachsen ist: normale Datenbanktabellen, WAL-Aufbewahrung, auf demselben Volume gespeicherte Backups, Logs, Docker-Layer oder ein unerwarteter Pfad. Wenn der Vorfall durch einen fehlgeschlagenen Archivierungs-/Replikationsprozess oder einen anderen Dienst verursacht wurde, der in das Datenbankvolume geschrieben hat, beheben Sie diese Ursache, statt lediglich die Kapazität zu erhöhen.

Richten Sie Warnmeldungen ein, lange bevor das Volume den Punkt erreicht, an dem PostgreSQL keine Checkpoints oder Wiederherstellung mehr durchführen kann. Überwachen Sie sowohl den Prozentsatz als auch den absoluten freien Speicherplatz, denn ein großes Volume kann nur noch wenige Prozent frei haben und dennoch ausreichend Arbeitsbereich bieten, während ein kleines Datenbankvolume schnell kritisch werden kann. Bewahren Sie Datenbank-Backups außerhalb derselben Ausfallgrenze auf, die sie schützen sollen.

Wiederholen Sie abschließend einen normalen Upload- und Hintergrundverarbeitungszyklus, erstellen Sie ein frisches Datenbank-Backup, starten Sie den Stack neu und führen Sie einen Neustart des Hosts durch. Der Test ist bestanden, wenn der freie Speicherplatz stabil abnimmt, keine WAL-/Wiederherstellungsfehler auftreten, alte und neue Assets lesbar sind und ein dokumentierter Schwellenwert vorhanden ist, der Maßnahmen auslöst, bevor Schreibvorgänge erneut fehlschlagen.