Welke Immich-gegevens moeten behouden blijven, en waarom zijn de opslagrollen belangrijk?

De betrouwbaarheid van Immich hangt ervan af dat originele bestanden en de applicatiestatus persistent blijven, terwijl opnieuw te genereren afgeleiden en tijdelijk werk als andere opslagrollen worden behandeld.

Alle mappen op één volume plaatsen kan werken, maar daardoor wordt minder duidelijk welke gegevens een herbouw moeten overleven, welke gegevens opnieuw kunnen worden aangemaakt en welke gegevens als back-up onafhankelijk moeten blijven. Dat onderscheid bepaalt de hersteltijd, de opslagplaats en de veiligheid van opschoningsacties meer dan de mapnamen zelf.

Originele media zijn de onvervangbare inhoudsrol

Geüploade foto's en video's zijn de herinneringen van het gezin die de applicatie moet bewaren. Het opslagpad kan variëren afhankelijk van de implementatie en keuzes in de opslagtemplate, maar hun rol blijft hetzelfde: het zijn bronbestanden, geen cache. Als ze verloren gaan, kunnen miniaturen of zoekindexen dat niet herstellen.

Een actuele overzichtsgids voor zelfhosting waarin de plaatsing van media en de database wordt gescheiden, is nuttig omdat die opslag benadert als een betrouwbaarheidsontwerp en niet als één getal voor de benodigde capaciteit. Beschouw de voorgestelde hardware als voorbeelden, maar houd het algemenere onderscheid tussen omvangrijke originelen en actieve applicatiestatus in stand.

Classificeer een map niet op basis van hoe eenvoudig het is om de container opnieuw aan te maken. Containers en applicatie-images zijn vervangbaar; de gekoppelde media zijn dat mogelijk niet. Bepaal vóór elke opschoning of migratie de canonieke locatie van de originelen en controleer of er een onafhankelijke kopie bestaat.

PostgreSQL is de gezaghebbende relatierol

De database bewaart wat de applicatie weet over gebruikers, assets, paden, albums, delen, metadata, instellingen en zoekgerelateerde status. Een map vol foto's is daarom niet gelijkwaardig aan een herstelde Immich-instantie: het bestandssysteem en de database beschrijven verschillende delen van dezelfde bibliotheek.

De servicearchitectuur maakt deze afhankelijkheid zichtbaar door PostgreSQL te scheiden van mediaopslag en achtergrondverwerking. Dat verklaart waarom databaselatentie de interactie kan beïnvloeden en waarom een back-up van alleen de media niet elke applicatierelatie kan behouden.

De foutgrens is belangrijk: alleen een databasedump is ook geen back-up van foto's. Zo'n dump kan metadata en relaties alleen herstellen wanneer de bijbehorende mediabestanden in de verwachte logische staat aanwezig zijn. Bescherm beide kanten en test ze samen.

Gegenereerde media ruilen opslagruimte in voor sneller gebruik

Miniaturen, voorbeelden en compatibele videocoderingen bestaan om browsen en afspelen praktisch te maken zonder originelen telkens opnieuw volledig te verwerken. Ze kunnen veel ruimte innemen, maar hun herstelwaarde verschilt omdat veel ervan opnieuw kan worden gegenereerd als de originelen en de vereiste applicatiestatus behouden blijven.

Een thuislabvoorbeeld met gescheiden opslagrollen laat zien waarom beheerders actieve databasebewerkingen en omvangrijke foto-opslag vaak op verschillende plaatsen onderbrengen. Het punt is niet dat elk huis dezelfde schijven nodig heeft, maar dat gegenereerde gegevens met veel wijzigingen een ander prestatie- en back-upbeleid kunnen hebben dan originelen.

Opnieuw te genereren betekent niet kosteloos. Het opnieuw opbouwen van afgeleiden voor een grote familiebibliotheek kan uren of dagen aan CPU-tijd, opslag-I/O en wachtrijtijd kosten. Ze uitsluiten van de back-up is een beslissing over de hersteltijd, niet het bewijs dat ze operationeel waardeloos zijn.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wachtrijen en caches zijn geen duurzame bron van waarheid

De status van wachtrijen en caches helpt het actieve systeem bij het coördineren en versnellen van werk, maar mag niet de enige plaats worden waar een onvervangbaar gegeven bestaat. Als een tijdelijke wachtrij na een herstart verdwijnt, moeten de duurzame database- en bestandssysteemstatus de applicatie nog steeds in staat stellen te bepalen wat er daarna moet gebeuren.

Het ZimaSpace-artikel over het Immich-datapad is nuttig om persistente status te onderscheiden van de services die aanvragen door het systeem voeren. Een wachtrij verklaart werk in uitvoering; ze mag niet worden verward met het gezinsarchief zelf.

Dit model is niet langer veilig als een aangepaste integratie unieke status uitsluitend opslaat in een tijdelijk pad, een niet-geborgde containerlaag of een niet-gedocumenteerde locatie van een sidecar. Breng aangepaste mounts en overrides in kaart voordat je ervan uitgaat dat de standaardcategorieën voor persistentie de volledige implementatie omvatten.

Maak een herstelmatrix voordat je opslag verplaatst

Maak een lijst van elke rol: originelen, profielen, database, gegenereerde miniaturen, gecodeerde video, modelcache, back-ups, configuratie en eventuele externe bibliotheken. Noteer voor elke rol het hostpad, of deze gezaghebbend is, of deze opnieuw kan worden gegenereerd, het maximaal aanvaardbare verlies en de verwachte hersteltijd.

De back-upgids voor familiefoto's van ZimaSpace hanteert de juiste operationele grens: een bruikbare gezinsservice vereist beschermde media plus de applicatiestatus die nodig is om die media na een storing coherent te maken.

Accepteer het persistentieontwerp pas wanneer een nieuwe host representatieve originelen, accounts en relaties kan herstellen en vervolgens alle bewust uitgesloten afgeleiden opnieuw kan genereren. Als herstel afhankelijk is van het onthouden van een niet-gedocumenteerd volume of het terughalen van een schrijfbare containerlaag, zijn de opslagrollen nog niet veilig gedefinieerd.