Flytta Immich som en migrering av applikationens tillstånd, inte som en kopiering av en mapp: bevara databasen, medieträdet, konfigurationen, hemligheterna och sökvägarna som binder samman dem.
En migrering kan verka lyckad eftersom varje JPEG finns på den nya disken, medan konton, album, personer, delning, favoriter eller historiska relationer saknas. Skapa först en återställningspunkt, fånga ett konsekvent tillstånd på källan, kopiera det utan att ändra identifierare, återställ på ett isolerat mål och växla över först när hushållets arbetsflöden stämmer överens.
Inventera det tillstånd som måste flyttas tillsammans
Lista PostgreSQL-databasen, uppladdade medier, genererade data som du vill behålla, definitioner av externa bibliotek, Compose- eller appkonfiguration, miljövärden, hemligheter, nätverksnamn och aktuella lagringsmappningar. Markera vilket objekt som är auktoritativt och vilket som kan återskapas efter återställningen.
En diskussion från 2026 om att bevara Immich-användare under en flytt förstärker huvudpoängen: användar- och biblioteksdata är knutna till databasen och monterade sökvägar, inte till containeravbildningen. Betrakta community-kommandon som exempel och anpassa dem till den exakta versionen som är distribuerad.
Skriv ned en liten uppsättning verifieringspunkter före flytten: två användare, flera album, favoriter, delade objekt, en person eller ett sökresultat, äldre och nyare objekt samt en sökväg till ett externt bibliotek om det används. Dessa kända poster gör verifieringen efter migreringen mycket starkare än att bara jämföra den totala filstorleken.
Skapa en konsekvent återställningspunkt före kopieringen
Pausa nya uppladdningar eller schemalägg ett underhållsfönster så att källan slutar ändras medan du fångar migreringstillståndet. Ta en databasinbyggd säkerhetskopia och skydda källans medier och konfiguration. Låt den ursprungliga instansen vara orörd efter insamlingen tills destinationen har klarat verifieringen.
Återställningsguiden för ZimaSpace om att återställa fotobibliotekets komponenter tillsammans förklarar varför original, katalogtillstånd och sökvägsdefinierande konfiguration måste representera en kompatibel återställningspunkt. Det är samma gräns som en migrering behöver.
Använd inte den aktiva produktionsdatabasens katalog som mål för vanlig filkopiering medan den ändras. Om driftstoppet måste vara kort använder du en databasanpassad dump och en lagringsmetod vars insamlingsordning du förstår. En migrering är bara så återställningsbar som den punkt du kan återställa, inte som antalet kopierade filer.
Kopiera medier med sökvägar och behörigheter intakta
Kopiera medieträdet till destinationen utan att omorganisera mappar under migreringen. Bevara ägarskap, behörigheter, tidsstämplar och eventuella filsystemsfunktioner som distributionen är beroende av. Om sökvägen som är synlig i containern ska förbli densamma ändrar du den bindade källan på värden men behåller mappningen i containern oförändrad.
Det aktuella rsync-arbetsflödet för migrering lyfter fram arkivläge, torrkörningar, återupptagbara överföringar och risken med destruktiva speglingsalternativ. Kör en torr jämförelse före all radering och verifiera destinationen i stället för att anta att ett slutfört kommando innebär en komplett applikationsmigrering.
Jämför antal filer och storlekar och verifiera sedan ett representativt urval av kontrollsummor för gamla foton, nya foton, videor och stora filer. Om kopieringsfel eller ”försvunna filer” visas på grund av att källan ändrades ska du sluta ta emot uppladdningar och upprepa den differentiella körningen i stället för att radera källan för att tvinga fram en destination som bara ser ren ut.
Återställ databasen och konfigurationen på ett isolerat mål
Starta destinationen under ett tillfälligt värdnamn eller i ett isolerat nätverk så att mobilklienter inte kan ladda upp till den under verifieringen. Anslut de kopierade medierna till de förväntade sökvägarna i containern, återställ den matchande databasen och återskapa miljön, hemligheterna, nätverken och proxyinställningarna som krävs av den versionen.
En separat redogörelse från 2026 om stegvis servermigrering visar varför administratörer testar den nya värden innan den gamla avvecklas. Använd sådana rapporter för att hitta möjliga fel, men låt dina kända poster avgöra om migreringen faktiskt bevarade tillståndet.
Avbryt om destinationen öppnas som en ny installation, rapporterar saknad lagring eller föreslår destruktiv initiering. Dessa symtom betyder vanligtvis att databasen eller monteringspunkterna inte är de förväntade. Korrigera sökvägen eller återställningsmålet först; ladda inte upp nya filer till en tomt utseende instans och skapa två konkurrerande historiker.
Växla över först när användare, historik och nya skrivningar har godkänts
Logga in som varje referensanvändare och verifiera albumtillhörighet, favoriter, delning, sök- eller persontillstånd, representativa original, tidsstämplar och förväntat antal biblioteksobjekt. Ladda sedan upp ett nytt testfoto och bekräfta att det visas, bearbetas och finns kvar efter en omstart av containern.
Ändra produktions-DNS eller proxymål först när det isolerade testet har godkänts. Behåll den gamla instansen avstängd men återställningsbar så att båda systemen inte kan ta emot skrivningar samtidigt. Bevara databassäkerhetskopian före migreringen och källmedierna tills den nya värden har genomfört normala säkerhetskopieringar och minst ett återställningstest.
Rulla tillbaka om antalen avviker, kända relationer försvinner, nya uppladdningar skrivs till fel disk eller destinationen slutar fungera efter omstart. Eskalera med käll- och målversioner, tidsstämpel för databassäkerhetskopian, monteringskartor, kopieringsloggar, behörighetsskillnader och den första verifieringspunkten som misslyckades.
Support och tips
Mer att läsa

Så optimerar du Immich-databasanslutningar för samtidiga containrar
Höj inte max_connections först. Mät Immich-sessionerna, summera alla containers behov, behåll utrymme för administratörsåtkomst och justera bara den flaskhals som har bevisats.

Så förhindrar du duplicerade jobb eller importer i Immich
Separera upprepade jobb från duplicerade resurser. Använd en enda kanonisk inläsningsväg, kontrollera omförsök och sökvägsändringar och testa sedan återinmatning på en liten grupp.

Så reparerar du Immich när dess databasvolym blir full
Ta aldrig bort PostgreSQL-WAL för att frigöra utrymme. Stoppa skrivningar till Immich, bevara databastillståndet, lägg till säker lagringskapacitet, återställ PostgreSQL och förhindra sedan att...

