Unraid cache corruption errors: proteggere i dati e individuare la causa

Procedura

1. Conservare il messaggio e lo stato iniziale

   Registra testo esatto, orario e primo sintomo osservato. Esporta le diagnosi Unraid prima del riavvio, se il sistema è ancora accessibile. Annota nome del pool, seriali, filesystem e configurazione di ridondanza. Distingui errori di checksum, problemi di ingresso e uscita, mount in sola lettura e danneggiamento di una singola applicazione. Non sono situazioni equivalenti. Segna anche interruzioni elettriche, cambi di cavi o aggiornamenti precedenti. Una base chiara evita che, dopo molti tentativi, restino visibili soltanto gli effetti delle ultime modifiche.

2. Ridurre scritture e salvare quanto è leggibile

   Arresta i servizi che modificano continuamente il pool attraverso i loro controlli ordinari, quando possibile. Individua dati recenti o unici che non esistono altrove. Copiali prima su un dispositivo sano e indipendente. Un'altra cartella sullo stesso pool non è una destinazione di salvataggio adeguata. Registra errori di lettura e non insistere senza limite su un disco che scompare o mostra segnali meccanici anomali. Se l'hardware è instabile, valuta ogni ulteriore prova in funzione delle possibilità di recupero rimaste, non del desiderio di far sparire l'avviso.

3. Identificare filesystem e copie ridondanti

   Controlla se il pool utilizza Btrfs, ZFS o un altro filesystem supportato. Verifica il profilo reale di dati e metadati invece di dedurre protezione dal numero di unità. I checksum possono rilevare un problema, ma una correzione richiede condizioni adatte e una copia valida disponibile. Un singolo disco non ottiene una seconda copia completa soltanto perché usa un filesystem avanzato. Mantieni separati pool e array nella diagnosi. Nomi di dispositivo simili non rendono intercambiabili procedure, percorsi o requisiti dei relativi strumenti.

4. Scegliere controlli coerenti con il caso

   Consulta il procedimento ufficiale per filesystem e versione installati. Per Btrfs valuta le informazioni di stato e lo scrub previsto, con i suoi limiti. Per ZFS usa lo stato del pool e il percorso documentato. Alcune verifiche XFS richiedono invece il filesystem non montato. Non trasformare un comando trovato in rete in una riparazione standard. Opzioni invasive possono modificare strutture ancora recuperabili. Se dispositivo o risultato non sono chiari, conserva diagnosi e supporti e chiedi una valutazione specifica prima di eseguire operazioni che scrivono.

5. Collegare diagnosi hardware e strategia di recupero

   Confronta stato delle unità e registro del sistema. Reset delle connessioni, errori di trasporto, alimentazione, temperatura e instabilità della memoria possono meritare attenzione. Un riepilogo SMART positivo non esclude ogni problema del percorso. Osserva variazioni e orari. Decidi poi tra copia su storage sano, sostituzione e riparazione appropriata sulla base delle evidenze. Conserva i supporti originali fino alla verifica. Dopo il recupero, le applicazioni devono aprire record e file significativi: una cartella nuovamente visibile è soltanto un primo controllo.

Guida approfondita

La parità dell'array non copre il pool

Le unità di parità Unraid proteggono i dati dell'array secondo la configurazione prevista. Un pool SSD separato ha una propria struttura. Anche due dischi di parità non ricreano automaticamente un database presente soltanto sul pool. Controlla dove si trovano realmente i dati di ogni condivisione. La vista aggregata può nascondere che i file recenti non sono ancora arrivati all'array. Includi questi contenuti nel backup indipendente e non considerarli sacrificabili soltanto perché il percorso viene chiamato cache.

Separare immagine applicativa e dati personali

Un'immagine Docker danneggiata non prova da sola che l'intero pool sia corrotto. Allo stesso modo, ricrearla non risolve un problema del filesystem sottostante. Individua il file interessato e proteggi configurazione, database e caricamenti persistenti. Quando il servizio è abbastanza sano, un'esportazione supportata può essere utile; non improvvisare una riparazione del database soltanto per ottenere una copia. Dopo aver stabilizzato lo storage controlla anche sistemi ospiti e macchine virtuali. Il loro avvio può lasciare nascosti errori in documenti utilizzati raramente.

Formattare non è riparare

La formattazione crea una nuova struttura di filesystem e non recupera i file precedenti. Un pool vuoto che torna montabile cambia l'aspetto del problema, non restituisce i contenuti. Questa operazione appartiene a un eventuale rifacimento consapevole dopo aver verificato le copie e identificato ogni dispositivo coinvolto. Fino a quel momento, stato originale e registri restano importanti. Anche rimuovere e ricreare un pool non è un tentativo neutro. Prima di modifiche distruttive deve essere chiaro quale dato è stato salvato e quale potrebbe andare perso.

Mover non rende sani i dati danneggiati

Mover applica regole di posizionamento e spostamento, ma non è una cronologia indipendente né un sistema generale di recupero. Un file incompleto non diventa corretto spostandolo. Controlla direzione, destinazione e stato dei contenuti prima di azioni manuali. Evita copie improvvisate tra condivisione utente e percorsi dei dischi sottostanti, perché possono rappresentare gli stessi file. Per il salvataggio usa una destinazione chiaramente separata. Riattiva le automazioni normali soltanto quando diagnosi e obiettivo del recupero sono comprensibili.

Misurare il ritorno alla stabilità

Conserva i contatori iniziali e i registri. Azzerare un numero può rendere il pannello tranquillo senza eliminare la causa. Confronta nuove osservazioni dopo carichi ordinari con la situazione documentata. Se un disco sostitutivo presenta errori sullo stesso collegamento, controlla il percorso comune. Riavvia i servizi uno alla volta e prova i loro dati. Questo aiuta a riconoscere una ricorrenza legata a un'attività specifica, evitando che il riavvio contemporaneo di tutto renda di nuovo confusa l'origine del problema.

Rendere più semplice il prossimo intervento

Inserisci dati del pool, configurazioni e backup coerenti dei database in un piano chiaro. Prova un recupero separato e annota le versioni usate. Attiva notifiche raggiungibili e considera un arresto controllato in caso di problemi elettrici. Il miglioramento principale non consiste soltanto in una nuova SSD. Consiste nel notare prima la prossima anomalia e nel non lasciare nuovamente l'unica copia attuale di contenuti importanti sul dispositivo che sta mostrando errori. Una piccola prova periodica mantiene valido questo risultato.

Confronto delle situazioni

Domande frequenti

Guide correlate

• Backup 3-2-1: organizzare le copie e verificare il ripristino