Pensionera inte den gamla Immich-servern bara för att den nya instrumentpanelen läses in och foton visas. Pensionera den först när det återställda systemet har bevisat att användare, album, personer, sökning, utvalda original, nya uppladdningar, bakgrundsjobb, omstarter och en färsk säkerhetskopia fungerar, medan den gamla värden fortfarande är tillgänglig som återställningsmål.
Håll den gamla servern avstängd men oförändrad under valideringen, så att två instanser inte tar emot uppladdningar mot divergerande tillstånd. Ge den återställda värden en kontrollerad testadress först, dokumentera en baslinje från det gamla systemet och jämför samma hushållsarbetsflöden i stället för att förlita dig på ett visuellt intryck av att tidslinjen ser komplett ut.
Behåll den gamla servern intakt medan du fastställer en återställningsbaslinje
Före övergången dokumenterar du antal användare och tillgångar, några representativa album, namngivna personer, favoriter, delade objekt, sökvägar till externa bibliotek och flera exempel på original från olika datum och användare. Dokumentera även versionerna av Immich och PostgreSQL på den gamla servern samt de säkerhetskopior som användes vid återställningen. Kontroller av mapp- eller lagringsintegritet är användbara kontrollpunkter, men ersätter inte verifiering på relationsnivå.
ZimaSpaces återställningsmodell för återställning av ett sökbart fotobibliotek behandlar original, katalogens/databasens tillstånd och den konfiguration som definierar sökvägar som en enda återställningsenhet. Det är rätt baslinje, eftersom lösa bildfiler i sig inte kan bevisa att albumtillhörighet, ägarskap, personer och sökrelationer har överlevt.
Radera inte de gamla diskarna, återanvänd inte dess IP-adress permanent och ta inte bort den senaste fungerande säkerhetskopian ännu. Verifieringsmålet ska vara reversibelt: om en kritisk relation saknas behöver du det gamla tillståndet för att avgöra om problemet kom från säkerhetskopian, återställningsmetoden, sökvägsmappningen eller den nya körtidsmiljön.
Verifiera relationer, inte bara att foton visas
Logga in som fler än en förväntad användare och kontrollera att varje konto ser rätt tillgångar och delningar. Öppna kända album, namngivna personer, favoriter, minnen eller andra hushållsspecifika relationer som skulle vara svåra att återskapa från enbart filerna. Jämför ett mindre urval med den dokumenterade baslinjen från den gamla servern.
En migreringsdiskussion om saknade album efter en PostgreSQL-återställning i Immich visar varför detta är viktigt: foton kunde finnas kvar medan albumtillståndet saknades, och en senare ny dump av databasen ändrade resultatet. Betrakta detta som ett exempel på att en lyckad inloggning eller en synlig tidslinje inte är ett fullständigt återställningstest.
Sök efter flera kända tillgångar med hjälp av metadata och eventuella aktiverade visuella funktioner eller personfunktioner. Om originalen finns men relationer eller sökresultat saknas, avgör om det relevanta tillståndet skulle ha återställts eller avsiktligt håller på att återskapas. Pensionera inte den gamla servern medan den skillnaden är olöst.
Testa läs-, skriv-, beroende- och omstartsflödena
Öppna gamla foton och videor direkt från den återställda lagringen och ladda sedan upp en ny testfil som kan raderas från en mobil- eller webbklient. Bekräfta att originalet skrivs till rätt sökväg, visas för rätt användare och att dess bakgrundsjobb fortskrider. Testa externa bibliotek och fjärråtkomst först när den lokala läs- och skrivvägen är stabil.
Återställningstestning ska validera programmet efter att byte har kopierats. En aktuell guide för testning av katastrofåterställning rekommenderar validering på programnivå som omfattar databaser, behörigheter, nätverksanslutningar och tjänster, i stället för att stanna vid ett slutfört säkerhetskopierings- eller återställningsjobb. Starta om Immich-stacken två gånger och starta om den nya värden en gång. Efter varje cykel bekräftar du att samma monteringar, användare, exempelobjekt, databas, proxy eller lokala slutpunkt och jobb beteende återkommer. En tjänst som bara fungerar tills värden startas om har inte klarat migreringen.
Skapa en färsk säkerhetskopia innan återställningsfönstret stängs
Skapa en ny databaskonsistent säkerhetskopia och skydda det medie- och konfigurationsomfång som krävs av återställningsdesignen. Återställ åtminstone ett litet valideringsmål eller inspektera säkerhetskopian med samma process som användes före övergången. En återställd server som inte kan skapa en egen återställningsbar säkerhetskopia bör inte bli den enda produktionskopian.
Kör den nya värden under en definierad observationsperiod som omfattar normala telefonuppladdningar, bläddring, sökning, bakgrundsbehandling, schemalagd säkerhetskopiering och minst en nattlig cykel. Låt den gamla värden vara avstängd så att den inte delar upp tillståndet, men behåll den oförändrad tills det nya systemet har klarat dessa händelser utan oförklarliga skillnader.
Beslutet att gå vidare kräver matchande kritiska relationer, läsbara original, lyckade nya skrivningar, stabila omstarter och en färsk, verifierad säkerhetskopia.
Om användare försvinner, antal skiljer sig väsentligt, sökvägsfel återkommer eller databasen rapporterar konsistensproblem, stänger du av den nya instansen och bevarar båda sidorna innan du undersöker saken. Först därefter bör den gamla servern raderas eller tas i annan användning.
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...

