{"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\/nl\/blog\/administrirovanie\/vosstanavlivaem-virtualnye-mashiny-s-oshibochno-initsializirovannogo-datastore-istoriya-odnoj-gluposti-s-heppi-endom","title":{"rendered":"Restoring virtual machines from incorrectly initialized Datastore. The story of a mistake with a happy ending","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Disclaimer: <\/b>Dit aantekening heeft een vermakelijk karakter. De informatie-dichtheid is laag. Het was geschreven \"voor mezelf\".<\/p><\/blockquote>\n

<\/p>\n

Lyrische inleiding<\/h3>\n

\nDe bestandcontainer in onze organisatie draait op een virtuele machine VMware ESXi 6 onder Windows Server 2016. En dit is niet zomaar een container. Dit is een server voor bestandsoverdracht tussen de afdelingen: hier vindt gezamenlijke samenwerking plaats, projectdocumentatie, en mappen van netwerkscanners. Kortom, hier bevindt zich het hele productieproces.<\/p>\n

En dit vat van het hele productieproces begon vast te lopen. Bovendien kon een gast stilletjes vastlopen zonder de anderen te be\u00efnvloeden. Hij kon het hele host vastzetten en, bijgevolg, alle andere gastmachines. Hij kon zichzelf vastzetten en de klantenservices van vSphere platleggen: dat wil zeggen, de processen van de andere gasten waren levend, de machines werkten correct en reageerden, maar de bestandscontainer niet en de vSphere Client kon de host niet bereiken. Kortom, er was geen systeem te detecteren. Vastlopers konden zich overdag voordoen tijdens een lage belasting. Ze konden 's nachts optreden bij nul belasting. Ze konden 's nachts optreden tijdens een incrementele back-up en gemiddelde belasting. Ze konden in het weekend tijdens een volledige back-up en hoge belasting voorkomen. En er was een duidelijke verslechtering van de situatie zichtbaar. In het begin was het eens per jaar, daarna eens per half jaar. Tegen het einde van mijn geduld - tweemaal per week.
\nIk gaf de schuld aan het RAM-geheugen. Maar ik kon de container zelfs in het weekend niet stopzetten en Memtest draaien. We wachtten op de meivakanties. Tijdens de meivakanties heb ik Memtest gedraaid en... er werden geen fouten gevonden.
\n<\/a><\/noindex>
\nIk viel in verbazing en besloot op vakantie te gaan. Terwijl ik op vakantie was, was er geen enkele vastloper bij de container. En toen ik op maandag weer aan het werk ging - stond de container vast. Hij overleefde de volledige back-up en net na het be\u00ebindigen ervan viel hij stil. Zo'n warme terugkeer van vakantie duwde me naar de beslissing om de schijven van de gastmachine fysiek naar een andere host te verplaatsen.<\/p>\n

En, hoewel het al lang bekend is dat je op de eerste dag na je vakantie niets ernstigs moet doen, hoewel ik mezelf elke reis naar het werk had ingesteld om niet te werken, maakte mijn verontwaardiging over de volgende vastloper me het hoofd en de instelling en de beloften vergeten...<\/p>\n

De fysieke schijven werden in een andere host geplaatst. Hot swap. In de opslaginstellingen op het tabblad Schijven<\/i> de schijven verschijnen. Op het tabblad Datastores<\/i> zijn er geen opslagplaatsen op deze schijven. Vernieuwen<\/i> \u2014 verschijnen niet. En natuurlijk is mijn eerste reactie \u2014 Voeg opslag toe<\/i>. De wizard voor het toevoegen vertelt dat hij dit ondersteunt. Natuurlijk ondersteunt hij VMFS. Daar had ik geen twijfels over. Een vluchtige blik op de berichten van de wizard bij elke stap: Volgende, Volgende, Voltooien. Mijn blik is zelfs niet op de kleine gele cirkel met een uitroepteken onderaan een van de stappen van de wizard gevallen.<\/p>\n

Na de wizard verscheen de nieuwe Datastore in de lijst... samen met Datastores van de andere fysieke schijven.<\/p>\n

Ik ga navigeren door de pas toegevoegde Datastore, en die is... leeg. Uiteraard viel ik opnieuw in verbazing. Het is 8 uur 's morgens, de eerste 15 minuten op het werk na mijn vakantie, ik heb zelfs de suiker in mijn koffie nog niet geroerd. En dan dit. Mijn eerste gedachte was \u2014 ik heb de verkeerde schijf van de \"hoofd\" host getrokken. Gecontroleerd of de gewenste Datastore aanwezig is op de \"hoofd\" host: nee, die is er niet. De tweede gedachte was: \"verdorie!\". Ik ben niet zeker, maar ik denk dat de derde, vierde en minstens de vijfde gedachte ook zo waren.<\/p>\n

Om mijn twijfels te verhelpen, heb ik snel een nieuwe ESXi getest, een random schijf genomen en, terwijl ik las, door de stappen van de wizard gegaan. Ja. Bij het toevoegen van een Datastore via de wizard verliezen alle gegevens op de schijf zonder mogelijkheid om de operatie terug te draaien en gegevens te herstellen. Later las ik op een van de forums de beoordeling van dit ontwerp van de wizard: shitsome crap. En ik kon het niet meer eens zijn.<\/p>\n

Vanaf de zesde \u2014 begonnen de gedachten meer constructief te stromen. Goed. De initialisatie duurt enkele seconden, zelfs voor een 3Tb-schijf. Dat betekent dat het om hoog-niveau formatteren gaat. Dat betekent dat alleen de partitie-tabel is overschreven. Dat betekent dat de gegevens er nog steeds zijn. Dus nu gaan we een unformat-tool zoeken en voila.<\/p>\n

Ik boot de machine met het opstartimage van Strelec... En ontdek dat recovery-programma's alles weten, behalve VMFS. Ze kennen bijvoorbeeld de partitie-indeling van Synology, maar VMFS \u2014 niet.<\/p>\n

De zoektocht naar programma's is niet bemoedigend: in de beste gevallen vinden GetDataBack en R.Saver NTFS-partities met een levendige mappenstructuur en levende bestandsnamen. Maar dat voldoet me niet. Ik heb twee vmdk-bestanden nodig: met de schijf van het systeem en de schijf van de afvalbestanden.<\/p>\n

En dat is wanneer ik besef dat ik waarschijnlijk Windows ga installeren en mijn bestanden ga herstellen vanaf een back-up. Tegelijkertijd herinner ik me dat ik daar een DFS-wortel had. En er is ook een volkomen verbazend uitgebreide en afwijkende systeem van toegangsrechten voor de mappen van de afdelingen. Geen optie. De enige tijdseffici\u00ebnte optie is het herstel van de systeemstatus en de schijf met gegevens en alle rechten.<\/p>\n

Weer Googelen, forums, KB-artikelen en weer de klagen van de Yaroslavna: VMware ESXi voorziet niet in een mechanisme voor gegevensherstel. Alle discussiedraden hebben twee uitkomsten: iemand heeft zich hersteld met behulp van de niet goedkope DiskInternals VMFS Recovery of iemand kreeg hulp van een specialist die zijn diensten actief promoot. vmfs-tools<\/i> en dd<\/i>. De optie om een licentie van DiskInternals VMFS Recovery voor $700 aan te schaffen, is geen optie. Toegang voor een derde partij van 'het grondgebied van een potenti\u00eble vijand' tot bedrijfsgegevens is eveneens geen optie. Maar het is gevonden dat UFS Explorer ook VMFS-partities kan lezen.<\/p>\n

DiskInternals VMFS Recovery<\/h3>\n

\nEen trialversie werd gedownload en ge\u00efnstalleerd. Het programma zag succesvol de lege VMFS-partitie:<\/p>\n

\"Restoring
\n
\nIn modus Undelete (Snelle scan)<\/i> vond ook de beschadigde datastore met mappen virtuele machines<\/a> met schijven erin:<\/p>\n

\"Restoring
\n
\nDe preview toonde aan dat de bestanden levend waren:<\/p>\n

\"Restoring
\n
\nHet monteren van de partitie in het systeem was succesvol, maar om onduidelijke redenen had elke map dezelfde virtuele machine. Natuurlijk, volgens de wet van Murphy \u2014 niet de gewenste.<\/p>\n

Drie zinnen van schaamte<\/b>De poging om de software schaamteloos te pirateren eindigde in een fiasco. Maar UFS Explorer werd wel succesvol gepirateerd.<\/p>\n

Ik ben extreem negatief over software-diefstal. Ik roep absoluut niet op tot het gebruiken van middelen om de bescherming tegen ongeautoriseerd gebruik te omzeilen. \n<\/p><\/blockquote>\n

\nIk bevond me in een catastrofale positie en was totaal niet trots op de maatregelen die ik had genomen.<\/p>\n

UFS Explorer<\/h3>\n

\nDe scan van de schijf toonde de aanwezigheid van 7 knooppunten. Het aantal knooppunten kwam 'wonderbaarlijk' overeen met het aantal *-flat.vmdk-bestanden dat door VMFS Recovery was gevonden:<\/p>\n

\"Restoring
\n
\nDe vergelijking van bestandsgroottes en knooppuntgroottes toonde ook overeenkomsten tot op de byte. Tegelijkertijd werden de namen van de *-flat.vmdk-bestanden hersteld en dus ook de toewijzing aan de virtuele machines.<\/p>\n

\"Restoring
\n
\nEigenlijk bestaan vmdk-schijven vanuit het perspectief van ESXi uit twee bestanden: dit is het gegevensbestand (<machine naam>-flat.vmdk) en het bestand voor de 'fysieke' indeling van de schijf (<machine naam>.vmdk). Als je het *-flat.vmdk-bestand vanaf een lokale machine in de Datastore uploadt, herkent ESXi het niet als een geldig schijfbestand. In de VMware-kennisbank is er een artikel over hoe je handmatig een schijfdescriptorbestand kunt maken: kb.vmware.com\/s\/article\/1002511<\/a><\/noindex>, maar ik hoefde dit niet te doen, ik heb gewoon de inhoud van de bijbehorende bestanden gekopieerd uit het voorbeeldgedeelte van het bestand in DiskInternals VMFS Recovery:<\/p>\n

\"Restoring
\n
\nNa 4 uur het exporteren van 2,5TB van de knooppunt uit UFS Explorer en 20 uur het importeren in de Datastore van de hypervisor, werden de beschadigde schijfbestanden aangesloten op een nieuw aangemaakte virtuele machine. De schijven werden herkend. Er is geen dataverlies opgemerkt.<\/p>\n

\"Restoring
\n
Bron: 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\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\udd47Wij herstellen virtuele machines met een foutief ge\u00efnitialiseerde Datastore. Het verhaal van een domme fout met een gelukkig einde | ProHoster","description":"Disclaimer: Deze notitie is bedoeld ter vermaak. De informatie-dichtheid is laag.","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/34321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=34321"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34321\/revisions"}],"predecessor-version":[{"id":159242,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34321\/revisions\/159242"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/25881"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=34321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=34321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=34321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}