Storwize V3700 con 13 dischi SAS: il datastore VMware recuperato senza lo storage

A settembre ci arriva un nuovo caso. Tredici dischi SAS da 1,2 TB. Venivano da uno storage IBM Storwize V3700 che reggeva l’infrastruttura VMware di un’azienda: una quarantina di macchine virtuali, fra cui il gestionale e il suo database. Della macchina in sé nemmeno l’ombra (il cliente dice che si è guastata in modo irreparabile). Solo i dischi, e uno di questi era guasto (guasto meccanico con testine rotte).

Prima che il caso arrivasse da noi, qualcuno aveva già provato la strada più battuta, i programmi di ricostruzione RAID più diffusi. Nessun risultato utilizzabile. Chi conosce l’architettura di un IBM Storwize non se ne stupisce.

La priorità del cliente era comunque chiara: il database del gestionale, per poter ripartire con urgenza estrema. Tutto il resto, le altre macchine e le cartelle condivise, poteva anche aspettare qualche giorno.

Perché ricostruire il RAID qui non basta

Un IBM Storwize non scrive i dati come un normale controller RAID. Nei dischi ci sono tre strati: gli array RAID, un pool che li riunisce e li divide in blocchi da 1 GB, e i volumi che il sistema presenta ai server, montati pescando quei blocchi dal pool.

La conseguenza è controintuitiva. Un volume non sta in un punto preciso di un array. Il suo contenuto è sparso, a blocchi da un gigabyte, può attraversare due array diversi, e l’ordine in cui i pezzi dovrebbero essere lo conosce solo lo Storwize, annotato nella sua tabella interna.

Se si ricostruisce semplicemente il RAID su questi dischi, nel migliore dei casi (quando i parametri sono giusti) ci si ritrova un disco virtuale che contiene tutto ma nell’ordine sbagliato. Il file system legge le prime strutture (quindi spesso si vede anche la Root corretta con le cartelle), ma poi non trova ciò che si aspetta e rifiuta di aprirlo. È come un camion di mattoni scaricato davanti al cantiere: i mattoni ci sono tutti ma non sono messi al loro posto. È quello che presumibilmente era successo al tentativo fatto prima di noi.

Prima i dischi, poi i metadati

Il primo lavoro è sempre mettere al sicuro quello che c’è. La regola fissa del recupero dati è che si lavora solo su copie, mai sull’originale: abbiamo quindi fatto copie settore per settore creando delle immagini di ogni disco. Il disco guasto non l’abbiamo mai collegato in quanto il contenuto è stato ricostruito con la parità del RAID5.

Nella parte finale di ogni disco lo Storwize tiene circa mezzo gigabyte di metadati, con le copie della configurazione del sistema. Analizzandoli è saltata fuori la prima anomalia: i dischi non raccontavano la stessa storia. Alcuni si fermavano al 2014, altri al 2016, altri ancora all’ultimo aggiornamento del 2025. Non è un segno di guasto. Il sistema IBM Storwize scrive quei dati solo su alcuni dischi alla volta, per cui ognuno conserva la fotografia dell’ultima volta in cui è stato usato per quel compito. Su un sistema la cui prima configurazione risale a undici anni prima, con modifiche accumulate nel frattempo, è quasi la norma. Per chi deve rimettere insieme i pezzi significa una cosa sola: nessuna singola versione va presa per buona senza verifica.

Due RAID 5 e una mappa da ritrovare

Per capire come erano organizzati i dischi abbiamo esaminato i dati e le informazioni di parità del RAID5, quelle che permettono al sistema di tollerare il guasto di un disco senza perderne il contenuto.

Abbiamo così individuato due gruppi. Il primo era completo, mentre nel secondo mancava proprio il disco con il guasto meccanico. Il suo contenuto, però, poteva essere ricostruito a partire dagli altri dischi del gruppo. Non è stato quindi necessario intervenire sulle testine danneggiate: quel disco è rimasto nella sua busta per tutta la lavorazione.

A quel punto abbiamo ricostruito l’ordine dei dischi e il modo in cui i dati erano distribuiti al loro interno. Per farlo abbiamo confrontato le possibili configurazioni con le strutture ancora leggibili, fino a individuare quella che trovava riscontro nei dati.

Ricostruiti i due RAID, il lavoro non era però finito. Mancava ancora il passaggio che aveva impedito ai precedenti tentativi di arrivare a un risultato utilizzabile: capire come lo Storwize avesse organizzato i volumi sopra quei due gruppi.

Il datastore VMware era distribuito fra entrambi gli array. Nel corso degli anni lo storage aveva assegnato e spostato porzioni di dati, aggiornando ogni volta la propria mappa interna. Per ricostruire il volume bisognava ritrovare quella mappa e usarla per rimettere ogni pezzo al suo posto.

Le informazioni erano ancora sui dischi, ma in versioni diverse. Alcune descrivevano una configurazione precedente, altre rispecchiavano gli ultimi aggiornamenti del sistema. Era quindi necessario confrontarle e verificare quale corrispondesse davvero ai dati presenti.

Con una configurazione vecchia, la ricostruzione sembrava funzionare solo in parte. Si riconoscevano alcune strutture, ma proseguendo nella lettura emergevano le incongruenze: ciò che cercavamo non si trovava dove avrebbe dovuto essere. Vedere delle cartelle, in queste condizioni, non significa ancora poter recuperare correttamente i file funzionanti.

La configurazione più recente ha permesso di risolvere il problema. Ne erano rimaste poche copie e una si trovava sul tredicesimo disco, quello che non apparteneva più a nessuno dei due array. A prima vista poteva sembrare un disco avanzato, senza più alcuna utilità. Conservava invece una copia aggiornata delle informazioni che ci servivano.

Un dettaglio che vale la pena raccontare, perché quando arriva uno storage smontato non sempre è chiaro quale ruolo abbia avuto ciascun disco. Anche un’unità ormai esclusa dagli array può conservare informazioni utili per ricostruire quello che è successo.

Usando la mappa corretta, i test hanno cominciato a dare risultati positivi. Abbiamo potuto ricomporre il volume di archiviazione VMware, verificarne le strutture e procedere con l’estrazione delle macchine virtuali.

Il database, prima di tutto

Il cliente ci aveva indicato una priorità: recuperare il database del gestionale. Le altre macchine virtuali e le cartelle condivise potevano aspettare; il gestionale serviva per organizzare la ripartenza dell’azienda.

Una volta ricostruito il volume di archiviazione VMware, abbiamo quindi estratto per prima la macchina virtuale che conteneva il database, insieme ai relativi snapshot. Il recupero non si è concluso con la copia: abbiamo riletto i file dalla destinazione e confrontato il contenuto con i dati di origine, per verificare che il trasferimento fosse avvenuto correttamente.

Due giorni dopo l’arrivo dei dischi, il database era stato recuperato e verificato. Il cliente aveva così a disposizione la parte più urgente e poteva cominciare a pianificare il ripristino dei servizi.

Nel recupero dati è essenziale anche segnalare con chiarezza eventuali parti non leggibili. Se un file contiene zone che non è stato possibile recuperare, queste vengono documentate e indicate al cliente. Il fatto che un file sia stato estratto non basta, da solo, a considerarlo integro.

Siamo partiti da tredici dischi, uno dei quali guasto, senza avere a disposizione lo storage originale. I tentativi precedenti non avevano prodotto dati utilizzabili e le configurazioni rimaste sui dischi non erano tutte aggiornate.

Il recupero ha richiesto di ricostruire prima i due RAID e poi il modo in cui lo Storwize aveva distribuito i volumi. Ritrovata e verificata la mappa corretta, siamo riusciti ad accedere al datastore e a recuperare il database nei tempi richiesti dall’urgenza del cliente.

Se vi capita uno storage che non si avvia

Non reinizializzate MAI il sistema e non ricreate gli array. Sui dischi possono essere ancora presenti sia i dati sia le informazioni necessarie per interpretarli. Una nuova configurazione rischia di sovrascrivere proprio ciò che serve al recupero.

Prima di estrarre i dischi, annotate la posizione di ciascuno e fate una foto agli alloggiamenti. Sono accorgimenti semplici, ma aiutano chi dovrà ricostruire il sistema, soprattutto se nel tempo sono stati sostituiti o spostati dei dischi.

Conservate tutto, anche le unità guaste, quelle vecchie e quelle che sembrano di troppo. In questo caso, un disco che non faceva più parte degli array custodiva una copia della configurazione più recente. Scartarlo avrebbe significato perdere informazioni utili.

Se volete tentare una ricostruzione con un software, lavorate soltanto su copie dei dischi. È fondamentale, perché anche senza arrivare a un risultato potreste creare problemi maggiori. Negli storage di questo tipo, ricostruire il RAID può essere solo una parte del lavoro: i dati possono esserci, ma risultare ancora illeggibili perché manca la mappa necessaria a ricomporre i volumi.

Sappiamo che in pratica non capita quasi mai, ma avere un backup della configurazione dello storage può cambiare le cose, offrire un riferimento utile e ridurre i tempi di analisi.

Tutti i dischi, anche quelli non utilizzati, possono essere utili.

Se hai uno storage aziendale fermo, trovi come lavoriamo nella pagina sul recupero dati da server e RAID aziendali, oppure chiamaci al numero verde 800 032 302.