Så förhindrar du duplicerade jobb eller importer i Immich

Förhindra dubbla Immich-jobb eller importer genom att först skilja på två olika symtom: samma bakgrundsarbete verkar köras igen, och samma foto blir mer än en tillgång. Ta sedan reda på vilken klient, importör, biblioteksskanning, sökvägsändring eller omkörning som skapade den andra händelsen innan du raderar något.

Den säkraste utformningen ger varje tillgångsgrupp en kanonisk importväg. Ett historiskt molnarkiv, ett externt bibliotek och en aktiv telefonbackup kan alla vara giltiga, men överlappande ägarskap av samma filer kan skapa dubbla poster eller loopar med upprepade uppladdningar som ingen efterföljande rensning på ett tillförlitligt sätt kan åtgärda.

Ta reda på om du har upprepat arbete eller dubbla tillgångar

För upprepade jobb ska du registrera könamnet, tillgångens ID, starttid, status för slutförande eller misslyckande samt händelsen som föregick det nya jobbet. Ett legitimt efterföljande jobb som skapas efter metadataarbete skiljer sig från att samma misslyckade jobb försöker om och om igen. Rensa inte alla köer förrän du vet vilket mönster som förekommer.

För dubbla tillgångar ska du jämföra källbibliotek, ursprunglig sökväg, kontrollsummebeteende där det är tillgängligt, enhetens backupstatus, fotograferingstid och filstorlek. Samma synliga bild kan finnas som två olika filer efter molnexport, metadataändringar, omkodning eller sökvägsbaserad hantering av externa bibliotek, medan byteidentiska filer också kan finnas i olika Immich-bibliotekskällor.

Om vanliga uppladdningar börjar ge upprepade fel med kontrollsummor eller unika begränsningar ska du bevara databasen och granska migrerings- och schemastatus innan du behandlar symtomet som ett problem med importkällan. Dubbla tillgångar från två legitima källtyper och ett databasfel med en begränsning är olika grenar och bör inte få samma rensning.

ZimaSpace-guiden om backupstatus och mobil schemaläggning är användbar eftersom en mobilklient har sin egen uppfattning om vad som fortfarande behöver säkerhetskopieras. Serverbaserad rensning som ignorerar klientens status kan göra att telefonen skickar filerna igen vid nästa session.

Använd en kanonisk importväg för varje befintlig fotogrupp

Bestäm hur gamla foton ska komma in i Immich innan du aktiverar kontinuerlig telefonbackup: importera till exempel det historiska arkivet en gång, verifiera det och låt sedan telefonen endast bidra med nya bilder. Om samma historiska filer både monteras som ett externt bibliotek och laddas upp via det vanliga uppladdningsbiblioteket ska du inte anta att global deduplicering kan förena de två källorna.

En rapport om dubblering mellan källor i Immich dokumenterar att identiskt innehåll kan samexistera när det kommer från ett externt bibliotek och uppladdningsbiblioteket. Betrakta detta som en gräns för projektets beteende: källans ägarskap spelar roll, så förebyggande åtgärder är mer tillförlitliga än att förvänta sig att ett senare dubblettverktyg ska härleda vilken kopia du föredrar.

Undvik att flytta filer som Immich har laddat upp internt till ett externt bibliotek bakom dess rygg medan telefonen fortfarande betraktar dem som en del av sin backupuppsättning. Om lagringsarkitekturen måste ändras ska du migrera via en dokumenterad väg med säkerhetskopior och en liten testgrupp och sedan bekräfta att mobilappen och servern är överens innan du raderar den gamla kopian.

Kontrollera omkörningar och klientstatus innan du skalar upp importen

Använd ett mellanlagringsmanifest för en stor manuell import: registrera källsökväg, filantal, totalt antal byte och en stabil kontrollsumma eller ett importresultat där det är praktiskt möjligt. Om en import avbryts ska du återuppta den med samma verktyg och mål i stället för att starta en andra oberoende importör mot samma källa medan den första jobbstatusen är osäker.

En färsk rapport om upprepade uppladdningar i Immich visade en mobilklient som ständigt försökte ladda upp tillgångar som servern redan hade, med fel från unika begränsningar på servern. Betrakta detta som versionsspecifika belägg för att klientens backupstatus kan vara den som äger loopen; generalisera det inte till ett universellt beteende hos mobilappen. Sökvägsändringar är fortfarande en separat risk. Håll sökvägarna till externa bibliotek, så som de syns i containern, stabila under en stor import och migrera en liten grupp först om en lagringsflytt är nödvändig. Om den andra kopian dyker upp först efter en sökvägsändring ska du följa grenen för sökvägsidentitet i stället för att återställa telefonens backupstatus.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testa avbrott, omkörning och en verkligen ny tillgång

Skapa en liten representativ grupp som innehåller vanliga foton, videor, en redigerad bild och minst en fil som redan finns på målsökvägen. Importera den en gång, registrera antal tillgångar och ID:n och avbryt sedan ett andra kontrollerat försök eller en ny skanning enligt det arbetsflöde du planerar att använda i produktion.

Ett godkänt test innebär att ingen oförklarad andra tillgång skapas för samma avsedda källobjekt, att omkörningar avslutas utan en kö som växer permanent och att ett verkligt nytt foto fortfarande importeras korrekt. Öppna också mobilklienten igen efter testet så att dess backupstatus inte i tysthet hamnar i konflikt med servern.

Om dubbletter endast återkommer mellan uppladdnings- och externa bibliotekskällor ska du göra om ägargränsen i stället för att upprepade gånger slå ihop dem. Om samma tillgångs-ID får ett oändligt antal misslyckade jobb ska du isolera det jobbet och filen. Eskalera med källtyp, sökvägar, hashvärden där de är relevanta, versioner, klientens backupstatus och den minsta reproducerbara gruppen.