Intervento & differenziatori
Datacenter Lombardia Aruba Ponte San Pietro Oltre il supporto del vendorController RAID failed: i dati sono sui dischi, non sul controller.
Un controller RAID fallito non perde dati di per sé — la maggior parte dei dischi resta intatta. Il rischio è "fare la cosa sbagliata" sul nuovo controller: inizializzazione, clear foreign config, rebuild non voluto. La procedura corretta preserva l'array.
Tre operazioni che chiudono il recovery.
- Initialize dell'array sul nuovo controller: distrugge la configurazione esistente. È l'operazione più distruttiva del menu del controller.
- Clear Foreign Config senza prima averla letta: perde l'informazione su ordine slot, dimensione chunk, livello RAID.
- Rebuild preventivo in assenza di reale degradazione: aggiunge stress all'array nel momento più fragile e può portare a doppio disco se uno dei dischi è marginale.
Re-import sicuro, in 4 step.
- Documentazione preliminare: ordine fisico dei dischi (foto), output del vecchio controller se ancora leggibile, eventuali eventi pre-failure.
- Sostituzione controller con modello identico o compatibile (verificata matrice firmware).
- Re-import della foreign config: lettura dei metadati DDF / proprietary del vendor, importazione dell'array nel corretto ordine, verifica integrità.
- Validazione: array online in modalità read-only iniziale, verifica I/O senza errori, poi ritorno graduale alla modalità nominale.
Le domande che ci fanno più spesso.
Sul nuovo controller serve modello esattamente identico?
Idealmente sì. In pratica funziona spesso anche con controller della stessa famiglia (es. PERC H730 → H730P, Smart Array P440ar → P408i-a) se firmware è compatibile e algoritmo RAID supportato. Cross-vendor (es. PERC → MegaRAID) non funziona: i metadati DDF sono diversi.
Senza il vecchio controller, come capite l'ordine slot?
I metadati DDF (o equivalenti proprietari) scritti dal controller sui dischi contengono l'informazione di slot. Sui dischi sani questi metadati sono leggibili anche senza il controller originale: li parsiamo per ricostruire l'array virtualmente prima di importarlo sul nuovo controller.
E se il fault del controller ha già danneggiato la coerenza dell'array?
Caso raro ma possibile (es. controller che ha continuato a scrivere parzialmente durante il fault). In questo caso l'array re-imported sarà inconsistente e va trattato come recovery RAID 5/6 più complesso, lavorando sui cloni. La diagnosi iniziale dice se siamo nello scenario semplice o nello scenario complesso.