So verhindern Sie, dass Immich-Backups einen inkonsistenten Zustand erfassen

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 Prevent Immich Backups From Capturing Inconsistent State - Zima Store Online

Verhindern Sie inkonsistente Immich-Backups, indem Sie Datenbank und Medien als eine gemeinsame Wiederherstellungseinheit behandeln, deren Erfassungsreihenfolge und Schreibvorgänge gezielt gesteuert werden.

Ein Backup kann jede angeforderte Datei enthalten und sich dennoch schlecht wiederherstellen lassen, wenn die Datenbank auf nicht erfasste Assets verweist oder die Medienkopie einen anderen Zeitpunkt als der Katalog abbildet. Definieren Sie zuerst die Konsistenzgrenze, wählen Sie eine angehaltene oder koordinierte Live-Methode und überprüfen Sie das Ergebnis isoliert.

Definieren Sie die Wiederherstellungseinheit vor der Backup-Planung

Führen Sie die PostgreSQL-Datenbank, hochgeladene Medien, Profildaten, Bereitstellungskonfiguration, Umgebungswerte, Geheimnisse und alle benutzerdefinierten Speicherpfade auf, die für die Wiederherstellung des Dienstes erforderlich sind. Kennzeichnen Sie generierte Vorschaubilder, kodierte Videos und Modelldateien abhängig davon separat, ob Ihre Wiederherstellungsrichtlinie sie schützt oder neu erzeugt.

Der ZimaSpace-Vergleich von Live- und angehaltenen Immich-Backups erläutert die grundlegende Konsistenzentscheidung. Dieser Präventions-Workflow geht einen Schritt weiter: Unabhängig von der gewählten Methode muss ein dokumentierter Zeitpunkt entstehen, der wiederhergestellt werden kann, ohne raten zu müssen, welche Datenbank zu welcher Medienkopie gehört.

Schreiben Sie die Wiederherstellungsreihenfolge neben den Backup-Umfang. Wenn der Plan „Fotos wiederherstellen“ sagt, aber nicht angibt, welcher Datenbank-Dump, welche Konfiguration, Zugangsdaten und Speicherzuordnungen diese Fotos wieder mit Benutzern und Alben verknüpfen, ist die Backup-Definition bereits vor dem ersten geplanten Lauf unvollständig.

Verwenden Sie eine angehaltene Erfassung, wenn die einfachste Abgrenzung ausreicht

Für einen kleinen Haushalt, der ein kurzes Wartungsfenster tolerieren kann, pausieren Sie Uploads und stoppen Sie die Anwendungsdienste, die den Bibliotheksstatus schreiben. Erstellen Sie das Datenbank-Backup, erfassen Sie Medien und Konfiguration und starten Sie die Dienste erst wieder, nachdem der Snapshot oder die Kopie einen eindeutigen Zeitstempel und ein Abschlussresultat aufweist.

Eine angehaltene Anwendung macht einen fehlerhaften Pfad nicht automatisch korrekt. Überprüfen Sie, ob der Datenbankexport erfolgreich war, die vorgesehenen Medienverzeichnisse enthalten sind und das Backup-Ziel unabhängig von den Live-Daten ist, die es wiederherstellen soll. Notieren Sie Start- und Endzeit, damit spätere Wiederherstellungen die genaue Generation erkennen können.

Die Methode ist erfolgreich, wenn während der Erfassung keine Anwendungsschreibvorgänge stattfinden und eine Testwiederherstellung die erwarteten Benutzer, Asset-Anzahlen, Alben und stichprobenartig geprüften Originale liefert. Wenn die Ausfallzeit regelmäßig die Toleranz des Haushalts überschreitet, wechseln Sie zu einer koordinierten Live-Methode, statt Uploads stillschweigend während einer Dateikopie wieder zuzulassen.

Erfassen Sie bei Live-Backups Datenbank und Dateien in einer bekannten Reihenfolge

Wenn Immich verfügbar bleiben muss, erstellen Sie einen konsistenten, datenbanknativen Dump, anstatt das aktive PostgreSQL-Datenverzeichnis als gewöhnliche Dateien zu kopieren. Erfassen oder snapshotten Sie anschließend den Medienbaum in der dokumentierten Reihenfolge und verfolgen Sie Uploads, die während des Backup-Fensters eintreffen.

Der praxisorientierte Immich-Datenbank-Backup-Workflow zeigt den datenbankbewussten Ansatz. Befehle und Containernamen können je nach Bereitstellung variieren. Das übertragbare Prinzip besteht darin, PostgreSQL um ein konsistentes Backup zu bitten, statt einer laufenden rekursiven Kopie von Datenbankdateien zu vertrauen.

Bevorzugen Sie eine Reihenfolge, bei der die wiederhergestellte Datenbank nicht auf Medien verweisen kann, die nie in das Backup gelangt sind. Wenn die Dateisystemkopie zusätzliche Dateien enthält, die der Datenbank noch nicht bekannt sind, lassen sich diese sicherer abgleichen als Datenbankeinträge, deren referenzierte Originale fehlen. Dokumentieren Sie alle Uploads, die die Grenze überschreiten.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Koordinieren Sie Dateisystem-Snapshots mit Datenbank-Hooks, statt Atomizität vorauszusetzen

Dateisystem-Snapshots sind wertvoll, weil sie ein Volume schnell erfassen. Von sich aus machen sie jedoch zwei unabhängig voneinander veränderliche Systeme nicht transaktional konsistent. Wenn Datenbank und Medien auf unterschiedlichen Datasets oder Geräten liegen, definieren Sie Hooks vor und nach dem Snapshot und machen Sie deren Zeitpunkte im Backup-Protokoll sichtbar.

Ein Beispiel aus dem Jahr 2026, das Backup-Software mit Btrfs-Snapshot-Hooks kombiniert, zeigt, warum die Snapshot-Orchestrierung explizite Anwendungs- oder Datenbankgrenzen benötigt. Nutzen Sie die Idee zur Koordination der Erfassungen, aber übernehmen Sie die Dateisystembefehle nicht blind für ein anderes Layout.

Wenn das Snapshot-Tool die zeitliche Grenze von Datenbank und Medien nicht koordinieren kann, greifen Sie auf einen logischen Datenbank-Dump plus Medien-Backup zurück, statt eine atomare Wiederherstellung zu behaupten. Die zusätzliche Komplexität ist nur gerechtfertigt, wenn der Wiederherstellungstest bestätigt, dass die schnellere Erfassung weiterhin einen kohärenten Anwendungsstatus liefert.

Machen Sie Wiederherstellungstests zu einem Bestandteil des Backup-Zeitplans

Ein erfolgreich abgeschlossener Backup-Job belegt lediglich, dass die Erfassung beendet wurde. Wählen Sie regelmäßig eine aktuelle Generation aus, stellen Sie sie unter einem isolierten Hostnamen wieder her, binden Sie den erwarteten Speicher ein und überprüfen Sie Benutzer, repräsentative Originale, Alben, Berechtigungen, die Suchfunktion sowie ein neues Datenbank-Backup der wiederhergestellten Instanz.

Die PostgreSQL-Übersicht zur Wiederherstellung aus der Planung von PostgreSQL-Backup und -Wiederherstellung betont die Validierung der Wiederherstellung und die Wiederherstellungsziele, statt die Erstellung eines Dumps als Abschluss zu betrachten. Wenden Sie dieselbe Disziplin auf die kombinierte Immich-Wiederherstellungseinheit an.

Erklären Sie die Backup-Richtlinie für fehlgeschlagen, wenn die Datenbankwiederherstellung erfolgreich ist, aber Dateien fehlen, wenn sich Medien ohne Benutzer oder Beziehungen öffnen lassen oder wenn die Wiederherstellung von einem Geheimnis abhängt, das ausschließlich auf dem ausgefallenen Host gespeichert ist. Korrigieren Sie Umfang, Reihenfolge, Aufbewahrung oder Unabhängigkeit, bevor Sie die Backup-Häufigkeit erhöhen; mehr inkonsistente Kopien ergeben keinen zuverlässigen Wiederherstellungspunkt.