Prima di un altro tentativo di riparazione RAID, considera ogni file attualmente leggibile e ogni membro originale come prove che potrebbero non sopravvivere alla prossima ricostruzione, controllo del filesystem o assemblaggio forzato. Riduci le scritture, documenta il set di membri, copia i dati di maggior valore su una destinazione indipendente, verifica quella copia ed esegui la ricostruzione successiva da immagini o cloni ogni volta che lo stato dell'array è incerto.
Metti in pausa tutto ciò che può modificare la sorgente
Ferma applicazioni, macchine virtuali, download, indicizzazione media, lavori di backup, servizi di database e condivisioni utente che scrivono sul volume interessato. Un tentativo di riparazione è più difficile da valutare quando i carichi di lavoro ordinari continuano a modificare file, parità, journal e timestamp sottostanti.
Non riavviare ripetutamente solo per vedere se l'array ritorna. Un riavvio può cambiare i nomi dei dispositivi, cancellare i log volatili, attivare l'assemblaggio automatico o avviare una ricostruzione in background. Conserva lo stato attuale prima di testare un'altra ipotesi.
Registra la topologia di archiviazione prima di toccarla
Crea una mappa dei membri che collega ogni bay fisico a un numero di serie, porta del controller, nome dispositivo attuale, ruolo RAID e stato di salute. Salva il livello RAID, le impostazioni di stripe o chunk, l'UUID dell'array, l'ordine dei membri, i conteggi degli eventi, il progresso della ricostruzione e il primo errore rilevato.
Esporta anche i log del controller, del kernel, del filesystem e SMART. Il membro che sembra peggiore ora potrebbe non essere quello che ha fallito per primo. Un tentativo di recupero successivo necessita di prove sufficienti per distinguere un disco obsoleto, un disco che sta fallendo di recente e un percorso di connessione difettoso.
Copia prima i file leggibili più preziosi
Quando il filesystem è leggibile e i membri non si stanno deteriorando, metti al sicuro i file utilizzabili prima di eseguire un'operazione completa a lungo termine. Una discussione tecnica descrive una soglia pratica: copia prima i dati leggibili e passa alla clonazione quando compaiono errori di copia. Inizia con documenti, foto, file di progetto, database di applicazioni, chiavi di crittografia ed esportazioni di configurazione che non possono essere ricreati.
Copia su un confine di archiviazione fisico diverso. Non spostare i file, non eliminare gli originali dopo la copia e non scrivere i dati recuperati nuovamente sull'array interessato. Conserva un manifesto contenente il percorso di origine, il percorso di destinazione, la dimensione del file, il timestamp e il risultato della copia.
Verifica la copia prima di considerarla sicura
Una copia completata può ancora contenere file illeggibili, percorsi saltati o dati danneggiati. Confronta il numero di file e i byte totali, registra i percorsi falliti, apri file rappresentativi e usa checksum per gli elementi critici quando possibile.
Mantieni la destinazione della copia in sola lettura o scollegata dopo la verifica. Se la riparazione successiva danneggia la sorgente, la copia protetta deve rimanere indipendente dal processo di riparazione e da qualsiasi lavoro di sincronizzazione.
Scegli tra copia dei file e imaging dei membri
| Condizione attuale | Azione preferita iniziale | Motivo |
|---|---|---|
| Filesystem stabile e file critici leggibili | Copia prima i file di maggior valore | Il modo più veloce per mettere in sicurezza dati utili |
| Il filesystem non si monta ma i membri si leggono in modo affidabile | Immagina o clona ogni membro | Preserva la geometria dell'array per la ricostruzione offline |
| Un membro ha errori di lettura ma il volume si apre ancora | Copia i file critici, poi crea un'immagine con tentativi controllati | Una scansione completa potrebbe peggiorare il dispositivo debole |
| Due o più membri sono instabili | Spegni e usa il recupero basato sull'immagine prima di tutto | Un'altra ricostruzione potrebbe superare la tolleranza ai guasti residua |
| L'ordine dei dischi o la geometria RAID è incerta | Non creare o inizializzare un array | I nuovi metadati possono sovrascrivere gli indizi necessari per ricostruirli |
La scelta è guidata dalla stabilità della sorgente piuttosto che da una sequenza universale. Gli esperti di recupero distinguono tra estrazione diretta da un'unità stabile e imaging controllato di un'unità instabile, perché una lettura massiva può mettere ulteriore stress su hardware marginale.
Immagina i membri originali prima di test distruttivi
Quando l'accesso normale ai file è incompleto o l'array ha già fallito una riparazione, crea immagini o cloni a livello di settore dei membri originali. Il motivo è eseguire un lavoro intensivo di recupero su un'immagine del disco invece che sulla sorgente danneggiata. Etichetta ogni immagine con il numero di serie della sorgente e la posizione nel bay, e conserva gli originali invariati.
Esegui le riparazioni solo su un set di lavoro reversibile
Testa l'assemblaggio dell'array, i controlli del filesystem, la riparazione dei metadati o il software di recupero dati su copie ogni volta che è possibile. Un esempio di recupero consiglia di creare un'immagine prima di eseguire una riparazione del filesystem e lavorare su quell'immagine. Monta prima un volume ricostruito in sola lettura e scrivi i file estratti in una destinazione separata.
Registra ogni modifica al set di lavoro. Se un test usa un ordine dei membri, una dimensione della stripe, un offset o una rotazione della parità diversi, crea una nuova copia di lavoro invece di sovrascrivere l'unica ricostruzione che ha prodotto dati leggibili.
Evita azioni che riscrivono le prove
Le azioni che creano nuovi metadati non sono diagnosi neutrali. Le linee guida professionali per il recupero RAID avvertono specificamente contro l'inizializzazione dei membri, l'esecuzione di riparazioni del filesystem con scrittura abilitata o l'avvio di una ricostruzione incerta perché ciascuna può sostituire prove di cui una successiva ricostruzione ha bisogno.
- Non inizializzare un nuovo RAID con i membri originali.
- Non eseguire una riparazione del filesystem con scrittura abilitata solo perché il volume non si monta.
- Non riaggiungere un disco obsoleto finché non si conosce il set di membri autorevole.
- Non cancellare una configurazione esterna prima di salvare i metadati del controller e dei membri.
- Non continuare a riavviare una ricostruzione che fallisce sempre nella stessa area.
- Non salvare i file recuperati sull'array che si sta recuperando.
Se la ricostruzione attuale è ancora in corso mentre il numero di errori aumenta, segui il flusso di lavoro più sicuro per una ricostruzione RAID con errori I/O in aumento prima di decidere se continuare, copiare, fare l'immagine o fermarsi.
FAQ
Dovresti copiare i file o fare l'immagine dei dischi prima?
Copia prima i file critici quando il filesystem è stabile e i dischi non stanno peggiorando. Fai l'immagine prima quando il filesystem non è disponibile, la geometria RAID è incerta, una riparazione è già fallita o letture ripetute potrebbero peggiorare un membro marginale.
Dovresti continuare a copiare quando compaiono errori di lettura?
Continua solo quando gli errori sono limitati, stabili e i file di maggior valore sono ancora recuperati. Se gli errori aumentano, il disco si disconnette o la stessa area si blocca ripetutamente, interrompi la copia ordinaria e passa a un imaging controllato o a un recupero professionale.
Quando dovrebbe essere spento il NAS?
Spegni quando più membri sono instabili, una risincronizzazione inspiegabile sta scrivendo sugli originali, i dischi fanno clic o si disconnettono, o i dati sono irrecuperabili e la prossima azione non è completamente compresa.
L'obiettivo della protezione
La prossima riparazione non dovrebbe mai essere l'unica via rimasta per i dati. Proteggi i file leggibili, conserva le immagini dei membri e verifica prima una copia indipendente. Una volta che lo stato originale può essere ripristinato, la riparazione diventa un esperimento piuttosto che una scommessa a senso unico.
Supporto e consigli
Altro da leggere

Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...

Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...

Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...

