Disclaimer: La nota è a scopo di intrattenimento. La densità specifica di informazioni utili in esso contenute è bassa. È stato scritto "per me stesso".
Introduzione lirica
Il dump del file nella nostra organizzazione viene eseguito su una macchina virtuale VMware ESXi 6 che esegue Windows Server 2016. E non si tratta solo di un dump della spazzatura. Questo è un server di scambio file tra divisioni strutturali: c'è collaborazione, documentazione di progetto e cartelle da scanner di rete. In generale, tutta la vita produttiva è qui.
E questo contenitore di tutta la vita produttiva cominciò a bloccarsi. Inoltre, l'ospite poteva tranquillamente impiccarsi senza danneggiare gli altri. Potrebbe disattivare l'intero host e, di conseguenza, tutte le altre macchine ospiti. Potrei impiccarmi e bloccare i servizi del vSphere client: cioè i processi degli altri guest sono vivi, le macchine funzionano bene e rispondono, ma non c'è il filewasher e il vSphere Client non si aggrappa all'host. In generale non è stato possibile identificare alcun sistema. Potrebbero verificarsi gelate durante il giorno durante un carico basso. Potrebbero farlo di notte senza carico. Potrebbe di notte durante il backup differenziale e il carico medio. Potrebbe nei fine settimana durante backup completi e carico elevato. E c'è stato un chiaro degrado della situazione. All'inizio era una volta all'anno, poi una volta ogni sei mesi. Al limite della mia pazienza, due volte a settimana.
Ho avuto un problema di memoria. Ma non mi hanno permesso di fermare il mucchio di spazzatura nemmeno nei fine settimana e di eseguire Memtest. Aspettavamo le vacanze di maggio. Durante le vacanze di maggio ho eseguito Memtest e... non sono stati trovati errori.
Sono rimasto stupito e ho deciso di andare in vacanza. Mentre ero in vacanza, non c'è stato un solo riaggancio alla discarica. E quando lunedì sono tornato al lavoro per il primo giorno, c'era un mucchio di spazzatura. Ho subito un backup completo e ho bloccato subito dopo averlo completato. Un così caloroso benvenuto dalle vacanze mi ha spinto alla decisione di trascinare fisicamente i dischi con la macchina ospite su un altro host.
E, sebbene sia risaputo da tempo che non si può fare nulla di serio il primo giorno dopo le vacanze, sebbene mi stessi preparando a non lavorare fino al lavoro, la mia indignazione per l'ennesimo congelamento ha messo a dura prova sia il mio umore che la mia promesse fuori di testa...
I dischi fisici sono stati spostati su un altro host. Connessione calda. Nelle impostazioni di archiviazione nella scheda Unità appaiono i dischi. Sulla scheda Datastore Non c'è spazio di archiviazione su questi dischi. ricaricare - non appaiono. Beh, ovviamente, il primo impulso... Aggiungi memoria. L'Aggiunta guidata spiega cosa supporta. Naturalmente supporta anche VMFS. Non ne avevo dubbi. Un rapido sguardo ai messaggi della procedura guidata in ogni passaggio: Avanti, Avanti, Avanti, Fine. L’occhio non si è nemmeno avvicinato a cogliere il cerchietto giallo con il punto esclamativo in fondo alla finestra di uno dei gradini del maestro.
Al termine della procedura guidata, nell'elenco è apparso il nuovo Datastore... e insieme ad esso i Datastore dei rimanenti dischi fisici.
Passo alla navigazione nel Datastore appena aggiunto ed è... vuoto. Naturalmente, sono ricaduto nello stupore. Sono le 8 del mattino, i primi 15 minuti di lavoro dopo le vacanze, non ho ancora nemmeno mescolato lo zucchero nel caffè. Ed eccolo qui. Il primo pensiero è stato che avessi estratto il disco sbagliato dall'host "nativo". Ho guardato se il Datastore richiesto era presente nell'host “nativo”: no, non era presente. Il secondo pensiero è stato: “cazzo!” Non ne sono sicuro, ma mi sembra che il terzo, il quarto e almeno il quinto pensiero fossero lo stesso.
Per dissipare i dubbi, ho installato rapidamente un nuovo ESXi per il test, ho preso il disco sinistro e, già leggendolo, ho seguito i passaggi della procedura guidata. SÌ. Quando aggiungi un archivio dati utilizzando la procedura guidata, tutti i dati sul disco vengono persi senza la possibilità di eseguire il rollback dell'operazione e ripristinare i dati. Più tardi ho letto su uno dei forum una valutazione di questo progetto da parte di un maestro: una schifezza. E ho davvero accettato.
A partire dal sesto, i pensieri fluirono in una direzione più costruttiva. OK. L'inizializzazione richiede pochi secondi anche per un disco da 3 TB. Quindi questa è una formattazione di alto livello. Ciò significa che la tabella delle partizioni è stata semplicemente riscritta. Quindi i dati sono ancora lì. Quindi, ora cercheremo un formato unformat e voilà.
Avvio la macchina dall'immagine di avvio di Strelec... E scopro che i programmi di ripristino delle partizioni sanno tutto tranne VMFS. Ad esempio, conoscono il layout della partizione di Synology, ma non VMFS.
La ricerca tra i programmi non è rassicurante: nella migliore delle ipotesi, GetDataBack e R.Saver trovano partizioni NTFS con una struttura di directory live e nomi di file live. Ma questo non mi va bene. Ho bisogno di due file vmdk: con il disco di sistema e il disco dei file spazzatura.
E poi capisco che sembra che ora installerò Windows e lo eseguirò da un backup di file. E allo stesso tempo ricordo che lì avevo una radice DFS. E anche un sistema di diritti di accesso alle cartelle del dipartimento di portata e ramificazioni assolutamente selvaggi. Non è un'opzione. L'unica opzione accettabile in termini di tempo è ripristinare lo stato del sistema e del disco con i dati e tutti i diritti.
Ancora una volta Google, i forum, KB'shki e ancora il grido di Yaroslavna: VMware ESXi non fornisce un meccanismo di ripristino dei dati. Tutti i thread di discussione hanno due finali: qualcuno è stato recuperato utilizzando il costoso DiskInternals VMFS Recovery o qualcuno è stato aiutato da uno specialista di software che promuove attivamente i suoi servizi strumenti vmfs и dd. L'opzione di acquistare una licenza DiskInternals VMFS Recovery per $ 700 non è un'opzione. Anche consentire a un estraneo proveniente dal “territorio di un potenziale nemico” di accedere ai dati aziendali non è un’opzione. Ma è stato cercato su Google che le partizioni VMFS possono essere lette anche da UFS Explorer.
Ripristino di DiskInternals VMFS
La versione di prova è stata scaricata e installata. Il programma ha rilevato con successo la partizione VMFS vuota:
la modalità Annulla eliminazione (scansione veloce) Ho trovato anche uno squallido Datastore con cartelle di macchine virtuali con dischi all'interno:
L'anteprima ha mostrato che i file sono vivi:
Il montaggio della partizione nel sistema è riuscito, ma per qualche motivo sconosciuto tutte e tre le cartelle contenevano la stessa macchina virtuale. Naturalmente, secondo la legge, la meschinità non è ciò che è richiesto.
Tre righe di vergognaIl tentativo di bloccare spudoratamente il software si è concluso con un fallimento. Ma UFS Explorer si è bloccato.
Ho un atteggiamento estremamente negativo nei confronti del furto di software. Non incoraggio in alcun modo l'uso di mezzi per aggirare la protezione contro l'uso senza licenza.
Mi trovavo in una situazione catastrofica e non ero affatto orgoglioso delle misure a cui avevo fatto ricorso.
Esploratore UFS
Una scansione del disco ha mostrato la presenza di 7 nodi. Il numero di nodi "sorprendentemente" coincideva con il numero di file *-flat.vmdk rilevati da VMFS Recovery:
Anche un confronto tra le dimensioni dei file e le dimensioni dei nodi ha mostrato una corrispondenza fino al byte. Allo stesso tempo, 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 ESXi sono costituiti da due file: un file di dati (<nome macchina>-flat.vmdk) e un file di layout del disco “fisico” (<nome macchina>.vmdk). Se carichi un file *-flat.vmdk nel Datastore da un computer locale, ESXi non lo riconoscerà come un file disco valido. La Knowledge Base VMware contiene un articolo su come creare manualmente un file descrittore del disco: , ma non ho dovuto farlo, ho semplicemente copiato il contenuto dei file corrispondenti dall'area di anteprima del contenuto del file in DiskInternals VMFS Recovery:
Dopo 4 ore di scarico di un nodo da 2,5 TB da UFS Explorer e 20 ore di caricamento nel Datastore dell'hypervisor, i file del disco in crash sono stati collegati alla macchina virtuale appena creata. I dischi si sollevarono. Non è stata osservata alcuna perdita di dati.
Fonte: habr.com