Immich herstellen nadat het databasevolume vol raakt

Wanneer het Immich-databasevolume vol raakt, stop dan nieuwe schrijfbewerkingen van Immich, bewaar de PostgreSQL-gegevensdirectory en creëer veilige werkruimte voordat je herstel probeert. Verwijder geen bestanden uit pg_wal of andere interne PostgreSQL-onderdelen alleen omdat ze groot zijn.

Een volledig gevuld databasebestandssysteem kan checkpoints of crashherstel onderbreken, waardoor herhaalde herstarts kunnen blijven mislukken, zelfs als de fototoepassing zelf gezond lijkt. Controleer eerst welk bestandssysteem vol is—de PostgreSQL-gegevensopslag, de Docker-hoofdopslag, gedeeld geheugen of een andere mount—en herstel vervolgens die laag zonder het bewijsmateriaal te vernietigen dat je mogelijk nodig hebt om terug te draaien.

Bevestig welk bestandssysteem vol is en stop verdere schrijfbewerkingen

Controleer de beschikbare ruimte in bytes en inodes voor de PostgreSQL-mount, de Docker-gegevenshoofdmap, het rootbestandssysteem van de host en elk tmpfs-/gedeeld-geheugenpad dat in de fout wordt genoemd. Vergelijk het tijdstip met de PostgreSQL-logboeken. Een melding “no space left on device” uit pg_wal betekent iets anders dan een volle afbeeldingscache of thumbnailpartitie.

Een discussie over databaseherstel in Immich laat zien dat PostgreSQL het herstel afbrak omdat het geen tijdelijk WAL-bestand kon schrijven nadat de opslag vol was geraakt. De casus is oud en afhankelijk van de specifieke implementatie, maar toont aan waarom het wijzigen van bestandsrechten of het herstarten van de stack een capaciteitsprobleem niet oplost.

Pauzeer uploads en achtergrondtaken en stop vervolgens de toepassingsonderdelen die nieuwe databasebewerkingen genereren. Bewaar het eerste venster met foutmeldingen en de mountkaart. Als het volle bestandssysteem niet daadwerkelijk het PostgreSQL-gegevensbestandssysteem is, herstel dan de juiste locatie in plaats van de database onnodig te verplaatsen.

Bewaar de PostgreSQL-status voordat je ruimte vrijmaakt

Maak PostgreSQL gestopt en neem, wanneer de opslag en hulpmiddelen dit toestaan, een bestandssysteemsnapshot of volledige kopie van de databasegegevensdirectory. Neem de WAL-directory en eventuele niet-standaard tablespaces als één geheel op. Met deze veiligheidskopie kun je terugkeren naar het moment van het incident als de volgende herstelpoging de situatie verergert.

De herstelrichtlijnen voor PostgreSQL bij een volle schijf maken de belangrijkste regel expliciet: WAL maakt deel uit van de consistentie van de database en is geen gewone logruis. Handmatig verwijderen ervan kan de database beschadigen. Creëer in plaats daarvan capaciteit door het volume uit te breiden of te verplaatsen, of door andere veilige, niet-gerelateerde gegevens te verwijderen. Overschrijf de mislukte database niet meteen met de laatste back-up, tenzij je hebt besloten dat de huidige status niet herstelbaar is en accepteert dat wijzigingen sinds die back-up verloren gaan. Door de volle instantie te bewaren, behoud je zowel een terugvalpunt als bewijs voor de oorzaak van het capaciteitsverlies.

Herstel eerst PostgreSQL en beslis daarna of Immich reparatie nodig heeft

Zodra er voldoende ruimte is, start je PostgreSQL afzonderlijk of met de minimaal vereiste stack en houd je de herstel-logboeken in de gaten. Een schone opstart, een geslaagde gezondheidscontrole en normale leestoegang zijn sterkere signalen dan een containerstatus met “running”. Maak een nieuwe database-eigen back-up zodra de database stabiel genoeg is.

De ZimaSpace-gids over onderhoud of vervanging van een Immich-database geeft de volgende grens aan: gewone omvang- of prestatieproblemen zouden geen herbouw moeten veroorzaken, terwijl herhaalde integriteits- of herstelfouten het terugzetten van een geverifieerde databasekopie kunnen rechtvaardigen.

Start Immich pas nadat PostgreSQL gezond blijft.

Controleer gebruikers, tijdlijn, verschillende originelen, albums, zoeken en één gecontroleerde nieuwe upload. Als de database start maar toepassingsquery's consequent mislukken, bewaar dan de nieuwe logboeken en bepaal of schema-/versiecompatibiliteit of gegevensintegriteit—en niet vrije ruimte—nu het actieve probleem is.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verhelp de oorzaak van de groei en bewijs dat het systeem opnieuw veilig kan vollopen

Meet welk onderdeel is gegroeid: normale databasetabellen, WAL-behoud, back-ups op hetzelfde volume, logboeken, Docker-lagen of een onverwacht pad. Als het incident is veroorzaakt door een mislukte archiverings-/replicatieworkflow of een andere service die naar het databasevolume schrijft, herstel dan die oorzaak in plaats van alleen de capaciteit te vergroten.

Stel waarschuwingen in ruim voordat het volume het punt bereikt waarop PostgreSQL geen checkpoint meer kan uitvoeren of herstellen. Monitor zowel het percentage als de absolute vrije ruimte, omdat een groot volume een klein percentage vrije ruimte kan hebben en toch voldoende werkruimte kan bieden, terwijl een klein databasevolume snel gevaarlijk kan worden. Bewaar databaseback-ups buiten dezelfde foutgrens die ze moeten beschermen.

Herhaal ten slotte een normale upload- en achtergrondverwerkingscyclus, maak een nieuwe databaseback-up, herstart de stack en start de host opnieuw op. Het systeem is geslaagd wanneer de vrije ruimte stabiel afneemt, er geen WAL-/herstelfouten optreden, oude en nieuwe assets leesbaar zijn en er een gedocumenteerde drempel is die actie activeert voordat schrijfbewerkingen opnieuw mislukken.