Lo Scenario
Un service managed provider con sede in Corea ha tentato di apportare modifiche alla configurazione del sistema NetApp del proprio cliente quando un ingegnere ha avviato erroneamente un comando "dd" su alcune LUN, cancellando i dati che facevano parte del server Sybase di produzione dell'utente finale
Senza accesso ai dati, il provider rischiava di dover sostenere potenziali costi e penali con il cliente.
Il cliente aveva un sistema NetApp FAS8060 contenente 161 dischi rigidi SAS da 900 GB, organizzati in due aggregati separati (68 unità + 93 unità). Il cliente presentava 3 LUN FC da 468 GB ciascuna aggregata a un server Sybase.
Le 6 LUN sono state combinate in un unico pool di dischi, con tre volumi logici ricavati dal pool. Un comando "dd" errato aveva scritto zeri su circa 45 GB di uno dei volumi logici e questo volume non era più visibile al server Sybase.
La Soluzione
Durante la fase di valutazione, il nostro ingegnere ha incaricato il cliente di portare gli aggregati offline per evitare ulteriori danni da sovrascrittura. Gli aggregati sono stati portati offline dopo 12 ore da quando si è verificato l'evento di perdita di dati.
Il cliente ha presentato tutti i 161 HDD da entrambi gli aggregati a una singola macchina Windows e l'ha collegata al server RDR (Remote Data Recovery) di Ontrack. L'ispezione iniziale ha mostrato che entrambi gli aggregati erano denominati "aggrO", il che ha impedito al nostro ingegnere di ricostruire automaticamente l'aggregato.
Le unità sono state ordinate in gruppi aggregati e gli aggregati sono stati ricostruiti manualmente. I nostri ingegneri sono stati quindi in grado di ricostruire gli aggregati.
Il Risultato
Il nostro ingegnere non è stato in grado di estrarre o esaminare i dati interni perché i volumi logici sono stati utilizzati come archivio RAW dal server Sybase. Tutte e sei le LUN sono state quindi estratte come file flat nella memoria esterna. Il supporto NetApp è stato in grado di assistere nella presentazione delle LUN al server Sybase. I volumi logici ripristinati hanno superato i controlli di integrità sul server Sybase e il cliente ha confermato che tutto funzionava correttamente. Il server del database dell'utente finale è stato in grado di essere riportato in linea entro pochi giorni dall'errore senza perdita di dati.