So stellst du eine Immich-Datenbank aus einem bekannten guten Backup wieder her

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 Recover an Immich Database From a Known-Good Backup - Zima Store Online

Eine nachweislich intakte Immich-Datenbanksicherung ist nur dann nützlich, wenn du sie in einen kontrollierten Zustand einspielst und bestätigst, dass die wiederhergestellte Datenbank weiterhin auf die Medien verweist, die dein Server tatsächlich sehen kann.

Behandle die Wiederherstellung als Abfolge von Schritten, nicht als einzelnen Importbefehl. Sichere zuerst die ausgefallene Instanz, ermittle die Immich-Version und den Zeitstempel der Sicherung, stelle ein sauberes kompatibles Datenbankziel bereit, führe die Wiederherstellung durch, ohne dass die Anwendung zuvor in ein leeres Schema schreibt, und überprüfe anschließend Konten, Zeitliniendaten, Medienpfade und einen neuen Schreibvorgang. Wenn ein Schritt unklar ist, halte an, bevor du die letzte wiederherstellbare Kopie ersetzt.

Den ausgefallenen Zustand einfrieren, bevor du etwas wiederherstellst

Stoppe neue Uploads und Hintergrundschreibvorgänge für die betroffene Immich-Instanz, bevor die Wiederherstellungsarbeiten beginnen. Sichere die aktuelle Compose-Datei, Umgebungsvariablen, eingebundenen Pfade, Image-Versionen, aktuellen Logs und – sofern der Speicherplatz es zulässt – den beschädigten Datenbankzustand. Eine ausgefallene Datenbank kann noch Hinweise enthalten, die erklären, was passiert ist; durch Überschreiben gehen diese Hinweise verloren.

Bestimme genau, welcher Sicherung du vertrauen willst. Notiere den Zeitstempel, die Erstellungsmethode, die Dateigröße und ob die Sicherung jemals testweise wiederhergestellt wurde. Ein von der Datenbank erstellter SQL-Dump ist ein anderes Wiederherstellungsobjekt als eine Rohkopie des laufenden PostgreSQL-Datenverzeichnisses. Behandle beide nicht als austauschbar.

Erstelle das Wiederherstellungsziel nach Möglichkeit in einem separaten Verzeichnis oder einem isolierten Stack. Das Ziel dieses Abschnitts ist einfach: Der ursprüngliche ausgefallene Zustand ist erhalten, die ausgewählte Sicherung ist schreibgeschützt, und du weißt, mit welcher Bereitstellungsversion und welchen Speicherpfaden die Wiederherstellung wieder verbunden werden soll.

Prüfen, ob die Sicherung tatsächlich wiederherstellbar ist

Untersuche die Sicherung, bevor du sie einspielst. Ein komprimierter SQL-Dump sollte sich fehlerfrei dekomprimieren lassen und erkennbare PostgreSQL-Dump-Inhalte enthalten, statt ein leeres Archiv zu sein, das durch eine fehlgeschlagene Pipeline erzeugt wurde. Wenn Prüfsummen oder Verifizierungsergebnisse des Repositorys vorhanden sind, vergleiche sie jetzt, statt eine Beschädigung erst während der Wiederherstellung zu entdecken.

Ein PostgreSQL-Dump ist ein sichereres Wiederherstellungsobjekt als eine beiläufig erstellte Kopie eines laufenden Datenbankverzeichnisses, da er mit datenbankbewussten Werkzeugen erstellt und in ein sauberes Ziel eingespielt werden kann. Das Sicherungsmuster mit Datenbank-Dump hält die Datenbank außerdem von der Medienkopie getrennt, sodass du beide Hälften vor der Wiederherstellung leichter überprüfen kannst.

Bestätige außerdem, dass die Medien und die zur Sicherungsperiode gehörende Konfiguration noch vorhanden sind. Durch die alleinige Wiederherstellung der Datenbank lassen sich Benutzer, Alben, Metadaten und Dateiverweise wiederherstellen, während alle Medien unbrauchbar bleiben, wenn die referenzierten Bibliothekspfade fehlen. Fahre nur fort, wenn Dump sowie Medien- und Konfigurationsbestand zu einem bekannten Wiederherstellungspunkt gehören.

Zuerst ein kompatibles, sauberes Datenbankziel starten

Stimme die Wiederherstellungsmethode auf die Version ab, mit der die Sicherung erstellt wurde. Aktuelle Immich-Versionen bieten die Datenbankwiederherstellung über „Administration“ > „Wartung“ sowie über den Onboarding-Ablauf einer Neuinstallation an. Für ältere Sicherungen können versionsspezifische manuelle Anweisungen erforderlich sein; der Wiederherstellungsablauf wurde in Version 2.5.0 geändert.

Bei einem neuen Wiederherstellungsziel darf Immich keine normalen Migrationen gegen ein leeres Schema ausführen, bevor die Datenbank für die Wiederherstellung bereit ist. Wenn deine Bereitstellungsmethode die Anwendung zusammen mit PostgreSQL startet, verwende die versionsgerechten Wiederherstellungsoptionen, damit der Server vor dem Import keinen konkurrierenden Zustand erzeugt.

Wenn die Datenbank nicht selbstständig einen gesunden Zustand erreicht, halte an und löse dieses Problem zuerst. Spiele dieselbe Sicherung nicht wiederholt in ein Ziel ein, das ständig neu startet, keinen Speicherplatz mehr hat oder ein inkompatibles Speicherlayout verwendet. Ein sauberes, stabiles Ziel ist eine Voraussetzung und keine Nebenaufgabe der Fehlersuche.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Den Dump einmal wiederherstellen und beim ersten Fehler anhalten

Spiele den ausgewählten Dump in die vorbereitete Datenbank ein und erfasse die vollständige Ausgabe. Verwende die für das Dump-Format geeigneten Datenbankwerkzeuge und Optionen, damit ein Fehler sichtbar zum Abbruch der Wiederherstellung führt, statt ein teilweise importiertes Schema zu hinterlassen, das weiterhin startet.

Eine brauchbare Migrationsgrundlage benötigt die Medien, den PostgreSQL-Zustand und die Konfiguration, die beides wieder miteinander verbindet. Ein vollständiger Immich-Sicherungssatz umfasst hochgeladene Medien, eine unterstützte Datenbanksicherung und die Bereitstellungskonfiguration. Wiederherstellungstests bestätigen, dass dieser Satz funktioniert. Bewahre diese Bestandteile zusammen auf, damit das Ziel einem einzigen Wiederherstellungspunkt zugeordnet werden kann.

Starte die Immich-Anwendung nach einem erfolgreichen Import und beobachte den ersten Start aufmerksam. Wenn die Oberfläche dich auffordert, einen neuen ersten Administrator anzulegen, statt die vorhandenen Konten zu akzeptieren, halte an: Das deutet stark darauf hin, dass Immich nicht die wiederhergestellte Datenbank verwendet. Beginne nicht damit, Fotos erneut in diesen leeren Zustand hochzuladen.

Datenbankzustand, Medienpfade und einen neuen Schreibvorgang überprüfen

Melde dich mit einem vorhandenen Konto an und prüfe die Zeitleiste anhand älterer und neuerer Zeiträume. Öffne mehrere Originale, überprüfe Alben oder Favoriten, von deren Existenz du weißt, und bestätige, dass die Anwendung die zugrunde liegenden Dateien auflösen kann, statt lediglich Datenbankeinträge anzuzeigen.

Datenbankzustand, Anwendungsdateien, Konfiguration und Uploads müssen zum Zeitpunkt der Wiederherstellung zusammenpassen. Verwende eine konsistente Sicherung des Datenbank-Containers als Abnahmemodell und nicht lediglich die Tatsache, dass PostgreSQL startet.

Lade abschließend ein nicht benötigtes Foto hoch, warte die normale Verarbeitung ab, bestätige, dass es einen Neustart von Immich und einen Neustart des Hosts übersteht, und lösche es anschließend über die Anwendung. Wenn Konten, alte Medien und der neue Schreibvorgang normal funktionieren, erstelle eine neue Sicherung des wiederhergestellten Zustands, bevor du ein Versionsupgrade durchführst. Falls nicht, greife auf die gesicherten Beweise des Ausfalls oder eine ältere, nachweislich intakte Sicherung zurück, statt den Schaden zu vergrößern.