{"id":34321,"date":"2019-10-31T21:57:38","date_gmt":"2019-10-31T18:57:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vosstanavlivaem-virtualnye-mashiny-s-oshibochno-initsializirovannogo-datastore-istoriya-odnoj-gluposti-s-heppi-endom\/"},"modified":"2019-10-31T21:57:38","modified_gmt":"2019-10-31T18:57:38","slug":"vosstanavlivaem-virtualnye-mashiny-s-oshibochno-initsializirovannogo-datastore-istoriya-odnoj-gluposti-s-heppi-endom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vosstanavlivaem-virtualnye-mashiny-s-oshibochno-initsializirovannogo-datastore-istoriya-odnoj-gluposti-s-heppi-endom","title":{"rendered":"Ripristino delle macchine virtuali da un Datastore inizializzato erroneamente. La storia di una sciocchezza con un lieto fine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Disclaimer: <\/b>La nota ha un carattere ricreativo. La densit\u00e0 di informazioni utili \u00e8 bassa. \u00c8 stata scritta \"per me stesso\".<\/p><\/blockquote>\n

<\/p>\n

Introduzione lirica<\/h3>\n

\nIl cestino di file nella nostra organizzazione gira su una macchina virtuale VMware ESXi 6 sotto Windows Server 2016. E non \u00e8 solo un cestino. \u00c8 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'\u00e8 tutta la vita produttiva.<\/p>\n

E cos\u00ec 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\u00e8 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 \u2014 due volte a settimana.
\nHo sospettato della memoria RAM. Ma non mi lasciavano fermare il cestino nemmeno nei fine settimana e far girare Memtest. Aspettavamo le festivit\u00e0 di maggio. Durante le festivit\u00e0 di maggio ho fatto girare Memtest e... non sono stati trovati errori.
\n<\/a><\/noindex>
\nSono rimasto incredulo e ho deciso di andare in vacanza. Finch\u00e9 sono stato in vacanza, il cestino non ha avuto un solo blocco. E quando sono tornato al lavoro il luned\u00ec \u2014 il cestino era bloccato. Ha sopportato il backup completo e proprio al termine di questo \u00e8 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.<\/p>\n

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...<\/p>\n

I dischi fisici sono stati spostati su un altro host. Connessione a caldo. Nelle impostazioni dello storage nella scheda Dischi<\/i> appaiono i dischi. Nella scheda Datastores<\/i> i magazzini su questi dischi non ci sono. Aggiorna<\/i> non compaiono. Beh, ovviamente la prima reazione \u00e8 stata \u2014 Aggiungi storage<\/i>. La procedura guidata di aggiunta avverte che \u00e8 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 \u00e8 nemmeno avvicinato al piccolo cerchio giallo con punto esclamativo in basso nella finestra di uno dei passaggi della procedura.<\/p>\n

Al termine della procedura, il nuovo Datastore \u00e8 apparso nell'elenco... e insieme ad esso anche i Datastores degli altri dischi fisici.<\/p>\n

Inizio a navigare nel Datastore appena aggiunto, ma \u00e8... 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\u00e8. E poi succede questo. Il primo pensiero \u00e8 stato: non ho estratto il disco giusto dall'host 'madre'. Ho controllato se il Datastore cercato \u00e8 presente nell'host 'madre': no, non \u00e8 presente. Il secondo pensiero \u00e8 stato: 'cazzo!'. Non ne sono sicuro, ma mi sembra che il terzo, il quarto e almeno il quinto pensiero siano stati simili.<\/p>\n

Per dissipare i dubbi, ho rapidamente installato un nuovo ESXi, ho preso un disco di riserva e, gi\u00e0 leggendo attentamente, ho seguito i passaggi della procedura. S\u00ec. Aggiungendo un Datastore tramite la procedura, si verificano la perdita di tutti i dati sul disco senza possibilit\u00e0 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.<\/p>\n

A partire dal sesto \u2014 i pensieri hanno cominciato a fluire in modo pi\u00f9 costruttivo. Va bene. L'inizializzazione richiede pochi secondi anche per un disco da 3Tb. Quindi, \u00e8 un'operazione di formattazione ad alto livello. Quindi, \u00e8 stata semplicemente riscritta la tabella delle partizioni. Quindi, i dati sono ancora l\u00ec. Quindi, ora cercheremo qualche unformat e voil\u00e0.<\/p>\n

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.<\/p>\n

La selezione dei programmi non \u00e8 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.<\/p>\n

E qui capisco che, sembra proprio, che adesso dovr\u00f2 installare Windows e ripristinare da un backup. E allo stesso tempo ricordo che avevo una radice DFS. E inoltre c'\u00e8 un sistema di diritti di accesso alle cartelle delle divisioni completamente selvaggio per volume e complessit\u00e0. Non \u00e8 un'opzione. L'unica opzione accettabile in termini di tempo \u00e8 il ripristino dello stato del sistema e del disco con i dati e tutti i diritti.<\/p>\n

Ancora ricerca su Google, forum, KB e ancora il lamento di Iaroslavna: VMware ESXi non prevede un meccanismo di recupero dei dati. Tutte le discussioni hanno due finali: qualcuno \u00e8 riuscito a recuperare con l'aiuto del costoso DiskInternals VMFS Recovery o qualcuno ha ricevuto assistenza da un esperto che promuove attivamente i suoi servizi. vmfs-tools<\/i> e dd<\/i>. L'opzione di acquistare una licenza di DiskInternals VMFS Recovery per $700 \u2014 non \u00e8 un'opzione. Permettere a una persona estranea con \"territorio di un potenziale avversario\" di accedere ai dati aziendali \u2014 anch'essa non \u00e8 un'opzione. Tuttavia, ho trovato su Google che i partizioni VMFS possono essere letti anche da UFS Explorer.<\/p>\n

DiskInternals VMFS Recovery<\/h3>\n

\n\u00c8 stata scaricata e installata una versione di prova. Il programma ha rilevato con successo la partizione VMFS vuota:<\/p>\n

\"Ripristino
\n
\nIn modalit\u00e0 Undelete (Fast Scan)<\/i> ha trovato anche il Datastore danneggiato con le cartelle macchine virtuali<\/a> con i dischi all'interno:<\/p>\n

\"Ripristino
\n
\nL'anteprima ha mostrato che i file erano integri:<\/p>\n

\"Ripristino
\n
\nIl montaggio della partizione nel sistema \u00e8 stato un successo, ma per motivi sconosciuti in tutte e tre le cartelle c'era la stessa macchina virtuale. Naturalmente, per legge di Murphy \u2014 non quella richiesta.<\/p>\n

Tre righe di vergogna<\/b>Il tentativo di piratare spudoratamente il software \u00e8 fallito. Eppure, UFS Explorer \u00e8 riuscito a piratarsi.<\/p>\n

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. \n<\/p><\/blockquote>\n

\nEro in una situazione catastrofica e non ero affatto orgoglioso delle misure a cui avevo ricorso.<\/p>\n

UFS Explorer<\/h3>\n

\nLa scansione del disco ha mostrato la presenza di 7 nodi. Il numero di nodi si \u00e8 \"sorprendentemente\" coinciso con il numero di file *-flat.vmdk trovati da VMFS Recovery:<\/p>\n

\"Ripristino
\n
\nIl 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.<\/p>\n

\"Ripristino
\n
\nIn 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\u00e0 come un file disco valido. Nella base di conoscenza di VMware c'\u00e8 un articolo su come creare manualmente un file descrittore del disco: kb.vmware.com\/s\/article\/1002511<\/a><\/noindex>, 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:<\/p>\n

\"Ripristino
\n
\nDopo 4 ore di scarico di 2,5 TB di nodi da UFS Explorer e 20 ore di caricamento nel Datastore dell'iper-vizor, i file danneggiati dei dischi sono stati collegati a una macchina virtuale appena creata. I dischi sono stati riconosciuti. Non si sono riscontrate perdite di dati.<\/p>\n

\"Ripristino
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

Disclaimer: \u0417\u0430\u043c\u0435\u0442\u043a\u0430 \u043d\u043e\u0441\u0438\u0442 \u0440\u0430\u0437\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440. \u0423\u0434\u0435\u043b\u044c\u043d\u0430\u044f \u043f\u043b\u043e\u0442\u043d\u043e\u0441\u0442\u044c \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u043d\u0435\u0439 \u043c\u0430\u043b\u0430. \u0411\u044b\u043b\u0430 \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0430 \u00ab\u0434\u043b\u044f \u0441\u0435\u0431\u044f\u00bb. \u041b\u0438\u0440\u0438\u0447\u0435\u0441\u043a\u043e\u0435 \u0432\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u0435 \u0424\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u043f\u043e\u043c\u043e\u0439\u043a\u0430 \u0432 \u043d\u0430\u0448\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u043a\u0440\u0443\u0442\u0438\u0442\u0441\u044f \u043d\u0430 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u0435 VMware ESXi 6 \u043f\u043e\u0434 Windows Server 2016. \u0418 \u044d\u0442\u043e \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u043c\u043e\u0439\u043a\u0430. \u042d\u0442\u043e \u0441\u0435\u0440\u0432\u0435\u0440 \u0444\u0430\u0439\u043b\u043e\u0432\u043e\u0433\u043e \u043e\u0431\u043c\u0435\u043d\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043d\u044b\u043c\u0438 \u043f\u043e\u0434\u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u0438\u044f\u043c\u0438: \u0442\u0443\u0442 \u0438 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u0430\u044f \u0440\u0430\u0431\u043e\u0442\u0430, \u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u043d\u0430\u044f \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u044f, \u0438 \u043f\u0430\u043f\u043a\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25881,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34321","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ripristiniamo macchine virtuali da un Datastore inizializzato in modo errato. Storia di una sciocchezza con un lieto fine | ProHoster","description":"Disclaimer: Questa nota ha carattere ricreativo. La densit\u00e0 di informazioni utili al suo interno \u00e8 bassa.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vosstanavlivaem-virtualnye-mashiny-s-oshibochno-initsializirovannogo-datastore-istoriya-odnoj-gluposti-s-heppi-endom","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u043e\u0441\u0441\u0442\u0430\u043d\u0430\u0432\u043b\u0438\u0432\u0430\u0435\u043c \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0435 \u043c\u0430\u0448\u0438\u043d\u044b \u0441 \u043e\u0448\u0438\u0431\u043e\u0447\u043d\u043e \u0438\u043d\u0438\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e Datastore. \u0418\u0441\u0442\u043e\u0440\u0438\u044f \u043e\u0434\u043d\u043e\u0439 \u0433\u043b\u0443\u043f\u043e\u0441\u0442\u0438 \u0441 \u0445\u044d\u043f\u043f\u0438-\u044d\u043d\u0434\u043e\u043c | ProHoster","og:description":"Disclaimer: \u0417\u0430\u043c\u0435\u0442\u043a\u0430 \u043d\u043e\u0441\u0438\u0442 \u0440\u0430\u0437\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440. \u0423\u0434\u0435\u043b\u044c\u043d\u0430\u044f \u043f\u043b\u043e\u0442\u043d\u043e\u0441\u0442\u044c \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u043d\u0435\u0439 \u043c\u0430\u043b\u0430.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vosstanavlivaem-virtualnye-mashiny-s-oshibochno-initsializirovannogo-datastore-istoriya-odnoj-gluposti-s-heppi-endom","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:57:38+00:00","article:modified_time":"2019-10-31T18:57:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34321","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:15:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:24:25","updated":"2026-02-09 17:15:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=34321"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34321\/revisions"}],"predecessor-version":[{"id":159242,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34321\/revisions\/159242"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25881"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}