Due unità disco sono guaste nel tuo array Synology SHR-1. DSM segnala il pool di archiviazione come Crashato e indica che i dati non possono essere recuperati. Il recupero dati SHR-1 dopo il guasto di due dischi è il tema di questo articolo — e la situazione è più articolata di quanto lasci intendere il messaggio di DSM. La possibilità di recuperare i dati non dipende soltanto dal numero di dischi guasti, ma anche da come si è verificato il guasto e dallo stato dei dischi ancora funzionanti.
Individua prima il tuo scenario
Prima di proseguire, utilizza questa tabella per individuare il tuo caso specifico e accedere direttamente alla sezione pertinente:
| Osservazione | Scenario probabile | Prospettive di recupero dati | Vai a |
|---|---|---|---|
| Entrambi i dischi compaiono nel sistema operativo, i superblock sono leggibili | Guasto logico — dischi fisicamente integri | Possibile | Livello 1 → Livello 2 |
| Un disco è leggibile, l’altro non viene rilevato | Un guasto logico + un guasto fisico | Parziale | Livello 2 → Livello 3 |
| Il secondo disco si è guastato durante la ricostruzione dopo il primo | Classico doppio guasto — probabile perdita parziale dei dati | Parziale | Livello 2 |
| Uno o entrambi i dischi emettono clic, fruscii o rumori di sfregamento, oppure non vengono rilevati | Guasto fisico — testine o piatti | Richiesto laboratorio | Livello 3 |
Perché due guasti compromettono matematicamente SHR-1
SHR-1 utilizza un unico insieme di parità, concettualmente equivalente a RAID 5 in termini di tolleranza ai guasti. Per ogni stripe dell’array, un disco contiene la parità XOR degli altri. Quando si guasta un disco, è possibile ricalcolare qualsiasi blocco di dati mancante: si prende il blocco di parità e lo si applica in XOR a tutti i blocchi di dati ancora disponibili, ottenendo così il valore mancante. Questo è possibile perché c’è una sola incognita e una sola equazione.
Con due dischi guasti, per ogni stripe ci sono due incognite e rimane comunque una sola equazione di parità. Dal punto di vista matematico, il sistema non ha soluzione. Nessun software, indipendentemente da come venga presentato, può ricostruire due valori indipendentemente sconosciuti a partire da una sola relazione XOR. Non si tratta di un limite di uno strumento specifico, ma di una caratteristica intrinseca dello schema di parità.
Il software può recuperare i dati dalle stripe in cui ha contribuito solo uno dei due dischi guasti. Se i file sono memorizzati su stripe che non coinvolgono entrambi i dischi guasti, il recupero dei dati è possibile. I file distribuiti su stripe che coinvolgono entrambi i membri guasti, invece, non sono recuperabili. La percentuale di dati recuperabili dipende dalle dimensioni e dalla distribuzione dei dischi guasti nell’array, motivo per cui spesso è possibile un recupero parziale anche quando il ripristino completo non lo è.
SHR-2 memorizza due insiemi di parità indipendenti per ogni stripe, in modo analogo a RAID 6, e tollera fino a due guasti simultanei di disco senza perdita di dati. Tuttavia, SHR-2 non è immune da questo scenario: tre guasti simultanei compromettono la logica di parità nello stesso modo in cui due guasti compromettono SHR-1. Se è in uso SHR-2 e sono stati persi tre dischi, si applica la stessa logica descritta di seguito. Per un confronto pratico tra la tolleranza ai guasti di SHR-1 e SHR-2, consultare il nostro articolo su recupero dati SHR/SHR-2 dopo un guasto hardware Synology.
L’ordine di guasto dei due dischi è importante
Non tutti i guasti doppi sono equivalenti. La sequenza e la natura dei guasti determinano quali possibilità di recupero dati sono disponibili:
Guasto simultaneo — evento di alimentazione o controller
Entrambi i dischi hanno smesso di rispondere nello stesso momento. I dati su ciascun disco sono probabilmente intatti dal punto di vista fisico: il RAID ha semplicemente perso il quorum. Si tratta dello scenario più recuperabile in caso di doppio guasto, perché i dati di nessuno dei due dischi sono stati sovrascritti parzialmente.
Guasto del secondo disco durante la ricostruzione
Il primo disco si è guastato, l’array è entrato in stato degradato e ha avviato la ricostruzione; poi, a metà processo, si è guastato anche il secondo disco. La nuova parità veniva scritta sul disco sostitutivo proprio mentre il secondo disco originale si arrestava. Le stripe ricostruite prima del secondo guasto restano integre; le stripe in fase di ricostruzione al momento del secondo guasto risultano corrotte. In genere è possibile un recupero parziale dei dati.
Il primo disco si è guastato molto tempo fa, senza essere rilevato
L’array RAID ha funzionato in modalità degradata, senza ridondanza, per un periodo prolungato, dopodiché si è guastato anche il secondo disco. Se il primo guasto non è stato rilevato, nel frattempo potrebbero essere state effettuate ulteriori scritture su stripe degradati. Le probabilità di recupero dei dati dipendono esclusivamente dallo stato fisico del secondo disco guasto. Per capire come individuare prima il problema, vedere il nostro articolo su come riconoscere i primi segnali di guasto del disco rigido.
Valutare lo stato fisico di ciascun disco
Prima di qualsiasi tentativo software, verificare se i dischi sono leggibili a livello fisico. Spegnere correttamente il NAS se è ancora in esecuzione — non eseguire un riavvio forzato e non inserire un disco sostitutivo, perché DSM tenterebbe un nuovo rebuild. Collegare ciascun disco singolarmente a una macchina di recovery.
Se un disco emette clic udibili, rumori di attrito o ripetuti tentativi falliti di avvio del motore — spegnerlo immediatamente e non tentare ulteriori letture. Ogni ciclo di spin-up su un disco con testine danneggiate aumenta il danneggiamento dei piatti. Passare direttamente al Livello 3.
Per i dischi che si avviano senza rumori anomali, eseguire mdadm --examine su ciascuna partizione del dispositivo:
mdadm --examine /dev/sdb3 Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 4b2f8e1a:7c3d9f02:1a4b8c3d:9e2f7b01 Name : DiskStation:2 Creation Time : Fri Mar 10 14:22:31 2023 Raid Level : raid5 Raid Devices : 3 Avail Dev Size : 7813959680 Array Size : 15627862016 Used Dev Size : 7813931008 Data Offset : 2048 sectors Super Offset : 8 sectors Unused Space : before=1968 sectors, after=0 sectors State : clean, degraded Device UUID : 9d3f1c2a:4e8b7f03:2c1d9e4b:7a3f8c01 Update Time : Mon Jun 2 09:14:22 2025 Bad Block Log : 512 entries available at offset 16 sectors Checksum : 3f8a1b2c - correct Events : 247
Verificare tre aspetti: l’Array UUID deve coincidere su tutti i dischi — in caso contrario, il disco appartiene a un altro array oppure il superblock è danneggiato. Il contatore Events dovrebbe essere simile tra i membri — una divergenza marcata indica che un disco ha perso un numero significativo di operazioni di scrittura. Il campo State mostrerà clean, degraded su un disco che faceva parte di un array che ha perso un membro.
Aprire inoltre, a questo punto, il monitor S.M.A.R.T. integrato in RS RAID Retrieve. I valori Reallocated Sector Count e Pending Sectors su un disco ancora funzionante sono importanti: un disco che accumula settori danneggiati durante un periodo già degradato può aver generato errori di lettura silenti che hanno compromesso l’integrità dei dati prima del secondo guasto. Per maggiori informazioni sull’interpretazione dei dati S.M.A.R.T., consultare il nostro articolo sui segni di guasto di un disco rigido.
Tre livelli di ripristino
Seguire questa procedura solo se mdadm --examine restituisce superblocchi validi con UUID corrispondenti su tutte le unità. L’approccio da terminale consente un controllo diretto di ogni fase, ma presenta limiti rigidi: richiede che tutte le unità siano fisicamente presenti e leggibili, non offre una procedura alternativa in caso di superblocchi danneggiati e non consente di stabilire in anticipo quali file risultino corrotti. Creare un’immagine di ogni unità con ddrescue prima di eseguire uno qualsiasi dei comandi riportati di seguito: operare esclusivamente sulle immagini disco.
Passaggio 1 — Creare un’immagine di ogni disco prima di qualsiasi altra operazione
# Installare ddrescue se non è già presente apt-get install -y gddrescue # Creare l’immagine di ciascun disco in un file separato — eseguire il comando per ogni unità ddrescue -d -r3 /dev/sdb /mnt/images/sdb.img /mnt/images/sdb.log ddrescue -d -r3 /dev/sdc /mnt/images/sdc.img /mnt/images/sdc.log ddrescue -d -r3 /dev/sdd /mnt/images/sdd.img /mnt/images/sdd.log
Il flag -r3 indica a ddrescue di ritentare la lettura dei settori illeggibili tre volte prima di marcarli come non recuperabili. Il file .log consente di riprendere l’operazione di imaging in caso di interruzione. Non saltare questo passaggio: un disco con settori danneggiati nascosti può peggiorare ulteriormente sotto il carico di lettura continuo richiesto dalla ricostruzione dell’array RAID.
Passaggio 2 — Verificare i superblock su tutti i membri
# Eseguire su ogni immagine — verificare che UUID ed Events coincidano mdadm --examine /mnt/images/sdb.img mdadm --examine /mnt/images/sdc.img mdadm --examine /mnt/images/sdd.img
Prima di procedere, verificare tre aspetti. L’Array UUID deve essere identico in tutte le immagini — una discrepanza indica che un disco appartiene a un altro array RAID oppure che il relativo superblock è danneggiato. Il contatore Events deve risultare sostanzialmente allineato tra tutti i membri — una differenza di centinaia o migliaia indica che un disco ha perso una serie significativa di scritture. Il numero di Raid Devices deve corrispondere al numero atteso di membri.
Passaggio 3 — Forzare la ricomposizione dai file immagine
# Indica al kernel di trattare i file immagine come dispositivi a blocchi losetup /dev/loop0 /mnt/images/sdb.img losetup /dev/loop1 /mnt/images/sdc.img losetup /dev/loop2 /mnt/images/sdd.img # Forza la ricomposizione — specifica le partizioni dati, non l'intero dispositivo mdadm --assemble --force /dev/md0 /dev/loop0p3 /dev/loop1p3 /dev/loop2p3 # Verifica il risultato della ricomposizione cat /proc/mdstat mdadm --detail /dev/md0
--force ricompone l’array anche in assenza di un numero sufficiente di membri per raggiungere uno stato consistente. L’array risultante è degradato. Le stripe che coinvolgevano entrambi i dischi guasti contengono dati ricostruiti con parità non corretta: i file presenti in tali stripe risulteranno corrotti oppure avranno dimensione zero al momento della copia. I file presenti nelle stripe che interessavano un solo disco guasto sono integri e leggibili. Non è possibile stabilire dall’esterno, prima di tentare la copia, quali file rientrino in una delle due categorie.
Passaggio 4 — Attivare LVM e montare in sola lettura
# Attivare il gruppo di volumi LVM sull’array ricostruito pvscan vgchange -ay # Elencare i volumi logici per individuare il percorso corretto del dispositivo lvs # Montare in sola lettura — non montare mai in lettura/scrittura un array danneggiato mount /dev/vg1/volume_1 /mnt/data -o ro
Montare sempre con -o ro. La scrittura su un array assemblato forzatamente in questo stato estenderà la corruzione anche a stripe precedentemente integre. Una volta eseguito il mount, verificare la struttura delle directory e le dimensioni dei file prima di avviare qualsiasi operazione di copia. I file danneggiati si manifestano come errori di lettura, errori I/O o output di zero byte durante la copia: non esistono segnali preventivi.
Fase 5 — Copia con gestione degli errori
# Utilizzare rsync con registrazione degli errori — salta i file illeggibili invece di interrompersi rsync -av --ignore-errors /mnt/data/ /mnt/destination/ 2>&1 | tee /mnt/rsync.log # Verificare quali elementi sono stati saltati grep -i "error|failed|cannot" /mnt/rsync.log
cp standard si interrompe al primo errore di lettura. rsync --ignore-errors registra l’errore e prosegue con il file successivo, massimizzando la quantità totale di dati recuperati. Esaminare successivamente il log per identificare quali file non è stato possibile copiare: si tratta di quelli presenti sulle stripe che coinvolgono entrambi i dischi guasti.
Quando interrompere e passare al Livello 2:
mdadm --examine mostra UUID non corrispondenti tra i dischi; la ricostruzione con --force non riesce oppure genera un array inactive in /proc/mdstat; l’attivazione di LVM non rileva alcun volume group; il filesystem viene montato ma mostra una struttura di directory vuota o danneggiata. In tutti questi casi, il superblock o i metadati LVM sono troppo compromessi per un recupero manuale — il RAID Constructor di RS RAID Retrieve gestisce questi scenari.
RS RAID Retrieve gestisce l’intero flusso — analisi S.M.A.R.T., imaging dei dischi, ricostruzione dell’array RAID, attivazione di LVM e accesso al filesystem — in un’unica applicazione per Windows, Linux o macOS. Copre due percorsi di ricostruzione distinti, in base allo stato dei superblock mdadm.
Valutazione S.M.A.R.T. — prima di qualsiasi operazione di lettura
Collegare tutti i dischi alla macchina di recupero e aprire il monitor S.M.A.R.T. integrato prima di avviare la scansione. In questo scenario, gli attributi più rilevanti sono Reallocated Sector Count (ID 05), Current Pending Sector Count (ID C5) e Uncorrectable Sector Count (ID C6). Valori diversi da zero in uno qualsiasi di questi parametri — soprattutto sui dischi che sembrano essere i superstiti «sani» — indicano settori che presentavano già errori durante il periodo di degrado precedente al guasto del secondo disco. Un disco ancora funzionante con un numero elevato di settori pending è un’unità che può generare errori di lettura nel corso di una scansione di ricostruzione che richiede diverse ore.
Creazione dell’immagine del drive — proteggi gli originali dallo stress di scansione
Per qualsiasi unità con valori S.M.A.R.T. elevati, utilizzare la funzione integrata di creazione immagine di RS RAID Retrieve per generare un’immagine a livello di settore prima della scansione di ricostruzione. Il modulo di imaging esegue più passaggi sui settori problematici, registra le aree illeggibili con una mappa dei settori e produce un file immagine completo che rappresenta la migliore lettura possibile di quell’unità. Tutte le fasi successive — ricostruzione dell’array, attivazione di LVM, scansione del file system — vengono eseguite sul file immagine statico anziché sull’unità in tempo reale. In questo modo si evita un ulteriore degrado del drive dovuto al carico di lettura di una scansione completa dell’array, che in una configurazione SHR multi-terabyte può richiedere diverse ore.
Ricostruzione automatica dell’array — quando i superblocco sono integri
RS RAID Retrieve esegue la scansione di tutti i dischi e delle immagini collegate alla ricerca delle firme del superblocco mdadm. Quando vengono individuate, il software legge l’UUID dell’array, il livello RAID, i ruoli dei dispositivi membri, la dimensione del blocco di striping e i contatori degli eventi su tutti i membri. Ricostruisce quindi la topologia del volume SHR — array mdadm → volume fisico LVM → gruppo di volumi → volume logico → file system Btrfs o ext4 — senza richiedere un quorum valido e senza scrivere alcun dato sui dischi di origine. In caso di doppio guasto, con entrambi i dischi fisicamente leggibili e i superblocco integri, questa procedura in genere non richiede alcun intervento manuale.
La ricostruzione viene eseguita in modalità degradata: gli stripe a cui hanno contribuito entrambi i dischi guasti non possono essere ricostruiti tramite parità e i file corrispondenti vengono contrassegnati come non accessibili. Gli stripe a cui ha contribuito solo uno dei due dischi guasti vengono ricostruiti a partire dai dati residui del membro rimasto e dalla parità: tali file sono completamente recuperabili. Il programma contrassegna i file non accessibili nell’albero delle cartelle prima della fase di copia, così da consentire di valutare con precisione l’ambito del recupero prima di scrivere i dati sulla destinazione.
RAID Constructor — quando i metadati del superblocco sono danneggiati
Se il rilevamento automatico non produce alcun risultato — perché i superblock sono stati in parte sovrascritti, corrotti da un evento del firmware oppure mancanti a causa di un disco guasto che è stato scritto parzialmente durante il rebuild RAID — passare a RAID Constructor. Questa modalità consente di specificare manualmente tutti i parametri dell’array RAID, bypassando completamente il superblock.
Per prima cosa, individuare l’offset del file system con l’editor HEX integrato. Aprire ogni disco o immagine nell’editor HEX e cercare il marker ASCII LABLEONE. Nelle configurazioni SHR e SHR-2, questa stringa indica l’inizio dell’area dati del volume. Il settore immediatamente precedente al settore LABLEONE — che sarà riempito con zeri — è il settore di offset. Annotarne il numero: questo è il valore da inserire come parametro Offset in RAID Constructor.
Inserire i seguenti parametri in RAID Constructor:
| Parametro | Valore SHR-1 | Valore SHR-2 |
|---|---|---|
| Tipo RAID | RAID 5 | RAID 6 / Left synchronous (P+Q) |
| Dimensione del blocco | 64 KB | 64 KB |
| Byte per settore | 512 | 512 |
| Ordine dei dischi | Corrispondenza con la sequenza originale degli alloggiamenti NAS — prima il bay 1 | |
| Offset | Numero di settore individuato nella ricerca di LABLEONE (per ciascun disco) | |
Se l’ordine originale dei dischi non è noto, determinarlo per tentativi: aggiungere i dischi all’elenco Selected Disks in sequenze diverse e osservare, dopo ogni modifica, l’albero del file system ricostruito. Un ordine corretto produce una struttura di directory riconoscibile; un ordine errato genera dati incoerenti o un albero vuoto. Il valore di offset deve essere impostato singolarmente per ogni disco fisico o immagine: può differire tra i membri se, nella configurazione SHR originale, i dischi avevano capacità diverse.
Se uno dei dischi guasti non è affatto collegabile — guasto meccanico, non rilevato — usare Add empty disk per inserire un segnaposto nella posizione corretta nell’elenco dei dischi. RS RAID Retrieve considera il segnaposto come un membro completamente illeggibile: i stripe in cui quel disco contribuiva vengono ricostruiti dalla parità usando i membri rimanenti (recuperando i dati di quei stripe), mentre i stripe per i quali è necessaria anche la sua contribuzione di parità vengono contrassegnati come non recuperabili. Questo rappresenta il massimo recupero possibile da una configurazione con un disco fisicamente non accessibile.
Scansione del filesystem e recupero selettivo dei file
Una volta ricostruito l’array — automaticamente oppure tramite RAID Constructor — RS RAID Retrieve esegue la scansione del filesystem Btrfs o ext4 sul volume logico. La scansione attraversa l’albero del filesystem, identifica le aree integre e danneggiate e genera un elenco completo delle directory. I file e le cartelle i cui blocchi dati intersecano stripe non recuperabili vengono contrassegnati prima dell’avvio della copia: non è necessario procedere per tentativi per capire quali elementi siano accessibili.
Selezionare i file e le cartelle da recuperare, indicare una destinazione su un’unità separata con spazio libero sufficiente e avviare la copia. I dischi sorgente e le immagini vengono accessi in sola lettura per l’intera durata dell’operazione. Per informazioni sul livello LVM tra l’array mdadm e il filesystem, consultare il nostro articolo sulla struttura e il funzionamento di LVM.
Il recupero dati software — a qualsiasi livello — dipende dal fatto che le testine di lettura/scrittura del disco siano in grado di fornire i dati dei settori al controller host. Quando il gruppo testine è danneggiato meccanicamente, l’attuatore a bobina mobile è bloccato oppure il cuscinetto del motore del piatto ha subito un guasto, il disco non può soddisfare le richieste di lettura indipendentemente dalla configurazione software. Un laboratorio sostituisce il gruppo testine in camera bianca (ISO Classe 5 o superiore), regola l’allineamento delle testine in funzione dello specifico piatto e utilizza strumenti a livello firmware per estrarre i dati dei settori dalle aree che l’elettronica del disco rifiuterebbe di leggere.
L’output di un intervento in laboratorio è un insieme di immagini disco a livello di settore, una per ogni unità. Queste immagini contengono la migliore lettura possibile della superficie di ciascun disco, inclusi i settori recuperati da zone fisicamente danneggiate che, in condizioni normali, generano errori I/O. Una volta ricevute, queste immagini vengono utilizzate direttamente in RS RAID Retrieve: il RAID Constructor legge i superblock (oppure utilizza il metodo di offset LABLEONE se i superblock sono danneggiati), ricostruisce la topologia dell’array SHR e procede con la scansione del filesystem e il recupero esattamente come descritto nel Livello 2.
Il limite di parità in caso di doppio guasto si applica alle immagini da laboratorio esattamente come ai dischi collegati fisicamente: le stripe che coinvolgono entrambi i membri guasti restano matematicamente non recuperabili, indipendentemente da quanto pulita sia stata l’estrazione dei dati dei settori. Il vantaggio del laboratorio è l’accesso ai settori che gli strumenti software, operando su un’unità degradata in tempo reale, avrebbero ignorato a causa degli errori di lettura, con un incremento potenzialmente significativo della percentuale di file recuperabili.
Per una panoramica più ampia su quando sia opportuno rivolgersi a un servizio professionale di recupero dati e su cosa comporti la procedura, consultare il nostro articolo su recupero dati da hard disk guasti.
Passare direttamente al Livello 3 se si osserva uno di questi segnali
- Rumore di clic, stridio o ronzio proveniente da qualsiasi unità all’accensione
- Unità non rilevata nel BIOS/UEFI o in alcun output di
lsblk - Unità rilevata, ma
mdadm --examinerestituisce errori di I/O invece dei dati del superblocco - La temperatura della superficie dell’unità aumenta fino a livelli anomali in pochi minuti dal collegamento
- Nel valore S.M.A.R.T. Reallocated Sector Count (ID 05) si contano centinaia di settori riallocati, oppure Spin Retry Count (ID C0) aumenta a ogni ciclo di alimentazione
Non tentare un recupero software su un’unità con guasto meccanico. Ogni passaggio di lettura aggiunge usura alle superfici delle testine e ai piatti già danneggiati. Spegnere l’alimentazione e contattare un laboratorio prima di tentare qualsiasi ulteriore accesso.
Un doppio guasto in SHR-1 si colloca al confine tra recupero software e recupero fisico dei dati. La posizione esatta di questo confine dipende dallo stato delle unità, non dalle funzionalità degli strumenti. Due unità fisicamente integre, con superblocco integro, consentono al software una reale possibilità di recupero parziale. Due unità con guasto meccanico richiedono il ricorso immediato a un laboratorio di recupero dati. Nella maggior parte dei casi reali, i doppi guasti si collocano in una zona intermedia tra questi due estremi: per questo, in questo scenario la valutazione dello stato delle unità prima di scegliere il percorso di recupero è ancora più importante che in qualsiasi altro caso di questa serie.
