Immich dovrebbe mantenere spazio di archiviazione libero sufficiente per il più grande lotto di caricamenti previsto, i file derivati e gli output temporanei che può creare, un backup recente del database e un margine di sicurezza del filesystem; non esiste una percentuale universale affidabile per ogni libreria.
Un nucleo familiare che registra video con il telefono, un archivio di foto RAW e una libreria esterna per lo più statica producono picchi molto diversi. Misura un ciclo di elaborazione rappresentativo, calcola il picco di byte e inode aggiuntivi, quindi aggiungi un margine di recupero che rimanga inutilizzato durante la normale elaborazione. Configura gli avvisi sui byte e sugli inode liberi assoluti, perché una percentuale nominale può essere pericolosamente ridotta o inutilmente elevata.
Misura la libreria e un ciclo di elaborazione di picco
Registra le dimensioni degli originali, delle miniature, dei video codificati, dei dati dei profili, dei backup del database e delle posizioni temporanee prima di un'importazione rappresentativa. Esegui l'estrazione dei metadati, la generazione delle miniature, Smart Search o l'elaborazione dei volti e qualsiasi transcodifica video prevista per quel lotto, quindi registra il valore massimo raggiunto.
In un caso con una transcodifica intensiva, lo spazio di archiviazione è cresciuto da circa 100 GB a 326 GB. Questo esempio di crescita specifico di una distribuzione dimostra perché sia necessario misurare la combinazione di contenuti multimediali; non rappresenta un moltiplicatore generale.
Ripeti la prova con il più grande caricamento familiare realistico, non con una singola foto. Il test è superato se sono inclusi tutti i percorsi e i filesystem pertinenti. Se i file temporanei risiedono nella root del container o su un volume separato, misura quella capacità indipendentemente invece di fare affidamento sullo spazio libero del disco della libreria.
Calcola una riserva a partire da componenti identificati
Usa un'equazione di pianificazione: la riserva equivale al lotto di importazione di picco più la crescita misurata di file derivati e temporanei, più la maggiore sovrapposizione prevista con un backup pianificato, più il margine del filesystem e di recupero. Documenta ogni valore e ricalcola dopo aver modificato la politica video, il modello, le dimensioni della libreria o il processo di backup.
Un articolo indipendente sulla pianificazione dello spazio di archiviazione di Immich separa gli originali, i file generati, l'attività del database e la pianificazione della crescita. Usa questo schema come contesto, poi sostituisci le stime generiche con il tuo valore massimo misurato prima di configurare gli avvisi.
Non considerare gli snapshot recuperabili o le eliminazioni in sospeso come spazio libero garantito finché il filesystem non li indica come liberi. La riserva deve inoltre coprire il rollback e la raccolta dei log dopo un processo non riuscito, quindi le code normali non dovrebbero mai poter consumare il margine finale di recupero.
Avvisa su byte, inode e velocità di crescita
Imposta un avviso al di sopra della riserva calcolata e una soglia critica che interrompa le importazioni discrezionali o la rielaborazione prima che le scritture non vadano a buon fine. Monitora i byte assoluti, la percentuale, la disponibilità degli inode, la crescita degli snapshot e l'identità del punto di montaggio, così una condivisione disconnessa non possa riportare una capacità locale fuorviante.
Monitora la velocità di variazione durante le code oltre al totale attuale. Una transcodifica o un backup in rapida crescita può superare la riserva tra due controlli giornalieri. I messaggi di avviso dovrebbero indicare il filesystem e il processo attivo, invece di limitarsi a segnalare che lo spazio di archiviazione di Immich è insufficiente.
L'articolo di ZimaSpace sulla capacità di archiviazione dei NAS domestici aiuta a inserire gli avvisi sullo spazio libero in un piano più ampio di crescita ed espansione.
Convalida la soglia e definisci i tempi di espansione
In una finestra controllata, inizia con uno spazio libero nettamente superiore alla soglia di avviso ed esegui il lotto di picco insieme al modello di backup pianificato. Il test è superato se tutti i processi terminano, i backup vengono completati e lo spazio rimanente resta al di sopra del margine di recupero senza esaurire gli inode.
Monitora mensilmente il consumo della riserva. Espandi la capacità, sposta i contenuti multimediali che occupano più spazio oppure modifica la conservazione prima che lo spazio libero previsto raggiunga la soglia di avviso entro i tempi necessari per l'approvvigionamento. Non aspettare la soglia critica per ordinare nuovo spazio di archiviazione.
Interrompi i nuovi caricamenti o la rielaborazione facoltativa se lo spazio libero si avvicina al limite critico, ma conserva il database e i log. Annulla le modifiche alle policy che eliminano gli originali necessari o l'ultimo backup verificato. Escala il problema quando l'utilizzo riportato non corrisponde alle misurazioni a livello di percorso, perché gli snapshot, i file eliminati ma ancora aperti o un punto di montaggio mancante potrebbero nascondere il processo che sta scrivendo.
Supporto e consigli
Altro da leggere

Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...

Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...

Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...

