Recupero dati da server Dell PowerEdge RAID 5 Napoli

Guasto critico su server Dell PowerEdge con RAID 5: rebuild interrotto, errore URE su secondo disco e volume NTFS non montabile. Intervento ProDati con imaging dei dischi, ricostruzione virtuale dell’array e recupero dei dati notarili.

Questo case study descrive un intervento reale simulato su un server Dell PowerEdge T440 utilizzato da uno studio notarile a Napoli per centralizzare atti notarili, fascicoli digitali, PDF firmati, backup PEC, database documentali, repertori, copie autentiche e archivi amministrativi. Il sistema era configurato con 4 dischi SAS Enterprise da 2,4 TB in RAID 5 su controller Dell PERC H740P, con cache write-back protetta da batteria, stripe size 256 KB e file system NTFS su Windows Server 2019.

Il blocco operativo si è verificato dopo il guasto di un primo disco e la successiva sostituzione con avvio del rebuild. Durante la ricostruzione, un secondo membro dell’array ha iniziato a presentare URE (Unrecoverable Read Error) e timeout intermittenti in aree coinvolte dalla parità distribuita. Al termine dell’evento il controller esponeva un virtual disk incoerente, il volume risultava visibile ma non montabile e lo studio non riusciva più ad accedere agli atti e agli archivi critici. L’obiettivo dell’intervento era recuperare il dataset mantenendo struttura cartelle, nomi file, metadati documentali e coerenza dei database quanto più possibile intatti.

Recupero dati server Napoli

Il server era installato nella sala tecnica dello studio e gestiva circa 3,1 TB di dati notarili attivi. Le condivisioni principali contenevano atti in formato PDF/A, scansioni di repertorio, copie autentiche, fascicoli clienti, backup PEC, documentazione fiscale, file di firma digitale e database documentali utilizzati quotidianamente da più postazioni Windows in rete locale.

Nei giorni precedenti al fermo il personale aveva rilevato rallentamenti anomali in apertura dei fascicoli, eventi controller nel log di sistema e segnalazioni predictive failure su un disco SAS. Dopo la sostituzione del membro guasto, il PERC H740P ha avviato il rebuild del RAID 5 sull’array degradato. Durante tale fase un secondo disco ha prodotto errori di lettura latenti, impedendo al controller di ricostruire correttamente tutti gli stripe. Il sistema ha quindi iniziato a esporre sintomi compatibili con Virtual Disk Failed, foreign/inconsistent configuration e impossibilità di montare il volume NTFS in modo standard.

Importante: su server con RAID 5 degradato non bisogna avviare initialize, force online, consistency check aggressivi o rebuild ripetuti senza prima acquisire immagini complete dei membri. In presenza di parità incoerente, una singola operazione errata può sovrascrivere i riferimenti corretti e compromettere in modo definitivo la ricostruzione del virtual disk.

Piattaforma server

Dell PowerEdge T440 con controller PERC H740P, Windows Server 2019 e volume NTFS dedicato agli archivi notarili.

Configurazione RAID

4 x 2,4 TB SAS Enterprise in RAID 5, cache write-back, stripe 256 KB e volume dati condiviso in rete.

Sintomi rilevati

Rebuild interrotto, errori URE, virtual disk incoerente, volume NTFS non montabile e accesso ai fascicoli bloccato.

Dataset critico

Atti notarili, PDF firmati, repertori, PEC, scansioni, database documentali e archivi amministrativi.

Lo studio utilizzava un Dell PowerEdge T440 con 4 dischi SAS da 2,4 TB configurati in RAID 5 hardware su controller PERC H740P. Dal punto di vista tecnico il sistema impiegava cache protetta, stripe size di 256 KB e un volume NTFS su Windows Server 2019. Le share ospitavano atti firmati digitalmente, fascicoli cliente, scansioni, copie autentiche, archivi PEC e repository amministrativi.

Capacità dati attivi
circa 3,1 TB di contenuto realmente occupato
Client collegati
postazioni Windows in segreteria, sala stipule e amministrazione
Protocollo prevalente
SMB con accesso concorrente a cartelle documentali e archivi PEC
Evento scatenante
guasto di un disco, sostituzione del membro e rebuild avviato su array già stressato

Effetto operativo: impossibilità di accedere agli atti in lavorazione, blocco dei fascicoli digitali e rischio concreto di fermo operativo per le attività notarili.

La diagnosi ha evidenziato una catena di eventi tipica dei guasti critici su RAID 5 durante fase di rebuild.

Disco 2 guasto originario
membro inizialmente sostituito dopo predictive failure e degrado progressivo
Disco 3 con URE latenti
errori di lettura emersi solo sotto carico intenso durante la ricostruzione
Metadata controller incoerenti
stato del virtual disk non più allineato con la reale consistenza degli stripe
Parità distribuita non affidabile
alcuni parity block ricostruiti in modo parziale o su base incompleta
NTFS danneggiato
MFT leggibile solo parzialmente, settori critici in area metadata e mount standard impossibile

L’analisi dei blocchi ha mostrato divergenze in specifiche aree di stripe, con perdita di coerenza tra dati e parità. Il controller non era più in grado di esporre un virtual disk consistente e il volume risultava logicamente compromesso pur essendo ancora parzialmente visibile dal sistema operativo.

Conclusione diagnostica: il problema non era limitato al primo disco guasto, ma coinvolgeva simultaneamente controller RAID, parità distribuita e struttura logica del file system NTFS.

L’intervento è stato eseguito con approccio forense e conservativo.

Imaging hardware dei 4 membri SAS
clonazione progressiva con gestione di timeout, mappe di lettura e priorità sui settori critici
Analisi del layout RAID
verifica di ordine dischi, offset iniziali, stripe size, rotazione della parità e coerenza dei metadata PERC
Ricostruzione virtuale dell’array
assemblaggio del RAID 5 su copie di lavoro e validazione degli stripe incoerenti mediante confronto dati/parità
Recupero logico NTFS
ricostruzione della MFT, parsing dei record FILE, verifica dei bitmap e recupero delle directory
Estrazione dati prioritaria
prima atti notarili, fascicoli cliente, PDF firmati e database, poi archivi PEC e repository secondari

Nei punti in cui la parità risultava non affidabile, la ricostruzione è stata guidata attraverso analisi comparativa degli stripe e validazione semantica dei file ottenuti. Le correzioni logiche sono state eseguite esclusivamente sulle copie di lavoro, senza mai operare in scrittura sui supporti originali.

Regola chiave: nessuna operazione di rebuild, consistency check o repair NTFS è stata eseguita sul server originale. Tutta la lavorazione è avvenuta su copie di laboratorio.

La ricostruzione virtuale dell’array ha permesso di recuperare la quasi totalità dei dati professionali dello studio notarile.

File recuperati
PDF/A, DOCX, XLSX, scansioni TIFF/JPG, archivi PEC, database documentali e cartelle fascicolo
Integrità verificata
apertura campionaria di atti firmati, repertori, allegati e basi dati di lavoro
Percentuale utile
97,8% del dataset recuperato con struttura cartelle quasi completa
Elementi mancanti
alcuni temporanei, log secondari e porzioni non critiche nelle aree colpite dagli URE

La validazione finale ha incluso controllo dei documenti firmati digitalmente, verifica hash su campioni significativi e test di apertura dei database documentali maggiormente utilizzati dallo studio.

Outcome: lo studio ha ripreso l'operatività senza dover ricostruire da zero gli archivi principali e ha potuto pianificare una migrazione verso una configurazione più resiliente.

L’analisi iniziale ha mostrato un guasto combinato fisico e logico. Il primo disco del RAID 5 era già in stato di failure conclamata, mentre un secondo membro presentava errori latenti che si sono manifestati solo durante il rebuild, quando il controller ha dovuto leggere in modo esteso l’intero contenuto del set. In questi scenari il RAID 5 diventa particolarmente vulnerabile, perché la perdita di un disco e la presenza di URE su un altro impediscono la corretta ricostruzione della parità e compromettono la coerenza dell’array.

A livello logico, i metadata del controller e la disposizione degli stripe non erano più del tutto consistenti, mentre il file system NTFS presentava danni in aree chiave come MFT e bitmap. Per evitare ulteriori sovrascritture non è stato eseguito alcun rebuild forzato sul server originale. L’intervento è stato condotto esclusivamente su immagini di lavoro ottenute con acquisizione conservativa.

Problemi riscontrati

Primo disco guasto
membro del RAID 5 già sostituito prima dell'arrivo in laboratorio
Secondo disco con URE
letture fallite emerse durante la ricostruzione sotto carico
Metadata controller incoerenti
stato virtual disk non più perfettamente allineato alla realtà fisica
Parità distribuita parzialmente corrotta
stripe incompleti o incoerenti in aree critiche del dataset
NTFS non montabile
MFT e strutture di volume danneggiate dopo il rebuild interrotto

Strategia ProDati

Clonazione hardware dei membri
acquisizione settore per settore con controllo completo degli errori di lettura
Analisi della geometria RAID
verifica di order, stripe, offset e schema di parità del controller PERC
Ricostruzione virtuale del set
assemblaggio del RAID 5 su copie senza scrivere sugli originali
Recupero strutturato NTFS
ricostruzione MFT, parsing metadata e recupero directory tree
Validazione documentale
controllo di atti, PDF firmati, database e archivi PEC prioritari

Dopo la ricostruzione virtuale del RAID 5, è stato possibile enumerare correttamente la struttura NTFS e recuperare la quasi totalità del contenuto originale. Sono stati ripristinati fascicoli cliente, atti firmati, repertori, archivi PEC, documenti fiscali e repository amministrativi con mantenimento di nomi, percorsi e timestamp in gran parte coerenti con la sorgente.

Il recupero ha richiesto 4 giorni lavorativi: 2 giorni per imaging e analisi dei membri critici, 1 giorno per ricostruzione RAID e validazione della parità, 1 giorno per estrazione e verifica campionaria dei file prioritari. La percentuale di recupero utile è stata stimata intorno al 97,8% del dataset accessibile, con perdita limitata ad alcuni file temporanei e a porzioni secondarie non essenziali. A fine intervento è stata consigliata la migrazione verso una configurazione RAID 6 con backup esterno e monitoraggio proattivo SMART/controller.

Fase 1: Diagnosi

Analisi dei log PERC, identificazione dei membri critici, lettura dei metadata RAID e valutazione del danno logico sul volume NTFS.

Fase 2: Ricostruzione

Creazione di immagini complete, ricostruzione virtuale del RAID 5 e validazione della coerenza di stripe e parità.

Fase 3: Consegna dati

Export dei dati recuperati su nuovo supporto, verifica con il cliente dei fascicoli prioritari e report tecnico conclusivo.

Queste sono le domande che riceviamo più spesso quando un server con RAID 5 diventa inaccessibile dopo un guasto multiplo o un rebuild interrotto.

È possibile recuperare dati da un server con RAID 5 dopo un rebuild fallito?

Sì. In molti casi è possibile recuperare dati anche dopo un rebuild fallito, purché si lavori su immagini dei dischi e si ricostruisca correttamente il layout del RAID. La riuscita dipende dallo stato reale dei membri e dalla quantità di stripe compromessi.

Quali configurazioni server supportate per il recupero dati?

Supportiamo server Dell, HPE, Lenovo, Fujitsu e altre piattaforme con controller hardware o RAID software. Interveniamo su RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 e volumi NTFS, ReFS, EXT4, XFS o layer virtualizzati.

Perché un RAID 5 può collassare durante la ricostruzione?

Perché durante il rebuild il controller deve leggere completamente i membri superstiti. Se uno di questi presenta URE, timeout o settori latenti, la parità non è più sufficiente per ricostruire tutti gli stripe in modo coerente e l’array può diventare logicamente inconsistente.

È pericoloso forzare il virtual disk online dal controller?

Sì. Un force online, initialize o consistency check aggressivo può alterare ulteriormente metadata e parità. Nei casi critici è preferibile fermare il server e procedere con una diagnosi professionale basata su copie dei supporti.

Quanto tempo richiede il recupero dati da un server aziendale?

Dipende dal numero di dischi, dalla capacità complessiva, dal livello RAID e dallo stato fisico dei membri. Per un server con alcuni terabyte utili e danno misto fisico-logico, i tempi tipici vanno da 3 a 6 giorni lavorativi.

Approfondisci temi tecnici, consigli pratici e casi reali di recupero dati attraverso articoli sempre aggiornati. Il blog ProDati ti guida nella comprensione delle cause più comuni di perdita dei dati, nelle strategie di prevenzione e nelle procedure professionali che adottiamo nei diversi scenari di guasto, dai sistemi NAS domestici alle infrastrutture RAID aziendali.

NAS Synology guasto? Recupero dati RAID Milano

Recupero dati Synology RAID Milano: case study reale studio di architettura

Guasto critico su NAS Synology DS1821+ con RAID SHR-2: volume non montabile, storage pool in stato “crashed” e accesso ai progetti completamente bloccato. Intervento ProDati con imaging dei dischi, ricostruzione RAID e recupero completo dei file CAD e BIM.