Disclaimer: La nota ha un carattere ricreativo. La densità di informazioni utili è bassa. È stata scritta "per me stesso".
Introduzione lirica
Il cestino di file nella nostra organizzazione gira su una macchina virtuale VMware ESXi 6 sotto Windows Server 2016. E non è solo un cestino. È un server di scambio file tra le varie strutture: qui ci sono collaborazioni, documentazione di progetto e cartelle con scanner di rete. In sintesi, qui c'è tutta la vita produttiva.
E così questo contenitore di tutta la vita produttiva ha cominciato a bloccarsi. E il guest poteva bloccarsi silenziosamente, senza coinvolgere gli altri. Poteva bloccare l'intero host e, di conseguenza, tutte le altre macchine virtuali. Poteva bloccarsi da solo e interrompere i servizi client di vSphere: cioè i processi degli altri guest erano vivi, le macchine funzionavano correttamente e rispondevano, ma il cestino di file no e il vSphere Client non si collegava all'host. Insomma, non si riusciva a identificare alcun sistema. I blocchi potevano verificarsi di giorno durante carichi di lavoro leggeri. Potevano avvenire di notte durante carichi di lavoro nulli. Potevano avvenire di notte durante backup differenziali e carichi di lavoro medi. Potevano verificarsi nei fine settimana durante backup completi e carichi di lavoro elevati. E si osservava un evidente deterioramento della situazione. All'inizio succedeva una volta all'anno, poi una volta ogni sei mesi. Alla fine della mia pazienza — due volte a settimana.
Ho sospettato della memoria RAM. Ma non mi lasciavano fermare il cestino nemmeno nei fine settimana e far girare Memtest. Aspettavamo le festività di maggio. Durante le festività di maggio ho fatto girare Memtest e... non sono stati trovati errori.
Sono rimasto incredulo e ho deciso di andare in vacanza. Finché sono stato in vacanza, il cestino non ha avuto un solo blocco. E quando sono tornato al lavoro il lunedì — il cestino era bloccato. Ha sopportato il backup completo e proprio al termine di questo è andato in crash. Questo caloroso rientro dalle ferie mi ha spinto a decidere di spostare fisicamente i dischi della macchina virtuale su un altro host.
E, sebbene sia noto da tempo che il primo giorno dopo le ferie non si dovrebbe fare nulla di serio, anche se durante il viaggio al lavoro mi sono preparato a non lavorare, il mio sdegno per un altro blocco ha distratto la mia mente e il mio proposito...
I dischi fisici sono stati spostati su un altro host. Connessione a caldo. Nelle impostazioni dello storage nella scheda Dischi appaiono i dischi. Nella scheda Datastores i magazzini su questi dischi non ci sono. Aggiorna non compaiono. Beh, ovviamente la prima reazione è stata — Aggiungi storage. La procedura guidata di aggiunta avverte che è supportata. Certo che supporta anche VMFS. Non avevo dubbi. Una rapida occhiata ai messaggi della procedura ad ogni passaggio: Avanti, Avanti, Avanti, Fine. Lo sguardo non si è nemmeno avvicinato al piccolo cerchio giallo con punto esclamativo in basso nella finestra di uno dei passaggi della procedura.
Al termine della procedura, il nuovo Datastore è apparso nell'elenco... e insieme ad esso anche i Datastores degli altri dischi fisici.
Inizio a navigare nel Datastore appena aggiunto, ma è... vuoto. Ovviamente, sono di nuovo rimasto di stucco. Sono le 8 del mattino, sono i primi 15 minuti di lavoro dopo le ferie, non ho nemmeno mescolato lo zucchero nel caffè. E poi succede questo. Il primo pensiero è stato: non ho estratto il disco giusto dall'host 'madre'. Ho controllato se il Datastore cercato è presente nell'host 'madre': no, non è presente. Il secondo pensiero è stato: 'cazzo!'. Non ne sono sicuro, ma mi sembra che il terzo, il quarto e almeno il quinto pensiero siano stati simili.
Per dissipare i dubbi, ho rapidamente installato un nuovo ESXi, ho preso un disco di riserva e, già leggendo attentamente, ho seguito i passaggi della procedura. Sì. Aggiungendo un Datastore tramite la procedura, si verificano la perdita di tutti i dati sul disco senza possibilità di ripristinare l'operazione e i dati. In seguito ho letto su uno dei forum una valutazione di questo design della procedura: schifezze. E sono stato molto d'accordo.
A partire dal sesto — i pensieri hanno cominciato a fluire in modo più costruttivo. Va bene. L'inizializzazione richiede pochi secondi anche per un disco da 3Tb. Quindi, è un'operazione di formattazione ad alto livello. Quindi, è stata semplicemente riscritta la tabella delle partizioni. Quindi, i dati sono ancora lì. Quindi, ora cercheremo qualche unformat e voilà.
Avvio la macchina dall'immagine di avvio di Strelec... E scopro che i programmi di recupero delle partizioni conoscono tutto, tranne VMFS. Conoscono, ad esempio, il layout delle partizioni di Synology, ma non VMFS.
La selezione dei programmi non è rassicurante: nel migliore dei casi, GetDataBack e R.Saver trovano partizioni NTFS con una struttura di directory viva e nomi di file attivi. Ma questo non mi basta. Ho bisogno di due file vmdk: uno con il disco di sistema e uno con il disco dei file spazzatura.
E qui capisco che, sembra proprio, che adesso dovrò installare Windows e ripristinare da un backup. E allo stesso tempo ricordo che avevo una radice DFS. E inoltre c'è un sistema di diritti di accesso alle cartelle delle divisioni completamente selvaggio per volume e complessità. 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.
Di nuovo ricerche su Google, forum, KB e di nuovo il lamento di Iara: VMware ESXi non prevede un meccanismo per il ripristino dei dati. Tutte le discussioni hanno due finali: qualcuno si è ripristinato con l'aiuto del costoso DiskInternals VMFS Recovery o qualcuno ha ricevuto assistenza da uno specialista che promuove attivamente i suoi servizi. vmfs-tools e dd. L'opzione di acquistare una licenza di DiskInternals VMFS Recovery per $700 — non è un'opzione. Permettere a una persona estranea con "territorio di un potenziale avversario" di accedere ai dati aziendali — anch'essa non è un'opzione. Tuttavia, ho trovato su Google che i partizioni VMFS possono essere letti anche da UFS Explorer.
DiskInternals VMFS Recovery
È stata scaricata e installata una versione di prova. Il programma ha rilevato con successo la partizione VMFS vuota:
In modalità Undelete (Fast Scan) ha trovato anche il Datastore danneggiato con le cartelle macchine virtuali con i dischi all'interno:
L'anteprima ha mostrato che i file erano integri:
Il montaggio della partizione nel sistema è stato un successo, ma per motivi sconosciuti in tutte e tre le cartelle c'era la stessa macchina virtuale. Naturalmente, per legge di Murphy — non quella richiesta.
Tre righe di vergognaIl tentativo di piratare spudoratamente il software è fallito. Eppure, UFS Explorer è riuscito a piratarsi.
Sono estremamente contrario al furto di software. In nessun modo incoraggio l'uso di mezzi per eludere i meccanismi di protezione contro l'uso non autorizzato.
Ero in una situazione catastrofica e non ero affatto orgoglioso delle misure a cui avevo ricorso.
UFS Explorer
La scansione del disco ha mostrato la presenza di 7 nodi. Il numero di nodi si è "sorprendentemente" coinciso con il numero di file *-flat.vmdk trovati da VMFS Recovery:
Il confronto delle dimensioni dei file e delle dimensioni dei nodi ha mostrato anche una corrispondenza fino all'ultimo byte. Nel frattempo sono stati ripristinati i nomi dei file *-flat.vmdk e, di conseguenza, la loro appartenenza alle macchine virtuali.
In generale, i dischi vmdk, dal punto di vista di ESXi, consistono in due file: un file con i dati (-flat.vmdk) e un file di 'partizionamento fisico' del disco (.vmdk). Se carichi il file *-flat.vmdk dal computer locale nel Datastore, ESXi non lo riconoscerà come un file disco valido. Nella base di conoscenza di VMware c'è un articolo su come creare manualmente un file descrittore del disco: , ma non ho dovuto farlo, ho semplicemente copiato e incollato il contenuto dei relativi file dall'anteprima del contenuto del file in DiskInternals VMFS Recovery:
Dopo 4 ore di estrazione di 2,5 TB di nodi da UFS Explorer e 20 ore di caricamento nel Datastore, i file disco danneggiati sono stati collegati a una macchina virtuale appena creata. I dischi sono stati riconosciuti. Non sono stati riscontrati perdite di dati.
Fonte: habr.com
