Come riparare Immich dopo che il volume del database si è riempito

Quando il volume del database di Immich si riempie, interrompi le nuove scritture di Immich, preserva la directory dei dati di PostgreSQL e crea spazio di lavoro sicuro prima di tentare il ripristino. Non eliminare file da pg_wal o da altre strutture interne di PostgreSQL solo perché sono grandi.

Un filesystem del database pieno può interrompere i checkpoint o il ripristino dopo un arresto anomalo, quindi i riavvii ripetuti potrebbero continuare a fallire anche quando l'applicazione fotografica sembra funzionare correttamente. Innanzitutto verifica quale filesystem è pieno: i dati di PostgreSQL, lo spazio root di Docker, la memoria condivisa o un altro mount; quindi ripristina quel livello senza distruggere le prove che potrebbero servirti per un rollback.

Conferma quale filesystem è pieno e interrompi le ulteriori scritture

Controlla la disponibilità di byte e inode per il mount di PostgreSQL, la root dei dati di Docker, il filesystem root dell'host e qualsiasi percorso tmpfs/memoria condivisa indicato nell'errore. Confronta il timestamp con i log di PostgreSQL. Un messaggio “no space left on device” proveniente da pg_wal indica una situazione diversa rispetto a una cache delle immagini o a una partizione delle miniature piena.

Una discussione sul ripristino del database di Immich mostra PostgreSQL interrompere il ripristino perché non riusciva a scrivere un file WAL temporaneo dopo l'esaurimento dello spazio di archiviazione. Il caso è datato e specifico della distribuzione, ma dimostra perché modificare i permessi dei file o riavviare lo stack non risolve un problema di capacità.

Sospendi i caricamenti e i processi in background, quindi arresta i componenti dell'applicazione che generano nuovo lavoro per il database. Conserva la prima porzione di log con l'errore e la mappa dei mount. Se il filesystem pieno non è quello dei dati di PostgreSQL, ripara la posizione effettivamente interessata invece di spostare inutilmente il database.

Preserva lo stato di PostgreSQL prima di creare spazio

Con PostgreSQL arrestato, crea uno snapshot del filesystem o una copia completa della directory dei dati del database, quando lo spazio e gli strumenti lo consentono. Includi la directory WAL e gli eventuali tablespace non predefiniti come parte di un unico stato. Questa copia di sicurezza ti permette di tornare al punto dell'incidente se il tentativo di ripristino successivo peggiora la situazione.

Le indicazioni sul ripristino di PostgreSQL dopo l'esaurimento del disco rendono esplicita la regola fondamentale: il WAL fa parte della coerenza del database, non è semplice materiale di log, e cancellarlo manualmente può danneggiare il database. Crea capacità espandendo o spostando il volume oppure rimuovendo dati sicuri e non correlati. Non sovrascrivere immediatamente il database danneggiato con l'ultimo backup, a meno che tu non abbia stabilito che lo stato attuale è irrecuperabile e accetti di perdere le modifiche successive a quel backup. Preservare l'istanza piena ti fornisce sia un punto di rollback sia le prove del motivo per cui lo spazio è venuto a mancare.

Ripristina prima PostgreSQL, poi decidi se Immich necessita di una riparazione

Una volta disponibile spazio sufficiente, avvia PostgreSQL da solo o con lo stack minimo necessario e osserva i log di ripristino. Un avvio pulito, un controllo di integrità riuscito e un normale accesso in lettura sono segnali più affidabili dello stato di un container indicato come “running”. Crea un nuovo backup nativo del database non appena il database è abbastanza stabile per consentirlo.

La guida di ZimaSpace sulla manutenzione o sostituzione del database di Immich definisce il passaggio successivo: i normali problemi di dimensioni o prestazioni non dovrebbero attivare una ricostruzione, mentre errori ripetibili di integrità o ripristino possono giustificare il ripristino di una copia verificata del database.

Avvia Immich solo dopo che PostgreSQL rimane in buone condizioni.

Controlla gli utenti, la timeline, diversi originali, gli album, la ricerca e un nuovo caricamento controllato. Se il database si avvia ma le query dell'applicazione falliscono costantemente, conserva i nuovi log e determina se il problema attivo è ora la compatibilità dello schema o della versione, oppure l'integrità dei dati, e non lo spazio libero.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Correggi la causa della crescita e dimostra che il sistema può riempirsi di nuovo in sicurezza

Misura quale componente è cresciuto: le normali tabelle del database, la conservazione del WAL, i backup archiviati sullo stesso volume, i log, i layer di Docker o un percorso imprevisto. Se l'incidente è stato causato da un flusso di archiviazione o replica non riuscito, oppure da un altro servizio che scrive nel volume del database, correggi quella causa invece di limitarti ad aumentare la capacità.

Imposta avvisi con largo anticipo rispetto al punto in cui il volume raggiunge una condizione che impedisce a PostgreSQL di eseguire checkpoint o ripristini. Monitora sia la percentuale sia lo spazio libero assoluto, perché un volume di grandi dimensioni può avere una percentuale libera ridotta ma comunque uno spazio di lavoro sufficiente, mentre un piccolo volume del database può diventare rapidamente pericoloso. Conserva i backup del database al di fuori dello stesso confine di errore che devono proteggere.

Infine, ripeti un normale ciclo di caricamento ed elaborazione in background, crea un nuovo backup del database, riavvia lo stack e riavvia l'host. Il test è superato quando il calo dello spazio libero è stabile, non compaiono errori WAL o di ripristino, le risorse vecchie e nuove sono leggibili e disponi di una soglia documentata che attiva un intervento prima che le scritture falliscano di nuovo.