So überprüfst du eine Immich-Wiederherstellung, bevor du den alten Server außer Betrieb nimmst

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 Verify an Immich Restore Before Retiring the Old Server - Zima Store Online

Schalten Sie den alten Immich-Server nicht ab, nur weil das neue Dashboard geladen wird und Fotos angezeigt werden. Tun Sie dies erst, nachdem das wiederhergestellte System Benutzer, Alben, Personen, Suche, stichprobenartig geprüfte Originale, neue Uploads, Hintergrundaufgaben, Neustarts und eine frische Sicherung erfolgreich durchlaufen hat, während der alte Host weiterhin als Rückfalloption verfügbar bleibt.

Lassen Sie den alten Server während der Validierung ausgeschaltet, aber unverändert, damit nicht zwei Instanzen Uploads in einen voneinander abweichenden Datenbestand akzeptieren. Geben Sie dem wiederhergestellten Host zunächst eine kontrollierte Testadresse, dokumentieren Sie einen Ausgangszustand des alten Systems und vergleichen Sie dieselben Haushaltsabläufe, statt sich auf den visuellen Eindruck zu verlassen, dass die Zeitleiste vollständig aussieht.

Bewahren Sie den alten Server intakt, während Sie eine Wiederherstellungs-Baseline erstellen

Dokumentieren Sie vor der Umstellung die Anzahl der Benutzer und Assets, einige repräsentative Alben, benannte Personen, Favoriten, geteilte Elemente, Pfade externer Bibliotheken sowie mehrere Beispieloriginale aus verschiedenen Zeiträumen und von verschiedenen Benutzern. Notieren Sie außerdem die Versionen von Immich und PostgreSQL auf dem alten System sowie die für die Wiederherstellung verwendeten Sicherungsartefakte. Integritätsprüfungen von Ordnern oder Speicher sind hilfreiche Prüfkriterien, ersetzen jedoch keine beziehungsbezogene Überprüfung.

Das ZimaSpace-Wiederherstellungsmodell für das Wiederherstellen einer durchsuchbaren Fotobibliothek behandelt Originale, Katalog-/Datenbankstatus und pfaddefinierende Konfiguration als eine gemeinsame Wiederherstellungseinheit. Das ist die richtige Grundlage, denn einzelne Bilddateien können nicht belegen, dass Albumzugehörigkeit, Besitzverhältnisse, Personen und Suchbeziehungen erhalten geblieben sind.

Löschen Sie die alten Laufwerke nicht, verwenden Sie ihre IP-Adresse nicht dauerhaft weiter und löschen Sie die letzte bekanntermaßen funktionierende Sicherung noch nicht. Das Wiederherstellungsziel sollte umkehrbar sein: Wenn eine wichtige Beziehung fehlt, müssen Sie anhand des alten Zustands feststellen können, ob das Problem von der Sicherung, der Wiederherstellungsmethode, der Pfadzuordnung oder der neuen Laufzeitumgebung verursacht wurde.

Überprüfen Sie Beziehungen, nicht nur die Sichtbarkeit von Fotos

Melden Sie sich mit mehreren erwarteten Benutzern an und prüfen Sie, ob jedes Konto die richtigen Assets und Freigaben sieht. Öffnen Sie bekannte Alben, benannte Personen, Favoriten, Erinnerungen oder andere haushaltsspezifische Beziehungen, die sich nicht allein aus den Dateien rekonstruieren ließen. Vergleichen Sie eine kleine Auswahl mit dem dokumentierten Ausgangszustand des alten Servers.

Eine Migrationsdiskussion zu fehlenden Alben nach einer PostgreSQL-Wiederherstellung bei Immich zeigt, warum dies wichtig ist: Fotos konnten erhalten bleiben, während der Albumstatus fehlte, und ein späterer erneuter Datenbankexport führte zu einem anderen Ergebnis. Betrachten Sie dies als Beleg dafür, dass eine erfolgreiche Anmeldung oder eine sichtbare Zeitleiste keinen vollständigen Wiederherstellungstest darstellt.

Suchen Sie anhand von Metadaten sowie allen aktivierten visuellen oder personenbezogenen Funktionen nach mehreren bekannten Assets. Wenn Originale vorhanden sind, aber Beziehungen oder Suchergebnisse fehlen, klären Sie, ob der betreffende Zustand hätte wiederhergestellt werden müssen oder absichtlich neu erzeugt wird. Schalten Sie den alten Server nicht ab, solange diese Unterscheidung ungeklärt ist.

Testen Sie Lese-, Schreib-, Abhängigkeits- und Neustartpfade

Öffnen Sie alte Fotos und Videos direkt vom wiederhergestellten Speicher und laden Sie anschließend ein neues, entbehrliches Asset von einem mobilen oder Web-Client hoch. Bestätigen Sie, dass das Original am vorgesehenen Pfad geschrieben wird, für den richtigen Benutzer erscheint und seine Hintergrundaufgaben fortschreiten. Testen Sie externe Bibliotheken und den Fernzugriff erst, wenn der lokale Lese-/Schreibpfad stabil ist.

Bei einem Wiederherstellungstest sollte die Anwendung nach dem Kopieren der Daten validiert werden. Ein aktueller Leitfaden für Disaster-Recovery-Tests empfiehlt eine Validierung auf Anwendungsebene, die Datenbanken, Berechtigungen, Netzwerkverbindungen und Dienste umfasst, statt bei einem abgeschlossenen Sicherungs- oder Wiederherstellungsauftrag stehen zu bleiben. Starten Sie den Immich-Stack zweimal neu und führen Sie auf dem neuen Host einmal einen Neustart durch. Bestätigen Sie nach jedem Durchlauf, dass dieselben Einbindungen, Benutzer, Beispiel-Assets, Datenbanken, Proxy- oder lokalen Endpunkte und das Verhalten der Aufgaben wieder verfügbar sind. Ein Dienst, der nur bis zum ersten Neustart des Hosts funktioniert, hat die Migration nicht bestanden.

-15% OFF

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

Single board computer zimaboard2

Erstellen Sie eine frische Sicherung, bevor Sie das Rückfallfenster schließen

Erstellen Sie eine neue datenbankkonsistente Sicherung und schützen Sie den für das Wiederherstellungsdesign erforderlichen Umfang von Medien und Konfiguration. Stellen Sie mindestens ein kleines Validierungsziel wieder her oder prüfen Sie die Sicherung mit demselben Verfahren, das vor der Umstellung verwendet wurde. Ein wiederhergestellter Server, der keine eigene wiederherstellbare Sicherung erzeugen kann, sollte nicht die einzige Produktionskopie werden.

Betreiben Sie den neuen Host während eines festgelegten Beobachtungszeitraums, der normale Telefon-Uploads, Browsing, Suche, Hintergrundverarbeitung, geplante Sicherungen und mindestens einen nächtlichen Zyklus umfasst. Lassen Sie den alten Host ausgeschaltet, damit er den Datenbestand nicht aufteilt, bewahren Sie ihn jedoch unverändert auf, bis das neue System diese Ereignisse ohne unerklärliche Abweichungen übersteht.

Die Freigabeentscheidung setzt übereinstimmende kritische Beziehungen, lesbare Originale, erfolgreiche neue Schreibvorgänge, stabile Neustarts und eine frische, verifizierte Sicherung voraus.

Wenn Benutzer verschwinden, die Anzahlen erheblich voneinander abweichen, Pfadfehler erneut auftreten oder die Datenbank Konsistenzprobleme meldet, fahren Sie die neue Instanz herunter und bewahren Sie beide Seiten auf, bevor Sie die Ursache untersuchen. Erst danach sollte der alte Server gelöscht oder einer anderen Verwendung zugeführt werden.