Wann sollten Sie eine Immich-Installation neu aufsetzen, statt sie zu reparieren?

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.

When Should You Rebuild Rather Than Repair an Immich Installation? - Zima Store Online

Reparieren Sie Immich, wenn der Fehler lokal begrenzt ist und die dauerhaften Daten nachweislich intakt sind; erstellen Sie die Laufzeitumgebung neu, wenn die Konfigurationsabweichungen umfassend sind, aber eine verifizierte Datenbank, Medienbibliothek, Bereitstellungsdefinition und Rollback-Kopie den Dienst sicher wiederherstellen können.

Neuaufbau bedeutet nicht, alles zu löschen. Container und Netzwerke sind entbehrlich, während die Datenbank und die Originaldateien den Bestand der Bibliothek darstellen. Klassifizieren Sie zunächst Integrität, Umfang und Reproduzierbarkeit. Wenn die einzige Datenbank oder die einzige Fotokopie möglicherweise beschädigt ist, bewahren Sie sie auf und halten Sie an – ein sauberer Neustart auf Grundlage dieser Beweise kann einen diagnostizierbaren Vorfall in einen dauerhaften Datenverlust verwandeln.

Reparieren, wenn der Fehler lokal begrenzt und umkehrbar ist

Bevorzugen Sie eine Reparatur, wenn ein einzelner Mount, eine Berechtigung, ein Umgebungswert, eine Abhängigkeit, ein Job oder ein festgelegtes Image den Fehler erklärt und das System vor einer bekannten Änderung normal funktioniert hat. Erfassen Sie die Logs, erstellen Sie ein Backup, ändern Sie nur diese eine Ebene und wiederholen Sie den Auslöser.

Ein erfolgreicher Test stellt die ausgefallene Funktion wieder her, ohne fehlende Assets, Datenbankfehler oder neue Startwarnungen zu erzeugen. Wenn derselbe Fehler nach einer Neuerstellung zurückkehrt, kann die Ursache in der Bereitstellungsdefinition oder im dauerhaften Zustand liegen; wiederholtes Ersetzen von Containern ist dann keine evidenzbasierte Reparatur mehr.

Eine Diskussion über Datenbankbeschädigung zeigt, wie schnell Wiederherstellungsentscheidungen riskant werden, wenn die Datenbank als betroffene Ebene vermutet wird. Nutzen Sie die Lektion zum Bewahren vor der Reparatur, nicht etwa einen unüberprüften destruktiven Befehl.

Die Laufzeitumgebung neu erstellen, wenn die Abweichungen nicht mehr überschaubar sind

Wählen Sie einen sauberen Neuaufbau der Laufzeitumgebung, wenn Image-Versionen, Netzwerke, Umgebungswerte, Mounts und manuelle Containeränderungen nicht mehr reproduzierbar sind, die verifizierten dauerhaften Komponenten jedoch intakt bleiben. Erstellen Sie die neue Umgebung neben der alten Instanz mit festgelegten Versionen und isolierten Ports, statt die alte zu löschen.

Ein Neuaufbau ist auch nach einer Kompromittierung des Hosts oder bei einer nicht unterstützten Installation mit unbekannten Änderungen sinnvoll, da die Wiederherstellung vertrauenswürdiger Bereitstellungseingaben eine neue Prüfgrenze schafft. Wechseln Sie offengelegte Zugangsdaten und prüfen Sie Backups, bevor Sie sie mit dem sauberen Ziel verbinden.

Die ZimaSpace-Übersicht zur Bereitstellung selbst gehosteter Apps bietet einen breiteren Kontext zum Service-Stack; bei Immich müssen die Beziehung zwischen Datenbank und Medien jedoch weiterhin unabhängig geprüft werden.

Keine Neuerstellung über unsicheren dauerhaften Daten

Halten Sie an, wenn Datenbank und Upload-Bibliothek möglicherweise nicht synchron sind, das einzige Backup noch nicht getestet wurde oder unklar ist, welche Kopie maßgeblich ist. Erstellen Sie Snapshots oder Klone aller infrage kommenden Kopien und dokumentieren Sie die Zeitstempel, bevor Sie eine Datenbankwiederherstellung oder Medienabgleich versuchen.

Ein Unraid-Wiederherstellungsthread zeigt die praktischen Schwierigkeiten bei der Wiederherstellung von Immich, wenn Backup-Komponenten und Versionen nicht zusammenpassen. Die Diskussion zur Wiederherstellungsgrenze spricht dafür, isoliert zu testen, statt die produktiven Pfade zu überschreiben.

Wenn die Originaldateien intakt, die Datenbank jedoch nicht wiederherstellbar ist, bewahren Sie beide auf und dokumentieren Sie die Folgen, bevor Sie einen Import in eine neue Bibliothek erwägen. Das ist eine Entscheidung zur Datenrekonstruktion, keine routinemäßige Reparatur, und dabei können Alben, Freigabestatus, Gesichter, Favoriten oder historische Metadaten verloren gehen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Dauerhafte Daten auf einem sauberen Ziel validieren

Stellen Sie kopierte dauerhafte Daten auf dem sauberen Ziel wieder her oder binden Sie sie dort ein. Testen Sie anschließend Benutzer, Zeitachsenanzahl, stichprobenartig ausgewählte Originaldateien, Alben, Suche, Gesichtsdaten, externe Bibliotheken, einen neuen Upload, Jobs und ein frisches Datenbank-Backup. Vergleichen Sie die Ergebnisse mit den bewahrten Belegen der Quelle.

Vergleichen Sie die Asset-Anzahl der Datenbank mit stichprobenartig ausgewählten Dateien aus mehreren Zeiträumen, Benutzern und Medientypen. Bestätigen Sie die Pfade externer Bibliotheken, abgeleitete Jobs und einen neuen Datenbank-Dump, bevor Sie die Produktionsadresse zuweisen. Ein Anmeldebildschirm allein beweist keine Datenintegrität.

Starten Sie Container und Host zweimal neu. Für einen erfolgreichen Test sind stabile Mounts, eine reproduzierbare Konfiguration, keine Migrationsschleife und die ursprüngliche Arbeitslast erforderlich. Wenn das saubere Ziel denselben Datenbank- oder Dateifehler reproduziert, war die Laufzeitabweichung nicht die Ursache, und eine spezialisierte Datenwiederherstellung bleibt der sicherere Weg.

Mit einer Rollback-Grenze umschalten

Übertragen Sie die Produktionsadresse erst, wenn die isolierten Prüfungen erfolgreich sind, und lassen Sie das alte System während eines vereinbarten Beobachtungszeitraums ausgeschaltet, aber wiederherstellbar. Verhindern Sie, dass beide Instanzen gleichzeitig Uploads annehmen oder dieselbe Automatisierung bereitstellen.

Führen Sie nach dem Umschalten den normalen Familien-Workflow für Uploads, Browsen, Suche, Freigaben und Backups aus. Ein erfolgreicher Test bewahrt Anzahl und Originaldateien über den nächsten Neustart hinweg; bei einer Abweichung leiten Sie den Datenverkehr zurück auf das bewahrte Ziel, ohne einen der beiden Datensätze zu überschreiben.

Kehren Sie zur Reparatur oder spezialisierten Wiederherstellung zurück, wenn das saubere Ziel dieselben Datenbank- oder Dateifehler reproduziert; die Laufzeit war nicht die Ursache. Machen Sie das Umschalten rückgängig, wenn sich Anzahl oder Originaldateien unterscheiden. Eskalieren Sie mit Versionen, Prüfsummen, Backup-Zeitstempeln, dem ersten Fehler und der genauen Grenze zwischen kopiertem und neu erstelltem Zustand.