So verschieben Sie Immich-Daten, ohne Benutzer, Verlauf oder Einstellungen zu verlieren

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 Move Immich Data Without Losing Users, History, or Settings - Zima Store Online

Verschiebe Immich als Migration des Anwendungszustands und nicht als bloßes Kopieren eines Ordners: Bewahre die Datenbank, den Medienbaum, die Konfiguration, die Geheimnisse und die Pfade, die diese Komponenten miteinander verknüpfen.

Eine Migration kann erfolgreich aussehen, weil jedes JPEG auf der neuen Festplatte vorhanden ist, während Konten, Alben, Personen, Freigaben, Favoriten oder historische Beziehungen fehlen. Erstelle zuerst einen Wiederherstellungspunkt, erfasse einen konsistenten Ausgangszustand, kopiere ihn ohne Änderung der Kennungen, stelle ihn auf einem isolierten Ziel wieder her und führe die Umstellung erst durch, wenn die Abläufe im Haushalt übereinstimmen.

Den gemeinsam zu verschiebenden Zustand erfassen

Liste die PostgreSQL-Datenbank, hochgeladene Medien, zu bewahrende generierte Daten, Definitionen externer Bibliotheken, Compose- oder App-Konfiguration, Umgebungswerte, Geheimnisse, Netzwerknamen und die aktuellen Speichereinbindungen auf. Markiere, welches Element maßgeblich ist und welches nach einer Wiederherstellung neu erzeugt werden kann.

Eine Migrationsdiskussion aus dem Jahr 2026 über das Bewahren von Immich-Benutzern bei einem Umzug bestätigt den zentralen Punkt: Der Benutzer- und Bibliothekszustand ist an die Datenbank und die eingebundenen Pfade gebunden, nicht an das Container-Image. Behandle Community-Befehle als Beispiele und passe sie an die exakt eingesetzte Version an.

Lege vor dem Umzug eine kleine Prüfmenge fest: zwei Benutzer, mehrere Alben, Favoriten, freigegebene Elemente, eine Person oder ein Suchergebnis, alte und neue Assets sowie einen Pfad einer externen Bibliothek, falls verwendet. Diese bekannten Datensätze machen die Validierung nach der Migration deutlich aussagekräftiger als ein bloßer Vergleich der Gesamtdateigröße.

Vor dem Kopieren einen konsistenten Wiederherstellungspunkt erstellen

Halte neue Uploads an oder plane ein Wartungsfenster, damit sich die Quelle während der Erfassung des Migrationszustands nicht mehr verändert. Erstelle eine datenbanknative Sicherung und sichere die Quellmedien sowie die Konfiguration. Lasse die ursprüngliche Instanz nach der Erfassung unangetastet, bis das Ziel die Überprüfung bestanden hat.

Der ZimaSpace-Leitfaden zur gemeinsamen Wiederherstellung von Komponenten einer Fotobibliothek erklärt, warum Originale, Katalogzustand und pfaddefinierende Konfiguration einen kompatiblen Wiederherstellungspunkt darstellen müssen. Genau diese Grenze gilt auch für eine Migration.

Verwende das Verzeichnis der aktiven Produktionsdatenbank nicht als gewöhnliches Ziel für Dateikopien, während es sich verändert. Wenn die Ausfallzeit kurz sein muss, nutze einen datenbankbewussten Dump und eine Speichermethode, deren Erfassungsreihenfolge du verstehst. Eine Migration ist nur so wiederherstellbar wie der Punkt, den du zurückspielen kannst, nicht so gut wie die Anzahl der kopierten Dateien.

Medien mit unveränderten Pfaden und Berechtigungen kopieren

Kopiere den Medienbaum zum Ziel, ohne Ordner während der Migration neu zu organisieren. Bewahre Eigentümer, Berechtigungen, Zeitstempel und alle Dateisystemfunktionen, auf die deine Bereitstellung angewiesen ist. Wenn der im Container sichtbare Pfad unverändert bleiben soll, ändere die Bind-Quelle auf dem Host und behalte die Zuordnung im Container bei.

Der aktuelle Rsync-Migrationsablauf hebt den Archivmodus, Probeläufe, fortsetzbare Übertragungen und die Gefahr destruktiver Spiegelungsoptionen hervor. Führe vor jedem Löschen einen Vergleich im Probelauf durch und überprüfe das Ziel, statt anzunehmen, dass ein abgeschlossener Befehl einer vollständigen Anwendungsmigration entspricht.

Vergleiche Dateianzahlen und Größen und überprüfe anschließend eine repräsentative Stichprobe von Prüfsummen für alte Fotos, neue Fotos, Videos und große Dateien. Wenn aufgrund von Änderungen an der Quelle Kopierfehler oder Meldungen über „verschwundene Dateien“ auftreten, stoppe die Annahme neuer Uploads und wiederhole den Differenzabgleich, statt die Quelle zu löschen, um ein scheinbar sauberes Ziel zu erzwingen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Datenbank und Konfiguration auf einem isolierten Ziel wiederherstellen

Starte das Ziel unter einem temporären Hostnamen oder in einem isolierten Netzwerk, damit mobile Clients während der Validierung keine Uploads dorthin senden können. Binde die kopierten Medien an den erwarteten Containerpfaden ein, stelle die passende Datenbank wieder her und reproduziere die für diese Version erforderlichen Umgebungsvariablen, Geheimnisse, Netzwerke und Proxy-Einstellungen.

Ein separater Bericht aus dem Jahr 2026 über eine schrittweise Servermigration zeigt, warum Betreiber den neuen Host testen, bevor sie den alten außer Betrieb nehmen. Nutze solche Berichte als Anregungen für mögliche Fehler, aber lasse deine bekannten Datensätze darüber entscheiden, ob der Zustand tatsächlich erhalten wurde.

Halte an, wenn das Ziel als frische Installation startet, fehlenden Speicher meldet oder eine destruktive Initialisierung vorschlägt. Diese Symptome bedeuten meist, dass die Datenbank oder die Einbindungen nicht den erwarteten entsprechen. Korrigiere zuerst den Pfad oder das Wiederherstellungsziel. Lade keine neuen Dateien in eine leer wirkende Instanz hoch und erzeuge dadurch nicht zwei konkurrierende Verläufe.

Erst umstellen, wenn Benutzer, Verlauf und neue Schreibvorgänge geprüft sind

Melde dich als jeder Referenzbenutzer an und überprüfe die Albumzugehörigkeit, Favoriten, Freigaben, den Such- oder Personenstatus, repräsentative Originale, Zeitstempel und die erwarteten Bibliothekszahlen. Lade anschließend ein neues Testfoto hoch und bestätige, dass es angezeigt und verarbeitet wird und einen Neustart des Containers übersteht.

Ändere das Produktionsziel von DNS oder Proxy erst, nachdem der isolierte Test bestanden wurde. Halte die alte Instanz angehalten, aber wiederherstellbar, damit nicht beide Systeme gleichzeitig Schreibvorgänge akzeptieren können. Bewahre die Datenbanksicherung und die Quellmedien aus der Zeit vor der Migration auf, bis der neue Host reguläre Sicherungen erstellt und mindestens einen Wiederherstellungstest abgeschlossen hat.

Führe ein Rollback durch, wenn sich Anzahlen unterscheiden, bekannte Beziehungen verschwinden, neue Uploads auf die falsche Festplatte geschrieben werden oder das Ziel nach einem Neustart ausfällt. Gib bei einer Eskalation die Quell- und Zielversionen, den Zeitstempel der Datenbanksicherung, die Einbindungszuordnungen, Kopierprotokolle, Berechtigungsunterschiede und das erste fehlgeschlagene Prüfelement an.