Eine sichere Immich-Migrationscheckliste für einen neuen Heimserver

Eine sichere Immich-Migration beginnt damit, nachzuweisen, was erhalten bleiben muss, bevor Sie etwas kopieren: die Fotodateien, die Datenbank und die Bereitstellungseinstellungen, die beides auf dem neuen Host wieder miteinander verbinden.

Auf einem Heimserver entsteht das Migrationsrisiko meist dadurch, dass diese Bestandteile zu unterschiedlichen Zeitpunkten verschoben werden oder das Ziel mit den falschen Pfaden gestartet wird. Behandeln Sie den alten Server als Rollback-Kopie, vermeiden Sie nach Möglichkeit neue Schreibvorgänge, halten Sie die aktuelle Version und die Speichermappings fest und verschieben Sie anschließend einen verifizierten Datensatz auf die neue Maschine. Die folgende Checkliste hält den Vorgang umkehrbar, bis sich die neue Instanz anmelden, die ursprüngliche Bibliothek finden, Aufgaben verarbeiten und einen Neustart überstehen kann, ohne in einen leeren Zustand zurückzufallen.

Quelle einfrieren und den bekannten guten Zustand dokumentieren

Beginnen Sie auf dem funktionierenden Server, nicht auf dem neuen. Halten Sie die Immich-Version, die Compose- oder App-Store-Definition, die Umgebungswerte für Datenbank- und Speicherpfade, den Speicherort der Fotobibliothek, den Datenbankstandort und alle Einbindungen externer Bibliotheken fest. Notieren Sie außerdem die aktuelle Server-URL und das Benutzerkonto, das Sie zur Validierung verwenden werden.

Diese Bestandsaufnahme soll verhindern, dass eine Migration unbemerkt gleichzeitig zu einem Upgrade, einer Neugestaltung der Pfade und einer Netzwerkänderung wird. Halten Sie Anwendungsversion und logisches Speicherlayout möglichst stabil, bis die Wiederherstellung erfolgreich geprüft wurde; Versionsänderungen können vorgenommen werden, nachdem das Ziel bestätigt ist.

Stoppen oder pausieren Sie vor dem Kopieren neue Uploads, sofern Ihr Haushalt das verkraften kann. Falls das nicht praktikabel ist, legen Sie ein Umschaltfenster fest und planen Sie eine abschließende kurze Synchronisierung. Am Ende dieses Schritts sollte eine schriftliche Zuordnung der Quelle vorliegen, aus der hervorgeht, wo die Originale und der Datenbankzustand liegen und welche Konfiguration dieselben Beziehungen wiederherstellt.

Datenbank, Assets und Konfiguration als einen Migrationssatz erfassen

Behandeln Sie Datenbank und Mediendateien als einen gemeinsamen Wiederherstellungssatz statt als zwei unabhängige Backups. Aktuelle Immich-Datenbank-Backups enthalten Metadaten und Dateiverweise, nicht jedoch die Fotos oder Videos selbst. Deshalb muss das Datenbank-Backup zusammen mit den passenden Inhalten von UPLOAD_LOCATION und allen Daten externer Bibliotheken übertragen werden, die Sie separat verwalten.

Ein brauchbarer Migrationssatz benötigt die Assets, den PostgreSQL-Zustand und die Konfiguration, die beides wieder miteinander verbindet. Ein vollständiger Immich-Backup-Satz umfasst hochgeladene Assets, ein unterstütztes Datenbank-Backup und die Bereitstellungskonfiguration. Wiederherstellungstests dienen dabei als Nachweis, dass der Satz funktioniert. Bewahren Sie diese Bestandteile zusammen auf, damit das Ziel einem einzigen Wiederherstellungspunkt zugeordnet werden kann.

Überprüfen Sie den Migrationssatz, bevor Sie das Ziel anfassen. Stellen Sie sicher, dass der Datenbank-Dump nicht leer ist, prüfen Sie stichprobenartig mehrere Originaldateien aus der kopierten Bibliothek und speichern Sie die Compose- und Umgebungsdateien im selben Migrationsordner oder Dokumentationssatz. Wenn eine Komponente nicht überprüft werden kann, halten Sie hier an und erstellen Sie eine neue Kopie, statt auf dem neuen Server Ausgleichslösungen zu improvisieren.

Den neuen Host vorbereiten, ohne konkurrierende Zustände zu erzeugen

Erstellen Sie zuerst die Zielverzeichnisse und Einbindungen und bestätigen Sie anschließend, dass der neue Host die vorgesehenen Datenträger oder Netzwerkfreigaben genau unter den geplanten Pfaden sieht. Eine fehlende NAS-Einbindung kann ein gewöhnliches leeres Verzeichnis zurücklassen, und ein Container kann sich problemlos gegen diesen Ausweichpfad initialisieren.

Installieren Sie die Laufzeitumgebung und stellen Sie die Bereitstellungsdefinition wieder her, lassen Sie jedoch keine leere Immich-Instanz Uploads oder Konfigurationen ansammeln, bevor der alte Zustand wiederhergestellt ist. Halten Sie Zugangsdaten, Datenbanknamen, Speichervariablen und Ziele für Einbindungen externer Bibliotheken an der Quelle ausgerichtet, sofern der Migrationsplan nicht ausdrücklich eine kontrollierte Pfadänderung vorsieht.

Wenn der neue Server andere hostseitige Pfade erfordert, ordnen Sie diese bewusst zu und halten Sie dabei die im Container sichtbaren Pfade und die Erwartungen der Datenbank konsistent. Das Ziel ist erst bereit, wenn seine tatsächlichen Einbindungen auf die kopierten Datenorte zeigen und Sie jede Pfadübersetzung erklären können, bevor die vollständige Anwendung startet.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zustand wiederherstellen und jeden Speicherpfad erneut verbinden

Stellen Sie die Datenbank über den Wiederherstellungsweg wieder her, der für die Immich-Version geeignet ist, mit der das Backup erstellt wurde. Starten Sie die übrigen Dienste erst, wenn die Datenbank bereit ist. Improvisieren Sie keine destruktiven Datenbankbefehle aus einem älteren Leitfaden, wenn eine neuere Installation einen anderen Wiederherstellungsablauf verwendet.

Halten Sie während der Umschaltung die Beziehung zwischen Datenbank und Speicher intakt, bevor der normale Betrieb wieder aufgenommen wird. Eine getestete Immich-Migrationsabfolge folgt demselben Prinzip: Die Anwendung sollte mit dem wiederhergestellten Datenbankzustand und den vorgesehenen Medienpfaden starten, nicht eine neue Bibliothek initialisieren und einen vollständigen Neuaufbau erzwingen.

Prüfen Sie nach dem Start den Speicherzugriff, bevor Sie umfangreiche Hintergrundaufgaben starten. Öffnen Sie mehrere alte Assets aus verschiedenen Zeiträumen, vergewissern Sie sich, dass Vorschaubilder geladen werden, und bestätigen Sie ein Album sowie eine Person oder ein Suchergebnis, die bereits vor der Migration vorhanden waren. Stellen Sie außerdem sicher, dass externe Bibliotheken lesbar sind, falls Sie diese verwenden. Ein neuer Einrichtungsbildschirm oder eine leere Zeitleiste ist ein Stoppsignal: Überprüfen Sie Datenbank- und Einbindungsmappings, bevor Sie einen neuen Zustand schreiben.

Die ursprüngliche Arbeitslast prüfen, bevor der alte Server außer Betrieb geht

Eine erfolgreiche erste Anmeldung ist noch nicht das Ende der Migration. Laden Sie ein entbehrliches Testfoto über den normalen Client hoch, bestätigen Sie, dass es im erwarteten Host-Speicher erscheint, löschen Sie es anschließend über Immich und prüfen Sie, dass die Bibliothek intakt bleibt. Dadurch wird der vollständige Schreibpfad getestet, statt nur nachzuweisen, dass alte Daten gelesen werden können.

Starten Sie den neuen Heimserver neu und wiederholen Sie die für Ihren Haushalt wichtigen Prüfungen: Browser-Anmeldung, Verbindung der mobilen Sicherung, mehrere alte Fotos, Suche, ein repräsentatives Video, Aufgabenwarteschlangen und den Fernzugriff, sofern dieser zum normalen Setup gehört. Die Migration ist erst abgeschlossen, wenn derselbe Zustand einen Neustart des Hosts übersteht und die Speichereinbindungen verfügbar sind, bevor Immich startet.

Lassen Sie den alten Server während eines Rollback-Zeitraums ausgeschaltet und unverändert, anstatt ihn sofort zu löschen. Wenn die neue Instanz in einen unerwarteten leeren Ordner schreibt, die alte Bibliothek nach einem Neustart nicht wiederherstellen kann oder ungeklärte Datenbankfehler anzeigt, stoppen Sie neue Uploads und kehren Sie zur bekannten guten Quelle zurück, während Sie den Migrationssatz vergleichen. Nehmen Sie den alten Host erst außer Betrieb, wenn das Ziel den normalen Betrieb und einen frischen Backup-Test bestanden hat.