चुकीच्या पद्धतीने सुरू केलेल्या डेटास्टोअरमधून आभासी मशीन पुनर्संचयित करणे. आनंदी शेवट असलेल्या एका मूर्खपणाची कथा

अस्वीकरण: नोट मनोरंजनाच्या उद्देशाने आहे. त्यातील उपयुक्त माहितीची विशिष्ट घनता कमी आहे. ते "माझ्यासाठी" लिहिले होते.

गीतात्मक परिचय

आमच्या संस्थेतील फाइल डंप विंडोज सर्व्हर 6 चालवणार्‍या VMware ESXi 2016 व्हर्च्युअल मशीनवर चालते. आणि हे केवळ कचरा डंप नाही. हे स्ट्रक्चरल विभागांमधील फाइल एक्सचेंज सर्व्हर आहे: नेटवर्क स्कॅनरमधील सहयोग, प्रकल्प दस्तऐवजीकरण आणि फोल्डर आहेत. सर्वसाधारणपणे, सर्व उत्पादन जीवन येथे आहे.

आणि सर्व उत्पादन जीवनाचा हा कंटेनर लटकू लागला. शिवाय, अतिथी इतरांना प्रभावित न करता शांतपणे स्वत: ला लटकवू शकतो. तो संपूर्ण यजमान आणि त्यानुसार, इतर सर्व अतिथी मशीन खाली घेऊ शकतो. मी स्वत: ला हँग करू शकतो आणि vSphere क्लायंट सेवा हँग करू शकतो: म्हणजे, इतर अतिथींच्या प्रक्रिया जिवंत आहेत, मशीन योग्यरित्या कार्य करतात आणि प्रतिसाद देतात, परंतु फाइल वॉशर नाही आणि vSphere क्लायंट होस्टला चिकटत नाही. सर्वसाधारणपणे, कोणतीही प्रणाली ओळखली जाऊ शकत नाही. कमी भार असताना दिवसा फ्रीझ होऊ शकते. लोड नसताना ते रात्री करू शकत होते. विभेदक बॅकअप आणि सरासरी लोड दरम्यान रात्री शक्य. पूर्ण बॅकअप आणि उच्च लोड दरम्यान शनिवार व रविवार शक्य. आणि परिस्थितीची स्पष्ट अधोगती होती. सुरुवातीला ते वर्षातून एकदा होते, नंतर दर सहा महिन्यांनी एकदा. माझ्या संयमाच्या शेवटी - आठवड्यातून दोनदा.
मला स्मृती समस्या होती. पण त्यांनी मला वीकेंडलाही कचऱ्याचा ढीग थांबवू दिला नाही आणि मेमटेस्ट चालवू दिला नाही. आम्ही मे महिन्याच्या सुट्टीची वाट पाहत होतो. मे महिन्याच्या सुट्ट्यांमध्ये, मी मेमटेस्ट चालवली आणि... कोणत्याही त्रुटी आढळल्या नाहीत.

मी आश्चर्यचकित झालो आणि सुट्टीवर जाण्याचा निर्णय घेतला. मी सुट्टीवर असताना कचऱ्याच्या ढिगाऱ्यावर एकही हँगअप नव्हता. आणि सोमवारी पहिल्या दिवशी कामावर परत गेलो तेव्हा तिथे कचऱ्याचा ढीग होता. मी पूर्ण बॅकअप सहन केला आणि ते पूर्ण झाल्यानंतर लगेच हँग झाले. सुट्टीतील अशा प्रेमळ स्वागताने मला अतिथी मशीनसह डिस्क्स भौतिकरित्या दुसर्या होस्टकडे ड्रॅग करण्याचा निर्णय घेतला.

आणि, सुट्टीनंतर पहिल्या दिवशी आपण काहीही गंभीर करू शकत नाही हे बर्याच काळापासून ज्ञात आहे, जरी मी स्वत: ला पूर्णतः काम न करण्याची तयारी करत होतो, तरीही आणखी एका फ्रीझमुळे माझ्या रागाने माझा मूड आणि माझा दोन्ही ठोठावला. माझ्या डोक्यातून नवस निघाले...

भौतिक डिस्क दुसर्या होस्टवर हलवल्या गेल्या आहेत. गरम कनेक्शन. टॅबवरील स्टोरेज सेटिंग्जमध्ये ड्राइव्ह डिस्क दिसतात. टॅबवर डेटास्टोअर या डिस्कवर कोणतेही स्टोरेज नाही. रिफ्रेश - दिसत नाही. बरं, अर्थातच, पहिला आवेग - स्टोरेज जोडा. अॅड विझार्ड ते कशाचे समर्थन करते हे स्पष्ट करते. अर्थात ते VMFS ला देखील सपोर्ट करते. मला शंका आली नाही. प्रत्येक चरणावर विझार्डच्या संदेशांवर एक द्रुत दृष्टीक्षेप: पुढील, पुढील, पुढील, समाप्त. मास्तरांच्या एका पायरीच्या खिडकीच्या तळाशी उद्गारवाचक चिन्ह असलेले छोटे पिवळे वर्तुळ पकडायलाही नजर जवळ आली नाही.

विझार्डच्या शेवटी, यादीमध्ये नवीन डेटास्टोअर दिसू लागले... आणि त्यासोबत उर्वरित भौतिक डिस्कमधील डेटास्टोअर.

मी नव्याने जोडलेल्या डेटास्टोअरमधून नेव्हिगेट करण्यासाठी पुढे जात आहे आणि ते... रिकामे आहे. अर्थात, मी पुन्हा आश्चर्यचकित झालो. सकाळचे 8 वाजले आहेत, सुट्टीनंतर कामाची पहिली 15 मिनिटे, मी अद्याप माझ्या कॉफीमध्ये साखर देखील ढवळलेली नाही. आणि इथे आहे. पहिला विचार असा होता की मी “नेटिव्ह” होस्टकडून चुकीची डिस्क काढली. "नेटिव्ह" होस्टमध्ये आवश्यक डेटास्टोर उपस्थित आहे की नाही हे मी पाहिलं: नाही, ते उपस्थित नव्हते. दुसरा विचार होता: "संभोग!" मला खात्री नाही, परंतु मला असे दिसते की तिसरा, चौथा आणि किमान पाचवा विचार समान होता.

शंका दूर करण्यासाठी, मी त्वरीत चाचणीसाठी एक नवीन ESXi स्थापित केला, डावी डिस्क घेतली आणि आधीच ती वाचून, विझार्डच्या चरणांवरून चालत गेलो. होय. जेव्हा तुम्ही विझार्ड वापरून डेटास्टोअर जोडता, तेव्हा ऑपरेशन रोल बॅक करण्याची आणि डेटा पुनर्संचयित करण्याच्या क्षमतेशिवाय डिस्कवरील सर्व डेटा गमावला जातो. नंतर मी एका मंचावर या डिझाइनचे मास्टरद्वारे केलेले मूल्यांकन वाचले: शिट्ससम क्रॅप. आणि मी खरोखर सहमत आहे.

सहावीपासून विचारांचा प्रवाह अधिक विधायक दिशेने सुरू झाला. ठीक आहे. 3Tb डिस्कसाठी देखील प्रारंभ होण्यास काही सेकंद लागतात. तर हे उच्च-स्तरीय स्वरूपन आहे. याचा अर्थ विभाजन तक्ता फक्त पुन्हा लिहिला गेला. त्यामुळे डेटा अजूनही आहे. तर, आता आम्ही काही अनफॉर्मेट आणि व्हॉइला शोधू.

मी स्ट्रेलेक बूट इमेजवरून मशीन बूट करतो... आणि मला आढळले की विभाजन पुनर्प्राप्ती प्रोग्रामला VMFS व्यतिरिक्त सर्व काही माहित आहे. उदाहरणार्थ, त्यांना Synology चे विभाजन लेआउट माहित आहे, परंतु VMFS नाही.

प्रोग्राम्सद्वारे शोधणे आश्वासक नाही: सर्वोत्तम म्हणजे, GetDataBack आणि R.Saver ला थेट निर्देशिका संरचना आणि थेट फाइल नावांसह NTFS विभाजने सापडतात. पण हे मला पटत नाही. मला दोन vmdk फायली पाहिजेत: सिस्टम डिस्क आणि ट्रॅश फाइल डिस्कसह.

आणि मग मला समजले की मी आता विंडोज इंस्टॉल करेन आणि फाइल बॅकअपमधून रोल आउट करेन असे दिसते. आणि त्याच वेळी मला आठवते की माझ्याकडे तेथे डीएफएस रूट आहे. आणि डिपार्टमेंट फोल्डर्सच्या प्रवेश अधिकारांची एक प्रणाली जी व्याप्ती आणि परिणामांमध्ये पूर्णपणे जंगली आहे. पर्याय नाही. डेटा आणि सर्व अधिकारांसह सिस्टम आणि डिस्कची स्थिती पुनर्संचयित करणे हा एकमेव वेळ-स्वीकारणारा पर्याय आहे.

पुन्हा Google, मंच, KB'shki आणि पुन्हा Yaroslavna चे रडणे: VMware ESXi डेटा पुनर्प्राप्ती यंत्रणा प्रदान करत नाही. सर्व चर्चा थ्रेड्सचे दोन शेवट आहेत: कोणीतरी महाग डिस्कइंटरनल्स VMFS रिकव्हरी वापरून पुनर्प्राप्त केले गेले किंवा एखाद्याला त्याच्या सेवांचा सक्रियपणे प्रचार करणार्‍या सॉफ्टवेअर तज्ञाने मदत केली. vmfs-साधने и dd. DiskInternals VMFS रिकव्हरी परवाना $700 मध्ये खरेदी करण्याचा पर्याय नाही. कॉर्पोरेट डेटामध्ये प्रवेश करण्यासाठी "संभाव्य शत्रूचा प्रदेश" मधील बाहेरील व्यक्तीला परवानगी देणे हा देखील पर्याय नाही. पण हे गुगल केले होते की VMFS विभाजने UFS Explorer द्वारे देखील वाचता येतात.

डिस्कइंटरनल VMFS पुनर्प्राप्ती

चाचणी आवृत्ती डाउनलोड आणि स्थापित केली गेली. प्रोग्रामने रिक्त VMFS विभाजन यशस्वीरित्या पाहिले:

मोड हटवा (जलद स्कॅन) मला डिस्कसह व्हर्च्युअल मशीनच्या फोल्डर्ससह एक जर्जर डेटास्टोर देखील सापडला:

पूर्वावलोकनाने दाखवले की फायली जिवंत आहेत:

सिस्टममध्ये विभाजन माउंट करणे यशस्वी झाले, परंतु काही अज्ञात कारणास्तव, सर्व तीन फोल्डर्समध्ये समान आभासी मशीन समाविष्ट आहे. अर्थात, कायद्यानुसार, क्षुद्रपणा आवश्यक नाही.

लाज तीन ओळीनिर्लज्जपणे सॉफ्टवेअर लॉक करण्याचा प्रयत्न अयशस्वी झाला. पण UFS एक्सप्लोरर लॉक झाला.

सॉफ्टवेअर चोरीबद्दल माझा अत्यंत नकारात्मक दृष्टिकोन आहे. मी कोणत्याही प्रकारे विनापरवाना वापरापासून संरक्षण बायपास करण्यासाठी साधनांचा वापर करण्यास प्रोत्साहित करत नाही.

मी एक आपत्तीजनक परिस्थितीत होतो आणि मी केलेल्या उपायांचा मला अजिबात अभिमान नव्हता.

यूएफएस एक्सप्लोरर

डिस्क स्कॅनने 7 नोड्सची उपस्थिती दर्शविली. VMFS रिकव्हरी द्वारे आढळलेल्या *-flat.vmdk फायलींच्या संख्येशी “आश्चर्यकारकपणे” नोड्सची संख्या जुळली:

फाइल आकार आणि नोड आकारांची तुलना देखील बाइटशी जुळणारी दर्शविले. त्याच वेळी, *-flat.vmdk फायलींची नावे आणि त्यानुसार, व्हर्च्युअल मशीनशी संबंधित त्यांचे पुनर्संचयित केले गेले.

सर्वसाधारणपणे, ESXi दृष्टिकोनातून vmdk डिस्क्समध्ये दोन फाइल्स असतात: एक डेटा फाइल (<machine name>-flat.vmdk) आणि एक "फिजिकल" डिस्क लेआउट फाइल (<मशीन नाव>.vmdk). तुम्ही स्थानिक मशीनवरून डेटास्टोअरवर *-flat.vmdk फाइल अपलोड केल्यास, ESXi ती वैध डिस्क फाइल म्हणून ओळखणार नाही. व्हीएमवेअर नॉलेज बेसमध्ये डिस्क डिस्क्रिप्टर फाइल व्यक्तिचलितपणे कशी तयार करावी याबद्दल एक लेख आहे: kb.vmware.com/s/article/1002511, परंतु मला हे करण्याची गरज नव्हती, मी डिस्कइंटरनल्स व्हीएमएफएस रिकव्हरी मधील फाइल सामग्री पूर्वावलोकन क्षेत्रातून संबंधित फाइल्सची सामग्री कॉपी केली आहे:

UFS Explorer वरून 4 TB नोड अनलोड केल्यानंतर 2,5 तासांनंतर आणि हायपरवाइजरच्या डेटास्टोअरमध्ये 20 तास लोड केल्यानंतर, क्रॅश झालेल्या डिस्क फाइल्स नव्याने तयार केलेल्या व्हर्च्युअल मशीनशी जोडल्या गेल्या. डिस्क उचलल्या. कोणतीही डेटा हानी दिसून आली नाही.

स्त्रोत: www.habr.com