Una configurazione dello storage di Home Assistant sta diventando un rischio per il ripristino quando un solo disco, host, punto di montaggio, credenziale o percorso non documentato può eliminare sia lo stato in esecuzione sia ogni copia di ripristino utilizzabile.
L'avviso spesso compare prima di un'interruzione: i backup risiedono accanto alla macchina virtuale, una condivisione di rete si riconnette usando un percorso diverso, un database è esterno ma viene ripristinato senza un ordine documentato oppure gli archivi includono ricorsivamente se stessi. Mappa ogni ruolo persistente e il relativo dominio di guasto, quindi esegui una revisione del ripristino in sola lettura prima di spostare o eliminare qualsiasi elemento.
Mappa i ruoli dei dati e i relativi domini di guasto effettivi
Elenca il disco di sistema, la configurazione, il database attivo, lo stato degli add-on, i file multimediali, i log, gli snapshot locali, i backup indipendenti, le chiavi di crittografia e la documentazione per il ripristino. Registra per ogni ruolo il disco fisico, il pool di archiviazione, l'host, il percorso di rete, la credenziale e l'amministratore necessari.
Due directory nello stesso pool sono percorsi separati, ma appartengono allo stesso dominio di guasto dello storage. Uno snapshot della macchina virtuale e lo storage del suo host possono guastarsi insieme. Un backup su NAS può dipendere ancora dallo stesso switch, archivio delle password o account amministratore necessari per ripristinare l'ambiente di produzione.
Considera fallita la revisione della configurazione quando un ruolo critico ha un proprietario sconosciuto o quando tutte le copie di ripristino condividono il disco, il pool, l'host o la credenziale dell'ambiente di produzione. Non aspettare che lo spazio libero si riduca prima di correggere questa dipendenza.
Cerca schemi di avviso relativi a capacità e montaggio
Misura la crescita su sette giorni per database, backup, log, file multimediali e file temporanei. Verifica se le destinazioni dei backup sono montate all'avvio del processo, se l'assenza di un montaggio causa scritture in una directory locale di fallback e se un percorso di archiviazione può includere gli archivi precedenti.
Un percorso di backup ricorsivo può causare una crescita rapida senza aggiungere una cronologia recuperabile. Considera la ricorsione un errore di configurazione, non un motivo per acquistare maggiore capacità.
Se la crescita è costante e prevista, confrontala con gli obiettivi di conservazione e con i tempi di ripristino. Se la crescita aumenta a scatti, un montaggio scompare o i percorsi si duplicano, interrompi i nuovi processi di backup e conserva una copia sicuramente valida prima di correggere la destinazione.
Verifica l'indipendenza con uno scenario di perdita controllata
Per ogni dominio di guasto primario, chiediti se il file di backup, la chiave di decrittografia, la destinazione pulita e le istruzioni rimangono disponibili quando quel dominio non è accessibile. Verifica leggendo una copia indipendente ed eseguendo un ripristino isolato, non limitandoti a controllare lo stato positivo del processo.
La possibilità di archiviare i backup al di fuori dell'unità di produzione crea un dominio di guasto separato solo quando anche le relative credenziali e istruzioni per il ripristino sopravvivono alla perdita dell'ambiente di produzione.
Il test è superato quando una copia di ripristino può essere raggiunta senza utilizzare il percorso di produzione guasto. Il test è fallito quando è necessario spostare o replicare il backup e la chiave prima di modificare la configurazione attiva; in caso contrario, la migrazione aumenta il rischio.
Correggi un rischio e prova il ripristino
Separa innanzitutto il dominio di guasto condiviso con l'impatto maggiore, documenta l'ordine di ripristino del montaggio e del database, rimuovi la ricorsione, imposta la conservazione in base alla crescita misurata e monitora la presenza della destinazione prima di ogni backup. Mantieni disponibile la configurazione precedente finché la nuova copia non è stata verificata.
Consulta il limite di affidabilità dello storage di rete prima di collocare lo stato attivo su un montaggio remoto.
Concludi quando l'ambiente di produzione ha una posizione primaria identificata, ogni ruolo critico dispone di un metodo di protezione e un ripristino indipendente soddisfa l'obiettivo di recupero. Porta all'attenzione del team gli errori di I/O dello storage, gli smontaggi ripetuti, gli archivi danneggiati o i cambiamenti inspiegabili di proprietà prima di procedere con altre migrazioni.
Monitora la configurazione dopo la correzione
Dopo la modifica, monitora lo spazio libero, la crescita per classe di dati, la presenza dei montaggi, l'età dei backup, le dimensioni degli archivi e la data del test di ripristino. Gli avvisi devono identificare il ruolo e la destinazione interessati, anziché segnalare soltanto la percentuale dell'intero disco.
Confronta i primi due cicli di backup con la configurazione documentata e verifica che non siano ricomparse directory locali di fallback o percorsi ricorsivi. Verifica che la conservazione elimini solo le copie obsolete previste, mentre la copia di ripristino indipendente rimane disponibile.
Riapri la revisione del ripristino quando cambiano un database, un pool di archiviazione, un protocollo di montaggio, una chiave di crittografia o una destinazione di backup. Una configurazione che aveva superato la verifica prima di una modifica della topologia costituisce una prova per il vecchio sistema, non per quello nuovo.
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...

