Checklista för migrering av Immich-molnexport för sidofiler och dubbletter

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Immich Cloud Export Migration Checklist for Sidecars and Duplicates

Håll den råa molnexporten orörd tills Immich har bevarat de kompletterande filerna, datumen, relationerna och de önskade versionerna som du faktiskt kan verifiera.

En export från Google Foto eller liknande kan innehålla JSON-filer, upprepade albumreferenser, omdöpta dubbletter, redigeringar och filer som överlappar med samma telefons nästa säkerhetskopiering. Skapa först ett manifest, importera en liten testmängd med varje typ av konflikt och platta inte ut mappar eller radera molnkopian medan någon kompletterande fil fortfarande är tvetydig. Migreringen är klar först när originalhashar, tidslinjedatum, album och det första testet av överlappningen med mobilsäkerhetskopian stämmer överens.

Bevara råexporten och skapa ett migreringsmanifest

Packa upp varje arkiv i ett skrivskyddat mellanlagringsträd och behåll de nedladdade arkiven tills migreringen har godkänts. Registrera exportbatch, relativ sökväg, filnamn, storlek i byte, medietyp, fotograferingsuppgifter, sökväg till kompletterande fil och albumkatalog för varje möjlig tillgång. Manifestet är referensen för återställning när två filer har samma namn men olika innehåll.

En migrering som tar hänsyn till kompletterande filer är viktig eftersom en molnexport kan lagra fotograferingstid, beskrivning, plats och albumrelationer utanför mediefilen. Arbetsflödet för en exportmedveten importör visar varför användning av en exportmedveten importör och verifiering av målet innan molnkopian raderas bevarar mer än en blind filkopiering.

Avbryt om arkiv inte kan packas upp, förväntade år saknas, antalet kompletterande filer inte kan förklaras eller mellanlagringsvolymen saknar utrymme för en arbetskopia. Byt inte namn, platta inte ut, deduplicera inte och skriv inte om metadata i den enda exporten, eftersom sådana ändringar förstör bevisen som behövs för att matcha kompletterande filer senare.

Matcha kompletterande filer innan namn eller mappar normaliseras

Gruppera media och JSON enligt exportörens namnregler, inklusive suffix som lagts till för dubbletter, redigeringar och långa filnamn. Jämför för tio representativa objekt inbäddad fotograferingstid med fototid i den kompletterande filen, filsystemets ändringstid, tidszon, beskrivning, plats och albumtillhörighet. Dokumentera vilket fält som ska vara auktoritativt för varje konflikttyp.

Använd en arbetskopia för alla metadatafusioner och bevara den ursprungliga kompletterande filen bredvid den. Ett ZimaSpace-arbetsflöde för att förhindra att kompletterande filer ändrar fotograferingsdatum visar den närliggande grenen för datumbevarande; denna checklista lägger till manifest- och dubblettkontrollerna som krävs före en fullständig Immich-import.

Steget är godkänt först när varje kompletterande testfil är kopplad till exakt en avsedd mediefil eller uttryckligen har klassificerats som omatchad. Om en omdöpt fil kan matcha fler än en kompletterande fil ska du lämna den olöst och granska exportörens sekvens och hashvärden i stället för att enbart välja utifrån filnamnet.

Skilj äkta dubbletter från relaterade versioner

Klassificera konflikter som byteidentiska kopior, kopior med ändrad molnupplösning, redigerade versioner, albumreferenser, Live Photo-par eller faktiskt olika bilder med samma namn. Behåll redigerade och ursprungliga versioner om familjen inte har fastställt en dokumenterad regel; visuell likhet är inte tillräckliga bevis för radering.

Ett löst communityfall om molnhistorik och förnyad telefonsäkerhetskopiering visar hur molnhistorik och förnyad telefonsäkerhetskopiering kan skapa dubbletter med olika hashvärden. Använd detta avgränsade felmönster för att testa överlappningen mellan Takeout-mängden och varje telefons kamerarulle innan automatisk uppladdning aktiveras.

Importera en liten testmängd som innehåller varje dubblettklass. Jämför antal från källa och mål, hashvärden, datum, platser, albumtillhörighet och beteende för parade videor. Återställ testmängden om importören slår ihop önskade versioner eller skapar oförklarliga andra objekt; försök inte kompensera med massradering i efterhand.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Kör hela importen och bevisa den nya källan till sanningen

Frys omskrivning av metadata och mobil säkerhetskopiering medan du importerar batcher som identifierats i manifestet. Spara importloggar och listor över avvisade filer och stäm sedan av antal per klass i stället för att förvänta dig att ett enda råtal ska vara lika med ett annat när albumreferenser och exakta dubbletter avsiktligt slås ihop.

Efter importen ska du kontrollera ett urval av gamla och nya år, redigerade foton, långa videor, Live Photos, objekt från delade album och tillgångar med kompletterande filer. Ladda ner utvalda original och jämför hashvärden med den mellanlagrade kopian; bekräfta tidslinjedatum, sökning, albumtillhörighet och plats i både webb- och mobilklienter.

Aktivera säkerhetskopiering från endast en telefon efter att den importerade historiken har godkänts. Upprepa överlappningstestet, starta om Immich och verifiera att inga andra kopior visas. Behåll råexporten och molnbiblioteket tills två säkerhetskopieringscykler och ett återställningstest har lyckats; eskalera omatchade kompletterande filer eller icke-deterministisk dubbletthantering med manifestet och testloggarna intakta.