Dovresti mettere i metadati di Immich su un SSD e i dati in blocco su un HDD?
Sì, un’installazione di Immich spesso trae vantaggio dal mantenere il database e i dati generati sensibili alla latenza su SSD, archiviando invece i file originali di foto e video di grandi dimensioni su HDD, soprattutto quando la libreria è molto più grande dello stato dell’app. La separazione è utile solo se percorsi, margini di spazio libero, backup e procedure di ripristino restano chiari.
La scelta non è semplicemente “metadati veloci, contenuti multimediali lenti”. Immich utilizza in modo diverso diversi ruoli di archiviazione: PostgreSQL gestisce molte operazioni su piccoli dati di stato; miniature e anteprime vengono lette frequentemente durante la navigazione; i video codificati possono essere voluminosi; gli originali privilegiano capacità e durabilità. Misura separatamente questi ruoli prima di spostare qualsiasi cosa.
Separa lo stato caldo con piccoli I/O dai contenuti orientati alla capacità
Fai l’inventario dei dati PostgreSQL, delle miniature, delle anteprime, dei video codificati, della cache dei modelli, degli originali caricati, delle librerie esterne e delle copie di backup. Registra le dimensioni attuali, la crescita, la frequenza di lettura/scrittura, il costo della ricostruzione e se ogni ruolo deve sopravvivere a un ripristino. In questo modo eviti che una generica etichetta come “metadati” nasconda diversi carichi di lavoro molto differenti.
Il framework di archiviazione ZimaSpace per posizionare i metadati multimediali e la cache attiva evidenzia la distinzione utile: database e indici traggono vantaggio da uno storage a bassa latenza, mentre i contenuti multimediali sorgente in blocco possono restare su uno storage ad alta capacità quando il loro schema di accesso non richiede gli stessi IOPS. Se l’HDD attuale mostra una bassa latenza durante le ricerche, la navigazione nella timeline e i processi in background, spostare ogni derivato su SSD potrebbe offrire pochi vantaggi percepibili dall’utente. Mantieni la disposizione attuale finché un confronto controllato non dimostra che il percorso di archiviazione attivo è effettivamente in attesa.
Metti PostgreSQL e i derivati letti più frequentemente su SSD quando sono loro il collo di bottiglia
PostgreSQL e la navigazione ricca di miniature generano molte letture e scritture di piccole dimensioni che possono risultare lente su un disco meccanico occupato, soprattutto mentre importazioni o backup utilizzano lo stesso dispositivo.
Per le disposizioni attuali di Immich, mantieni il database su uno storage locale a bassa latenza e sposta deliberatamente i percorsi dei dati generati supportati, invece di inventare mount annidati arbitrari.
Il meccanismo di archiviazione è ben documentato al di fuori di Immich: il tuning dello storage di PostgreSQL beneficia di un accesso casuale molto più economico rispetto ai dischi rotanti. Questo non garantisce un miglioramento visibile in Immich, ma spiega perché database e indici siano ottimi candidati per lo storage SSD quando la latenza del dispositivo è il tempo di attesa misurato.
Misura il miglioramento utilizzando lo stesso album, la stessa ricerca e lo stesso campione di importazione prima e dopo. Se la latenza del database diminuisce, ma la richiesta percepita dall’utente è ancora in attesa del trasferimento di rete, della decodifica delle immagini o dell’apprendimento automatico, smetti di attribuire il ritardo residuo all’HDD.
Mantieni gli originali su HDD quando capacità e protezione contano più dell’I/O casuale
Le foto e i video originali sono generalmente la classe di dati più voluminosa e spesso vengono letti come file interi, anziché come piccole pagine casuali del database. I grandi pool HDD possono quindi essere una soluzione sensata per gli originali quando offrono l’affidabilità, il throughput e la capacità di backup necessari. Anche il livello HDD richiede spazio libero e una latenza adeguata durante carichi simultanei di importazione e navigazione.
Una lunga discussione sullo storage di Immich relativa alla separazione delle miniature dai contenuti multimediali riflette lo stesso obiettivo operativo: gli elementi generati per la navigazione e gli originali in blocco hanno priorità di accesso differenti. Non dimostra che ogni installazione necessiti di due dispositivi fisici; il vantaggio dipende da dove le richieste sono attualmente in attesa.
Non conservare gli originali insostituibili su HDD solo perché è più economico, trattando poi il RAID come backup. Mantieni una seconda copia e una copia esterna all’host o offline, in base all’obiettivo di protezione domestica. Il tiering dello storage modifica prestazioni e costi; non riduce le conseguenze della perdita dell’unica copia della libreria di famiglia.
Migra un ruolo di archiviazione alla volta e testa i mount dopo il riavvio
Prima di spostare un percorso, acquisisci un backup coerente del database e registra la mappa attuale dei mount tra host e container. Sposta un solo ruolo, avvia lo stack, verifica gli asset vecchi e nuovi, esegui una ricerca, riproduci un video, carica un file usa e getta e conferma che le nuove scritture vengano effettuate sul dispositivo previsto. Non spostare database, miniature, originali e destinazioni dei backup con un’unica modifica.
Riavvia l’host invece di limitarti a ricreare i container. Una configurazione separata funzionante porta online i mount SSD e HDD prima che Immich scriva, conserva utenti e relazioni, legge gli originali campionati e mantiene il monitoraggio dello spazio libero su entrambi i livelli. Una directory sostitutiva vuota in un punto di mount previsto è una condizione per interrompere la procedura. Mantieni la separazione quando il collo di bottiglia misurato migliora e la mappa di ripristino resta comprensibile. Esegui il rollback se la disposizione introduce percorsi obsoleti, asset mancanti, alterazioni dei permessi o un processo di backup che protegge un solo livello. Il miglior design di archiviazione è quello più veloce che puoi comunque ripristinare correttamente.
Prodotti consigliati
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...
