Recupero dati da RAID, NAS e sistemi di storage

Un RAID non sostituisce il backup: prima di un rebuild vanno protetti ordine dei dischi, geometria e cronologia degli eventi.

Richiedi un preventivo

NAS multi-disco spento con vani e unità numerati dopo il secondo disco segnalato guasto

Sintomo

Congelare ordine dei dischi e cronologia del RAID

Volume degradato, foreign configuration e più unità offline descrivono stati diversi.

Si annotano sostituzioni, blackout, aggiornamenti e rebuild prima di qualsiasi nuova azione.

Ogni disco resta associato al proprio vano: provarlo in posizioni differenti può scrivere nuovi metadati.

Prima dello spegnimento, se il sistema è ancora stabile, si fotografano schermata del controller, allarmi, slot e cablaggio senza avviare test o sincronizzazioni. Si registrano marca, modello, seriale, capacità e ruolo di ogni membro, compresi hot spare e dischi rimossi in precedenza. L’ora in cui ciascuna unità è diventata offline è importante: due dischi presenti oggi possono appartenere a stati temporali diversi. La configurazione non viene cancellata e nessun membro foreign viene importato automaticamente.

La cronologia distingue primo guasto, eventuale sostituzione, inizio e percentuale del rebuild, secondo errore e azioni successive. Anche un’unità dichiarata failed può contenere un’immagine più coerente rispetto a un membro su cui il rebuild ha scritto parzialmente. Per questo i vecchi dischi non vengono scartati né rimessi a caso negli slot. Backup, snapshot e replica vengono inventariati come sorgenti separate, senza ripristinarli sull’array incidentato. Il dossier conserva tutte le varianti prima di scegliere il punto utile.

Controller, cache e relativo modulo batteria o flash possono conservare parametri e scritture pendenti. Vengono registrati insieme ai dischi, soprattutto se il sistema usa cifratura o layout proprietari. Sostituire il controller con una revisione simile non garantisce la stessa interpretazione e può proporre un’inizializzazione. L’hardware originale rimane disponibile finché geometria e chiavi non sono chiarite.

Associare seriale, vano e stato a ciascun membro del RAID
Registrare primo guasto, sostituzioni e avanzamento di eventuali rebuild
Conservare controller, cache, chiavi e vecchi dischi come sorgenti separate

Ordine fisico

Foto, etichette e seriali mantengono il legame fra disco e slot. La posizione non viene dedotta in seguito dalla sola schermata del controller.

Sequenza temporale

Primo errore, sostituzione e secondo guasto definiscono quali membri appartengono allo stesso stato. Un disco rimosso può conservare blocchi ancora decisivi.

Spostare un membro in un altro vano o importare una configurazione foreign può scrivere nuovi metadati e cancellare indizi sulla geometria originale.

Monitor mostra un rebuild RAID sospeso mentre le unità dell’array restano identificate nei rispettivi vani

Prima mossa

Perché un altro rebuild può rendere il danno più esteso

La procedura presuppone membri sani e geometria esatta.

Settori instabili o ordine errato vengono propagati nel volume.

Datastrophe blocca le riparazioni automatiche e acquisisce i supporti singolarmente in modalità controllata.

Prima dello spegnimento non si avviano SMART estesi, scrub o test di superficie: leggono l’intera capacità e possono stressare i membri deboli senza creare una copia. Una volta arrestato, l’array resta fermo fino all’etichettatura e all’acquisizione. Disponibilità momentanea non prevale sulla conservazione delle sorgenti. Si salvano soltanto informazioni disponibili con basso rischio.

Spegnere il sistema dopo un rebuild fallito o un secondo disco offline
Etichettare vano e numero di serie di ogni unità
Non inizializzare un nuovo membro e non cambiare l’ordine

La priorità è creare immagini, non ottenere a ogni costo un volume montato

Durante un rebuild, i membri superstiti vengono letti intensivamente e i dati ricostruiti vengono normalmente scritti sul disco sostitutivo. Nei pool, durante un reshape o in procedure proprietarie, le scritture possono essere redistribuite più ampiamente. Se una seconda unità presenta settori lenti, la sollecitazione può farla uscire prima del completamento. Con ordine, stripe o parità errati, il controller può ricostruire blocchi secondo una configurazione sbagliata e sovrascrivere dati ancora utili sulla destinazione. Anche le operazioni presentate come correttive non sono equivalenti: uno scrub ZFS verifica i checksum e può correggere automaticamente un blocco soltanto se dispone di una copia ridondante valida; un import ZFS con opzioni di recupero può riavvolgere transazioni del pool, mentre `btrfs check --repair` può riscrivere i metadati. Queste operazioni non vanno avviate sugli originali prima dell’acquisizione.

Hot swap non significa che ogni sostituzione sia sicura durante un incidente

Prima di estrarre un’unità si associa in modo permanente il numero di serie allo slot e si arrestano servizi che continuano a scrivere. Un disco nuovo non viene inizializzato e un membro espulso non viene forzato online. Se il sistema ospita servizi essenziali, si organizza una continuità alternativa; mantenere l’array degradato in produzione aumenta modifiche, carico e distanza dal punto temporale che si vuole recuperare.

Dischi RAID etichettati collegati singolarmente a una stazione di imaging con mappe degli errori

Tecnica

Stabilizzare in laboratorio i membri RAID danneggiati

Ciascun disco riceve una propria mappa di lettura.

Un’unità che ticchetta può richiedere laboratorio e camera bianca; le unità sane non vengono aperte.

La ricostruzione parte dalle migliori immagini disponibili, mai dai dischi originali in produzione.

L’acquisizione registra settori letti, time-out, reset e passaggi successivi per ciascun seriale. Un hard disk stabile può essere copiato in sequenza; un membro meccanicamente instabile può richiedere priorità ai metadati RAID e alle aree che contengono dati critici. L’apertura avviene soltanto se la diagnosi fisica la giustifica e in un ambiente controllato adatto, non come procedura standard per tutti i dischi. Rumori, continue ricalibrazioni o perdita del collegamento limitano il numero di accensioni.

SSD, cache flash e tier ibridi seguono una strategia diversa: TRIM, garbage collection e wear-leveling possono modificare l’accessibilità dei blocchi anche senza rumore. I log permettono di combinare letture successive senza perdere ciò che era già stato acquisito. Gli originali restano protetti da scrittura; più ipotesi di ordine e geometria vengono provate sulle copie, così un test errato non altera le uniche sorgenti disponibili. Ogni immagine mantiene la dimensione e la posizione logica del membro.

Se una meccanica richiede un intervento sui gruppi testine, vengono valutati compatibilità del donatore e stato delle superfici prima di procedere. I settori mancanti restano marcati nell’immagine, permettendo alla parità e ai livelli superiori di essere valutati con informazioni trasparenti. Il membro non deve tornare affidabile per uso quotidiano: basta ottenere una lettura controllata delle zone utili.

Creare una mappa di lettura distinta per ogni seriale
Limitare accensioni e ricalibrazioni dei membri meccanicamente instabili
Provare ordine e geometria soltanto sulle immagini protette

Dischi meccanici

Rumori, perdita del collegamento e settori lenti guidano la strategia. Le aree necessarie alla geometria o ai dati prioritari possono essere acquisite per prime.

SSD e cache flash

TRIM, garbage collection e wear-leveling richiedono una lettura diversa. Ogni supporto conserva la propria dimensione e funzione nel tier originale.

Il rebuild sottopone i membri superstiti a letture intensive e scrive i blocchi ricostruiti sull’unità sostitutiva; pool e reshape possono distribuire altre scritture.

Schema dell’ordine dei dischi, dimensione dello stripe, offset e rotazione della parità su una stazione RAID

Diagnosi

Determinare livello, stripe, offset e rotazione della parità

RAID 0, 1, 5, 6, 10, SHR e varianti proprietarie distribuiscono i blocchi in modo diverso.

Metadati e strutture ricorrenti del file system consentono di testare le ipotesi.

La correttezza viene verificata aprendo file che attraversano più stripe.

La corruzione silenziosa viene cercata anche quando la parità sembra matematicamente valida. Se un controller ha scritto dati errati su tutti i membri, il calcolo può risultare coerente ma il file no. Per questo si aprono formati noti, si confrontano checksum applicativi e si verificano più periodi. La geometria è necessaria, ma non sufficiente per dichiarare integro il contenuto.

Le ipotesi sono valutate con blocchi distribuiti, non con un solo settore iniziale

Si ricercano superblock, firme di partizione, sequenze del file system e record del controller per ricavare ordine, offset iniziale, stripe size e rotazione della parità. La configurazione dichiarata dall’interfaccia non viene accettata senza confronto: dopo reset o migrazione può descrivere un nuovo array vuoto. Per RAID 6 vanno identificate le parità P e Q e la loro rotazione; per RAID 10 occorre riconoscere coppie e ordine.

La parità viene controllata su molte stripe e in zone diverse del volume

Un risultato corretto solo in testa può nascondere un membro disallineato, un cambio di geometria o un’unità appartenente a un momento precedente. File di grandi dimensioni, archivi e immagini virtuali attraversano numerose stripe e sono utili per la verifica. Se due membri divergono nel tempo, si confrontano combinazioni e journal per scegliere il set più coerente. Nessuna directory visibile è sufficiente da sola a validare la ricostruzione.

Immagini dei membri RAID ricomposte virtualmente su monitor prima del montaggio dei volumi

Ricostruzione

Aprire LVM, Btrfs, ZFS e pool sopra il blocco RAID

Dopo la geometria possono esserci mdadm, LVM, Storage Pool, snapshot o cifratura.

Ogni livello conserva mappe proprie, che devono restare coerenti con il blocco RAID ricostruito sottostante.

L’analisi mantiene separate le copie, evitando che una riparazione del file system alteri la ricostruzione sottostante.

SHR, mdadm, LVM, Btrfs, ZFS e pool proprietari possono aggiungere mirror, checksum, deduplicazione e snapshot sopra il RAID fisico. I rispettivi metadati vengono letti in sola lettura e confrontati con copie secondarie o uberblock quando disponibili. Uno scrub ZFS o Btrfs verifica i checksum e può correggere i blocchi soltanto se dispone di copie ridondanti valide; non ricrea un blocco privo di sorgente. Un import ZFS con opzioni di recupero può riavvolgere transazioni, mentre `btrfs check --repair` o un fsck possono riscrivere i metadati. Queste prove vengono eseguite su derivati della ricostruzione, mai direttamente sulle immagini dei membri.

Una geometria RAID corretta può produrre soltanto dati cifrati se manca la catena di accesso. Thin provisioning e snapshot distinguono inoltre blocchi mai allocati da aree perse; riempire ogni vuoto con zeri può nascondere un danno reale. La diagnosi conserva una mappa dei livelli e delle lacune, così problemi del disco, della parità, del pool e del file system non vengono confusi in un’unica riparazione opaca. Volumi cifrati richiedono chiavi, password o configurazione autorizzata.

I checksum di ZFS o Btrfs aiutano a individuare blocchi incoerenti, ma la riparazione richiede una copia valida da cui ricostruirli. I report mantengono questa distinzione e non presentano uno scrub completato come prova automatica che ogni file sia sano. Quando ridondanza e parità sottostanti sono esaurite, il checksum segnala il danno senza ricreare il contenuto.

Identificare mdadm, LVM, pool, snapshot e cifratura sopra il RAID
Confrontare copie di metadati e checksum senza import forzato
Distinguere blocchi mai allocati da lacune realmente perse

La parità funziona solo con la geometria corretta

Ordine, stripe size, offset e rotazione devono coincidere. Una combinazione errata può mostrare cartelle ma corrompere silenziosamente i file ricostruiti.

Livelli superiori

Pool, snapshot e volumi cifrati vengono aperti dopo la ricostruzione del blocco. Ogni correzione resta su una copia derivata e documentata.

Uno scrub completato può segnalare incoerenze senza ricreare i dati mancanti; checksum e parità hanno valore solo se esiste una copia valida.

Priorità

Mettere in priorità condivisioni, macchine virtuali e database

Un NAS ospita spesso backup, videosorveglianza e servizi attivi insieme.

Le priorità aziendali definiscono l’ordine.

VMDK e database vengono controllati nella loro coerenza interna, non considerati validi solo perché hanno la dimensione prevista.

Una condivisione aggiornata oggi, un database coerente alla notte precedente e una registrazione video di un intervallo preciso possono richiedere combinazioni diverse. Il referente definisce ciò che riapre l’attività e ciò che può attendere. Questa scelta guida sia le letture di un membro instabile sia l’ordine di validazione sul volume ricostruito. La priorità include anche il punto temporale.

La lista di priorità indica condivisioni, cartelle, periodi, proprietari e formato necessario

Per un server possono contare database e VM recenti; per il recupero video NVR contano invece un intervallo e alcuni canali; per un repository di backup la catena che permette un restore verificato. Questa gerarchia guida la lettura delle zone critiche su un membro debole e la prima estrazione dal volume ricostruito. Un referente competente controlla presto nomi, date e contenuto, evitando di elaborare per giorni la sorgente sbagliata.

Ogni tipo di dato riceve un test appropriato

Documenti e archivi vengono aperti, video riprodotti in più punti, database esportati o interrogati su copia, VMDK e VHDX collegati in ambiente isolato. Un file con dimensione corretta può contenere stripe mancanti o parità ricostruita male. I risultati parziali restano separati da quelli validati. Quando un backup integro copre parte del periodo, il recupero si concentra su ciò che non esiste altrove invece di duplicare dati già disponibili.

File e database aperti su una copia del volume RAID per verificarne la coerenza oltre il semplice montaggio

Limiti

Documentare gli stripe mancanti e la qualità del risultato

La parità può compensare alcuni guasti, non qualsiasi combinazione.

Datastrophe indica geometria ricostruita, aree assenti e test eseguiti.

Un albero di directory senza controllo d’integrità non equivale a un recupero completo.

RAID 5 tollera normalmente un membro mancante, RAID 6 due, ma solo se gli altri blocchi sono leggibili e appartengono allo stesso stato. Settori difettosi distribuiti possono creare stripe senza abbastanza informazioni anche quando il numero di dischi offline sembra entro la tolleranza. Il rapporto distingue aree ricostruite con parità, blocchi assenti e file toccati da quelle lacune, senza dedurre completezza dal solo livello RAID. Rebuild interrotto e scritture successive complicano ulteriormente il tempo logico.

Manifest, conteggi e checksum aiutano a controllare i file, mentre una selezione funzionale conferma condivisioni, database, video o VM prioritari. Il NAS guasto non viene rimesso in servizio come unica copia e i dati non vengono riscritti sull’array originale. Dopo l’accettazione, conservazione e cancellazione delle immagini tecniche seguono gli accordi. Dati personali o aziendali possono richiedere destinatari autorizzati e supporto di uscita cifrato. La consegna avviene su storage sano o tramite trasferimento protetto.

L’accettazione usa esempi noti al proprietario: un documento recente, una query, un backup ripristinabile o un video nel periodo atteso. Le anomalie vengono collegate alle stripe mancanti e non nascoste in una cartella generica. Dopo conferma, il risultato viene copiato in una nuova strategia di backup testata. L’array incidentato resta escluso dal percorso di produzione.

Immagine e mappa degli errori di ogni disco
Geometria verificata con file reali
Share, VM e database controllati per priorità

Mappa delle lacune

Settori illeggibili e stripe non ricostruibili vengono collegati ai file interessati. Il rapporto distingue dati validati, parziali e non verificabili.

Accettazione funzionale

Il proprietario verifica documenti, query, backup o video noti. Manifest e checksum controllano la consegna, ma non sostituiscono il test del contenuto.

Un albero di cartelle visibile non dimostra la completezza: file prioritari, stripe mancanti e controlli applicativi devono essere correlati.

Schema dei vani, seriali dei dischi e registri del NAS preparati accanto all’array spento

Orientamento

Integrare RAID, server, dischi virtuali e camera bianca

Per applicazioni e sistemi vedere recupero server; per snapshot VMDK e VHDX.

Gli interventi meccanici sono spiegati nella pagina camera bianca.

Vanno conservati anche i membri sostituiti in precedenza.

Se sono disponibili vecchi membri, vengono contrassegnati con la data approssimativa di rimozione. Imballi troppo grandi senza fissaggio permettono urti fra dischi; caddy e viti non viaggiano sciolti. Una consegna ordinata preserva la cronologia e riduce decisioni affrettate durante la prima diagnosi. Un elenco cartaceo o digitale accompagna ogni seriale e componente.

Si indicano cifratura, snapshot, virtualizzazione e dati prioritari

Per la valutazione iniziale servono produttore e modello di NAS o controller, livello dichiarato, numero e capacità dei membri, seriali per slot, messaggi, cronologia di guasti e rebuild. Fotografie di frontale e cablaggio completano la mappa senza richiedere un nuovo avvio. Configurazioni esportate sono utili solo se ottenibili senza scrivere o sollecitare ulteriormente un sistema instabile.

Controller, caddy e alimentatori sono separati affinché non colpiscano le unità

Per la spedizione dall’Italia, ogni disco viene spento, etichettato con slot e seriale, protetto antistaticamente e immobilizzato in materiale antiurto. Il sistema completo viene inviato soltanto se configurazione o cifratura lo richiedono. La diagnosi stabilisce i supporti necessari, la strategia di imaging e l’obiettivo; il preventivo non deriva dal solo numero di dischi. Il risultato viene restituito su un supporto distinto e validato con il referente.

Domande frequenti

Che cosa bisogna annotare prima di spegnere un RAID o un NAS degradato?

Vanno conservati ordine degli slot, numeri di serie, dischi segnalati come mancanti e messaggi del controller. Una fotografia del cablaggio e la cronologia di sostituzioni o rebuild evitano di perdere informazioni decisive per la geometria dell’array.

Perché un nuovo rebuild può peggiorare un RAID danneggiato?

Un rebuild sottopone a letture intensive i membri superstiti e scrive i dati ricostruiti sul disco sostitutivo. Nei pool, nei reshape o in procedure proprietarie, le scritture possono interessare porzioni più ampie. Se un altro membro è debole oppure ordine e geometria sono errati, l’operazione può aggravare l’incidente; prima si acquisiscono i supporti e si ricostruisce la configurazione su copie.

Come si gestisce un disco RAID che presenta settori instabili?

Il membro viene stabilizzato e acquisito con una strategia che limita i tentativi sulle zone deboli. Gli altri dischi restano identificati nel loro ordine e la ricostruzione di stripe e parità avviene fuori dall’array originale.

Che risultato è possibile quando mancano alcuni stripe del RAID?

Dipende dal livello RAID, dalla posizione dei blocchi mancanti e dai file prioritari. Il rapporto distingue elementi integri, parziali e non ricostruibili, indicando dove la parità o i membri disponibili non consentono una continuità affidabile.

Supporti

Altre competenze

Diagnosi

Dubbi su un supporto o su un guasto?

Datastrophe valuta il rischio prima di ogni intervento e indica il percorso più prudente.

Richiedi una diagnosi