Vilka Immich-data måste bevaras, och varför spelar lagringsrollerna roll?

Immichs tillförlitlighet beror på att auktoritativa original och applikationstillstånd hålls beständiga, samtidigt som återskapningsbara derivat och tillfälligt arbete behandlas som separata lagringsroller.

Att placera varje katalog på en enda volym kan fungera, men det döljer vilka data som måste överleva en ominstallation, vilka data som kan återskapas och vilka data som bör förvaras separat som säkerhetskopia. Den skillnaden påverkar återställningstiden, lagringsplaceringen och säkerheten vid rensningsåtgärder mer än själva katalognamnen.

Originalmedia är den oersättliga innehållsrollen

Uppladdade foton och videor är familjens minnen som applikationen finns till för att bevara. Deras lagringssökväg kan variera beroende på driftsättning och val av lagringsmall, men deras roll är densamma: de är källfiler, inte en cache, och om de går förlorade kan de inte återställas genom att miniatyrbilder eller sökindex återskapas.

En aktuell översikt över självhostning som skiljer på placering av media och databas är användbar eftersom den beskriver lagring som en tillförlitlighetsfråga snarare än som en enda kapacitetssiffra. Betrakta hårdvaruförslagen som exempel, men behåll den mer generella skillnaden mellan stora mängder original och aktivt applikationstillstånd.

Klassificera inte en katalog utifrån hur enkelt det är att återskapa containern. Containrar och applikationsavbildningar kan ersättas, men det monterade media de hänvisar till kanske inte kan det. Innan någon rensning eller migrering genomförs ska du identifiera den kanoniska platsen för originalen och verifiera att en oberoende kopia finns.

PostgreSQL är den auktoritativa relationsrollen

Databasen bevarar applikationens förståelse av användare, tillgångar, sökvägar, album, delning, metadata, inställningar och sökrelaterat tillstånd. En mapp full av foton är därför inte likvärdig med en återställd Immich-instans: filsystemet och databasen beskriver olika delar av samma bibliotek.

Tjänstearkitekturen synliggör detta beroende genom att skilja PostgreSQL från medielagring och bakgrundsbehandling. Den uppdelningen förklarar varför databasfördröjning kan påverka interaktionen och varför en säkerhetskopia av enbart media inte kan bevara alla applikationsrelationer.

Felgränsen är viktig: enbart en databaskopia är inte heller en fotosäkerhetskopia. Den kan återställa metadata och relationer endast när motsvarande mediefiler finns i det förväntade logiska tillståndet. Skydda båda delarna och testa dem tillsammans.

Genererade medier byter lagringsutrymme mot snabbare användning

Miniatyrbilder, förhandsvisningar och kompatibla videokodningar finns för att göra bläddring och uppspelning praktisk utan att originalen behöver bearbetas upprepade gånger. De kan ta betydande plats, men deras återställningsvärde är annorlunda eftersom många av dem kan återskapas om originalen och det nödvändiga applikationstillståndet överlever.

Ett hem-lab-exempel med separata lagringsroller visar varför administratörer ofta placerar aktivt databasarbete och storskalig fotolagring på olika platser. Poängen är inte att alla hem behöver samma diskar, utan att genererade data med hög förändringstakt kan ha en annan prestanda- och säkerhetskopieringspolicy än originalen.

Återskapningsbart betyder inte kostnadsfritt. Att bygga om derivat för ett stort familjebibliotek kan ta timmar eller dagar av CPU-tid, lagrings-I/O och kötid. Att utesluta dem från säkerhetskopieringen är ett beslut om återställningstid, inte ett bevis på att de saknar operativt värde.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Köer och cachar är inte en beständig källa till sanning

Kötillstånd och cachar hjälper det körande systemet att samordna och påskynda arbetet, men de bör inte bli den enda platsen där ett oersättligt faktum finns. Om en tillfällig kö försvinner efter en omstart bör beständigt databas- och filsystemstillstånd fortfarande göra det möjligt för applikationen att avgöra vad som ska hända härnäst.

ZimaSpace-artikeln om Immichs datasökväg är användbar för att skilja beständigt tillstånd från de tjänster som förfrågningar genom systemet. En kö beskriver pågående arbete; den bör inte förväxlas med själva familjearkivet.

Den här modellen är inte längre säker om en anpassad integration lagrar unikt tillstånd endast i en tillfällig sökväg, ett containerlager utan säkerhetskopiering eller på en odokumenterad plats hos en sidotjänst. Inventera anpassade monteringar och åsidosättningar innan du antar att standardkategorierna för beständighet täcker hela driftsättningen.

Skapa en återställningsmatris innan du flyttar lagring

Lista varje roll – original, profiler, databas, genererade miniatyrbilder, kodad video, modellcache, säkerhetskopior, konfiguration och eventuella externa bibliotek. Anteckna för varje roll värdsökväg, om den är auktoritativ, om den kan återskapas, den maximalt acceptabla förlusten och den förväntade återställningstiden.

ZimaSpaces guide till säkerhetskopiering av familjefoton anger rätt operativ gräns: en användbar familjetjänst kräver skyddade medier samt det applikationstillstånd som behövs för att göra dessa medier sammanhängande efter ett fel.

Godkänn lagringsdesignen först när en ny värd kan återställa representativa original, konton och relationer och därefter återskapa alla derivat som medvetet har uteslutits. Om återställningen är beroende av att någon minns en odokumenterad volym eller att ett skrivbart containerlager kan återvinnas, är lagringsrollerna ännu inte säkert definierade.