Disclaimer: Questo appunto ha un carattere ricreativo. La densità di informazioni utili in esso è bassa. È stato scritto "per me stesso".
Introduzione lirica
Il deposito di file nella nostra organizzazione gira su una macchina virtuale VMware ESXi 6 con Windows Server 2016. E non è solo un deposito. È un server di condivisione file tra le diverse unità: qui ci sono collaborazioni, documentazione di progetto e cartelle da scanner di rete. Insomma, qui si svolge tutta la vita produttiva.
Ecco, questo contenitore di tutta la vita produttiva ha cominciato a bloccarsi. E il guest poteva bloccarsi da solo, senza coinvolgere gli altri. Poteva bloccare l'intero host e, di conseguenza, tutte le altre macchine guest. Poteva bloccarsi e influenzare i servizi client di vSphere: cioè, i processi delle altre macchine erano attivi, le macchine funzionavano correttamente e rispondevano, ma la cartella di file non rispondeva e il client vSphere non riusciva a connettersi all'host. In generale, non siamo riusciti a identificare alcun sistema. I blocchi potevano verificarsi durante il giorno con un carico leggero. Potevano accadere di notte durante un carico zero. Potevano verificarsi di notte durante un backup differenziale e un carico medio. Potevano accadere nei fine settimana durante un backup completo e un carico elevato. Si è osservato un evidente deterioramento della situazione. All'inizio, accadeva una volta all'anno, poi una volta ogni sei mesi. Verso la fine della mia pazienza, due volte a settimana.
Ho sospettato della RAM. Ma non mi è stato permesso di fermare il sistema nemmeno nei fine settimana e di eseguire Memtest. Stavamo aspettando le festività di maggio. Durante le festività di maggio ho eseguito Memtest e... non sono stati trovati errori.
Sono rimasto stupito e ho deciso di prendere una pausa. Mentre ero in ferie, il server non ha mai avuto un blocco. Ma quando sono tornato al lavoro il lunedì, il server era bloccato. Ha sopportato un backup completo e proprio al termine si è bloccato. Questa calda accoglienza al ritorno dalle ferie mi ha spinto a trasferire fisicamente i dischi della macchina virtuale su un altro host.
E, sebbene sia ben noto che il primo giorno dopo le ferie non si dovrebbe fare nulla di serio, mentre mi preparavo a non lavorare durante il tragitto per l'ufficio, la mia indignazione per l'ennesimo blocco mi ha fatto dimenticare sia la mia preparazione che i miei propositi…
I dischi fisici sono stati trasferiti su un altro host. Collegamento a caldo. Nelle impostazioni dello storage, nella scheda Dischi appare il disco. Nella scheda Datastores non ci sono storage su questi dischi. Aggiorna non appaiono. E, naturalmente, il primo impulso è stato — Aggiungi Storage. La procedura guidata per l'aggiunta mi informa che supporta sicuramente anche VMFS. Non avevo dubbi. Una rapida panoramica dei messaggi della procedura: Avanti, Avanti, Avanti, Fine. Lo sguardo nemmeno si è posato sul piccolo cerchio giallo con il punto esclamativo in basso nella finestra di uno dei passaggi della procedura.
Al termine della procedura, il nuovo Datastore è apparso nell'elenco... e così anche i Datastore degli altri dischi fisici.
Vado a navigare nel nuovo Datastore aggiunto, e lui... è vuoto. Naturalmente, sono rimasto di nuovo stupito. Sono le 8 del mattino, i primi 15 minuti di lavoro dopo le ferie, non ho nemmeno mescolato lo zucchero nel caffè. Eppure succede questo. La prima idea è stata: non ho estratto il disco giusto dall'host 'nativo'. Ho controllato se il Datastore cercato fosse presente nell'host 'nativo': no, non c'era. La seconda idea è stata: 'Cazzo!'. Non sono sicuro, ma penso che il terzo, il quarto e almeno il quinto pensiero siano stati simili.
Per dissipare i dubbi, ho rapidamente installato una nuova versione di ESXi su un disco di prova e, mentre leggevo, ho seguito i passi della procedura guidata. Sì. Aggiungendo un Datastore tramite la procedura guidata, si perde tutti i dati sul disco senza possibilità di annullare l'operazione o recuperare i dati. Più tardi ho letto su un forum una valutazione di questo design della procedura: shitsome crap. E ci ho molto concordato.
Dalla sesta in poi, i pensieri sono diventati più costruttivi. Va bene. L'inizializzazione richiede solo pochi secondi anche per un disco da 3Tb. Quindi, si tratta di un formato di alto livello. Questo significa che è stata semplicemente riscritta la tabella delle partizioni. Questo significa che i dati sono ancora lì. Ora cerchiamo un qualche software di unformat e voilà.
Sto avviando la macchina dall'immagine di avvio di Strelec… E scopro che i programmi di recupero delle partizioni conoscono tutto, tranne VMFS. Conoscono, ad esempio, la partizione di Synology, ma VMFS no.
La selezione dei programmi non è confortante: nel migliore dei casi, GetDataBack e R.Saver trovano partizioni NTFS con una struttura di directory intatta e nomi di file attivi. Ma non mi accontento. Ho bisogno di due file vmdk: uno con il disco di sistema e l'altro con il disco di file spazzatura.
E qui capisco che dovrò probabilmente installare Windows e ripristinare da un backup file. Allo stesso tempo, mi ricordo che avevo un root DFS lì. E anche un sistema di autorizzazioni per le cartelle dei reparti completamente assurdo per dimensioni e ramificazione. Non è un'opzione. L'unica opzione accettabile in termini di tempo è il ripristino dello stato del sistema e del disco con i dati e tutti i diritti.
Ancora ricerche su Google, forum, KB e ancora una volta il lamento di Giacobbe: VMware ESXi non prevede un meccanismo di recupero dei dati. Tutte le discussioni hanno due finali: qualcuno si è ripristinato usando il costoso DiskInternals VMFS Recovery oppure qualcuno ha trovato aiuto da uno specialista che promuove attivamente i suoi servizi. vmfs-tools e dd. L'opzione di acquistare una licenza DiskInternals VMFS Recovery per $700 non è valida. Consentire a un estraneo proveniente da 'territori potenzialmente ostili' di accedere ai dati aziendali non è un'opzione. Tuttavia, è stato scoperto che UFS Explorer è in grado di leggere le partizioni VMFS.
DiskInternals VMFS Recovery
È stata scaricata e installata la versione trial. Il programma ha rilevato con successo la partizione VMFS vuota:
In modalità Undelete (Fast Scan) ha anche trovato e un Datastore danneggiato con cartelle di macchine virtuali con i dischi all'interno:
L'anteprima ha mostrato che i file sono attivi:
Il montaggio della partizione nel sistema è andato a buon fine, ma per motivi non chiari in tutte e tre le cartelle c'era la stessa macchina virtuale. Ovviamente, per legge di Murphy — non quella richiesta.
Tre righe di vergognaIl tentativo di pirateare disperatamente il software è finito in un fallimento. Tuttavia, si è piratato UFS Explorer.
Sono estremamente contrario al furto di software. In nessun caso incoraggio l'uso di mezzi per aggirare le protezioni contro l'uso non autorizzato.
Ero in una situazione disastrosa e non ero affatto orgoglioso delle misure a cui sono ricorso.
UFS Explorer
La scansione del disco ha rivelato la presenza di 7 nodi. Il numero di nodi corrisponde 'incredibilmente' al numero di file *-flat.vmdk trovati in VMFS Recovery:
Il confronto delle dimensioni dei file e delle dimensioni dei nodi ha mostrato una corrispondenza fino al byte. Sono stati inoltre ripristinati i nomi dei file *-flat.vmdk e, di conseguenza, la loro appartenenza alle macchine virtuali.
In generale, i dischi vmdk in termini di ESXi consistono in due file: un file con i dati (-flat.vmdk) e un file di 'mappatura fisica' del disco (.vmdk). Se si carica il file *-flat.vmdk dal computer locale nel Datastore, ESXi non lo riconoscerà come un file di disco valido. Nella base di conoscenza di VMware è presente un articolo su come creare manualmente un file descrittore del disco: , ma non ho dovuto farlo, ho semplicemente copiato e incollato il contenuto dei file corrispondenti dall'area di anteprima del file in DiskInternals VMFS Recovery:
Dopo 4 ore di esportazione di 2,5 TB di nodo da UFS Explorer e 20 ore di caricamento nel Datastore, i file di disco danneggiati sono stati collegati a una nuova macchina virtuale appena creata. I dischi sono stati riconosciuti. Non sono stati riscontrati perdite di dati.
Fonte: habr.com
