Configura la cache e lo spazio temporaneo di Immich separando innanzitutto lo stato persistente della libreria dai derivati generati, dalla cache dei modelli riutilizzabile e dai dati temporanei realmente sacrificabili del container.
Le miniature e i video codificati possono sembrare cache perché Immich può rigenerarli, ma sono risorse operative persistenti che possono diventare grandi e costose da ricreare. I download dei modelli seguono un ciclo di vita diverso, mentre i log e i dati temporanei del livello scrivibile non dovrebbero consumare silenziosamente il disco di avvio. Assegna lo spazio in base al ruolo, quindi verifica il comportamento durante la pulizia e il riavvio.
Classifica ogni ruolo di archiviazione prima di spostarlo
Crea un inventario con almeno quattro classi: originali e stato applicativo necessario; miniature e anteprime generate; video codificati generati; dati di modelli, log o runtime temporanei. Per ogni classe, annota il percorso attuale, le dimensioni, il tasso di crescita, la politica di backup, il costo di ricostruzione e il servizio che vi scrive.
Una segnalazione degli utenti sulla crescita delle miniature e dei video generati dimostra perché miniature e video codificati debbano essere misurati separatamente. I rapporti individuali non sono universali, perché la combinazione dei contenuti multimediali e le impostazioni di elaborazione modificano la quantità prodotta.
Non etichettare una directory come “cache” solo perché eliminarla libera spazio. Se la sua perdita comporta giorni di rigenerazione, interrompe la riproduzione attiva o rimuove dati che il piano di ripristino prevede di conservare, merita un ruolo persistente esplicito anche se l’applicazione può tecnicamente ricrearla.
Colloca i dati generati ad alta frequenza di accesso dove latenza e durata siano adeguate
Le miniature e le anteprime servono per la consultazione interattiva e spesso comportano numerose letture di piccole dimensioni, mentre i video codificati possono consumare una capacità sequenziale molto maggiore. Un SSD veloce può migliorare le attività che usano molti derivati, ma solo se spostare quel ruolo elimina il tempo di attesa misurato invece di creare un altro piccolo volume che si riempie inaspettatamente.
La spiegazione di ZimaSpace sulla crescita dello spazio occupato dalle miniature offre un insegnamento di archiviazione riutilizzabile: lo spazio attivo dell’applicazione può esaurirsi anche quando gli originali risiedono altrove. I percorsi specifici di Immich sono diversi, ma il requisito di monitorare il ruolo effettivamente scrivibile è lo stesso.
Se i contenuti multimediali principali rimangono su HDD o NAS mentre i derivati vengono spostati sull’SSD, monitora sia le soglie minime di spazio libero sia ogni montaggio dopo il riavvio. Un livello veloce per i derivati è utile solo quando è abbastanza grande da sostenere la crescita normale e il suo guasto non può essere scambiato per la perdita degli originali autorevoli.
Rendi persistente la cache dei modelli in modo intenzionale, ma trattala come ricostruibile
I modelli di apprendimento automatico vengono scaricati o preparati per inferenze ripetute e possono consumare una quantità significativa di spazio. Rendere persistente la cache dei modelli evita download e attività di avvio non necessari, soprattutto con connessioni lente, ma non deve essere confusa con il database o con gli originali delle foto di famiglia nella gerarchia di ripristino.
Una discussione della community sull’architettura di archiviazione di Immich mostra perché gli operatori separino i dati veloci simili alla cache dall’archiviazione principale delle foto. Usa questi layout solo come esempi; verifica i percorsi e i montaggi attuali nella tua definizione Compose prima di spostare qualsiasi elemento.
Se la cache dei modelli viene persa, il ripristino accettabile consiste normalmente nel ricrearla o riscaricarla, purché il servizio possa raggiungere la fonte richiesta e disponga di spazio sufficiente. Documenta questo comportamento affinché uno strumento di backup non utilizzi accidentalmente capacità offsite limitata per proteggere una cache grande ma rigenerabile.
Mantieni sotto controllo i livelli scrivibili, i log e lo spazio temporaneo
I livelli scrivibili dei container non dovrebbero diventare un deposito non documentato per derivati persistenti, transcodifiche temporanee o log di grandi dimensioni. Controlla l’utilizzo del disco Docker e i montaggi dei container affinché ogni percorso di grandi dimensioni e in crescita sia deliberatamente persistente oppure intenzionalmente sacrificabile. Un aumento inspiegabile del livello scrivibile è un sintomo di configurazione, non un obiettivo di pulizia predefinito.
La procedura Docker HQ del 2026 per una pulizia sicura del disco Docker sottolinea l’importanza di verificare prima di eseguire il pruning e di proteggere i volumi che possono contenere database. Applica la stessa cautela: non eseguire comandi di pulizia indiscriminati su un host Immich di produzione finché non conosci la proprietà di ogni volume e livello.
Imposta la rotazione dei log, colloca i percorsi temporanei su uno spazio con sufficiente margine per i picchi e monitora gli inode oltre all’utilizzo in byte quando vengono creati molti file piccoli. Se un percorso temporaneo si riempie, la soluzione corretta è limitarne o spostarne il ruolo, non eliminare directory sconosciute finché l’applicazione non si avvia casualmente.
Convalida le modifiche allo spazio di archiviazione con test di riavvio, ricostruzione e spazio libero
Dopo aver modificato i percorsi, apri elementi meno recenti e recenti, consulta diversi album, riproduci un video, esegui un’attività di generazione di miniature o di apprendimento automatico e carica un nuovo file controllato. Verifica che le scritture finiscano sui dispositivi previsti e che il database continui a fare riferimento a contenuti multimediali leggibili.
Riavvia i container e poi l’host. Una configurazione funzionante rimonta automaticamente ogni ruolo, conserva i derivati e la cache dei modelli previsti, mantiene sacrificabile lo spazio temporaneo e mostra spazio libero sufficiente su ogni livello attivo. Osserva l’archiviazione durante un normale intervallo di carico di lavoro per confermare che la crescita avvenga nei percorsi pianificati.
Ripristina la modifica di un percorso se Immich crea directory duplicate, segnala elementi mancanti o scrive silenziosamente nel livello del container perché un montaggio non è riuscito. Fornisci, in caso di escalation, la mappa dei montaggi, le dimensioni dei percorsi, la proprietà, lo spazio libero del filesystem, l’utilizzo del disco dei container e l’attività esatta che ha scritto per prima nella posizione errata.
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...

