लगहरू कहाँबाट आउँछन्? Veeam लग डाइविंग

हामी अनुमान लगाउने मनमोहक संसारमा हाम्रो डुब्न जारी राख्छौं ... लगहरूद्वारा समस्या निवारण। IN अघिल्लो लेख हामीले आधारभूत सर्तहरूको अर्थमा सहमति जनायौं र Veeam को समग्र संरचनालाई एक आँखाले एउटै अनुप्रयोगको रूपमा हेर्यौं। यसको लागि कार्य भनेको लग फाइलहरू कसरी बनाइन्छ, तिनीहरूमा कस्तो प्रकारको जानकारी प्रदर्शित हुन्छ र तिनीहरू किन देखिन्छन् भन्ने कुरा पत्ता लगाउनु हो।

तपाईलाई यी "लगहरू" के हो जस्तो लाग्छ? अधिकांशका अनुसार, कुनै पनि अनुप्रयोगको लगहरूलाई एक प्रकारको सर्वशक्तिमान निकायको भूमिका तोक्नु पर्छ जुन धेरैजसो समय घरपछाडि कतै वनस्पति हुन्छ, तर ठीक समयमा कतैबाट चम्किलो कवचमा देखा पर्दछ र सबैलाई बचाउँछ। त्यो हो, तिनीहरूले प्रत्येक घटकमा थोरै त्रुटिहरू देखि व्यक्तिगत डाटाबेस लेनदेन सम्म सबै कुरा समावेश गर्नुपर्छ। र त्यसैले त्रुटि पछि यो तुरुन्तै लेखिएको थियो कि यसलाई कसरी ठीक गर्ने। र यो सबै मेगाबाइट को एक जोडी मा फिट हुनुपर्छ, अधिक छैन। यो केवल पाठ हो! पाठ फाइलहरूले दसौं गिगाबाइटहरू लिन सक्दैन, मैले यो कतै सुनेको छु!

त्यसैले लगहरू

वास्तविक संसारमा, लगहरू निदान जानकारीको अभिलेख मात्र हुन्। र त्यहाँ के भण्डारण गर्ने, भण्डारणको लागि जानकारी कहाँ प्राप्त गर्ने र यो कत्तिको विस्तृत हुनुपर्छ, विकासकर्ताहरूले आफैले निर्णय गर्ने हो। कसैले ON / OFF स्तरको रेकर्ड राखेर minimalism को बाटो पछ्याउँछ, र कसैले लगनशीलताका साथ आफूले पुग्न सक्ने सबै चीजहरू निकाल्छ। यद्यपि त्यहाँ तथाकथित लगिङ स्तर चयन गर्ने क्षमताको साथ एक मध्यवर्ती विकल्प पनि छ, जब तपाईं आफैंले कसरी विस्तृत जानकारी भण्डारण गर्न चाहनुहुन्छ र कति अतिरिक्त डिस्क स्पेस छ भनेर संकेत गर्नुहुन्छ =) VBR सँग छवटा त्यस्ता स्तरहरू छन्। र, मलाई विश्वास गर्नुहोस्, तपाइँ तपाइँको डिस्कमा खाली ठाउँ संग सबै भन्दा विस्तृत लगिङ संग के हुन्छ हेर्न चाहनुहुन्न।

राम्रो। हामी के बचत गर्न चाहन्छौं भनेर हामीले लगभग बुझ्यौं, तर एक वैध प्रश्न उठ्छ: यो जानकारी कहाँबाट प्राप्त गर्ने? अवश्य पनि, हामी हाम्रा आन्तरिक प्रक्रियाहरूद्वारा आफैलाई लग इन गर्नका लागि घटनाहरूको अंश बनाउँछौं। तर बाह्य वातावरणसँग अन्तरक्रिया हुँदा के गर्ने? बैसाखी र साइकलको पिच नरकमा न सर्नको लागि, Veeam पहिले नै आविष्कार गरिसकेका आविष्कारहरू आविष्कार गर्दैन। जब पनि त्यहाँ रेडिमेड एपीआई, बिल्ट-इन प्रकार्य, पुस्तकालय, इत्यादि हुन्छ, हामी हाम्रा कन्ट्र्याप्शनहरू फेंस गर्न सुरु गर्नु अघि रेडिमेड विकल्पहरूलाई प्राथमिकता दिनेछौं। यद्यपि पछिल्लो पनि पर्याप्त छ। त्यसकारण, लगहरू विश्लेषण गर्दा, यो बुझ्न महत्त्वपूर्ण छ कि त्रुटिहरूको सिंहको अंश तेस्रो-पक्ष API, प्रणाली कलहरू, र अन्य पुस्तकालयहरूबाट सन्देशहरूमा पर्दछ। यस अवस्थामा, VBR को भूमिका यी त्रुटिहरूलाई लग फाइलहरूमा फर्वार्ड गर्न तल आउँछ। र प्रयोगकर्ताको मुख्य कार्य भनेको कुन लाइन कसको हो, र यो "को" को लागि जिम्मेवार छ भनेर बुझ्न सिक्नु हो। त्यसोभए यदि VBR लगबाट त्रुटि कोडले तपाईंलाई MSDN पृष्ठमा लैजान्छ भने, त्यो राम्रो र सही छ।

हामीले पहिले सहमति जनाए अनुसार: Veeam एक तथाकथित SQL-आधारित अनुप्रयोग हो। यसको मतलब यो हो कि सबै सेटिङहरू, सबै जानकारी र सामान्यतया सबै चीजहरू जुन सामान्य कार्यका लागि मात्र आवश्यक छ - सबै कुरा यसको डेटाबेसमा भण्डार गरिएको छ। यसैले सरल सत्य: के लग मा छैन डाटाबेस मा धेरै सम्भव छ। तर यो चाँदीको बुलेट पनि होइन: केहि चीजहरू Veeam कम्पोनेन्टहरूको स्थानीय लगहरूमा छैनन्, न त यसको डाटाबेसमा। तसर्थ, तपाईंले होस्ट लगहरू, स्थानीय मेसिनको लगहरू र ब्याकअप र पुनर्स्थापना प्रक्रियामा संलग्न हुने सबैका लगहरू कसरी अध्ययन गर्ने भनेर सिक्नु आवश्यक छ। र यो पनि हुन्छ कि आवश्यक जानकारी कतै उपलब्ध छैन। त्यो बाटो हो। 

त्यस्ता API हरूका केही उदाहरणहरू

यो सूची असाधारण रूपमा पूर्ण हुने लक्ष्य राख्दैन, त्यसैले यसमा अन्तिम सत्य खोज्नु आवश्यक छैन। यसको उद्देश्य हाम्रो उत्पादनहरूमा प्रयोग हुने सबैभन्दा सामान्य तेस्रो-पक्ष API र प्रविधिहरू देखाउनु मात्र हो।

बाट सुरु गरौं VMware. 

सूचीमा पहिलो हुनेछ vSphere API। प्रमाणीकरण, पदानुक्रम पढ्ने, स्न्यापसटहरू सिर्जना गर्ने र मेटाउने, मेसिनहरूको बारेमा जानकारी अनुरोध गर्ने, र धेरै (धेरै धेरै) को लागि प्रयोग गरिन्छ। समाधानको कार्यक्षमता धेरै फराकिलो छ, त्यसैले म संस्करणको लागि VMware vSphere API सन्दर्भ सिफारिस गर्न सक्छु। 5.5 и 6.0। थप हालको संस्करणहरूको लागि, सबै कुरा मात्र गुगल गरिएको छ।

VIX API। हाइपरवाइजरको कालो जादू, जसको लागि त्यहाँ छुट्टै छ त्रुटि सूची। VMware API होस्टमा फाइलहरूसँग नेटवर्कमा जडान नगरी काम गर्नका लागि। अन्तिम रिसोर्टको एक संस्करण जब तपाइँलाई मेसिनमा फाइल राख्न आवश्यक छ जसमा कुनै राम्रो सञ्चार च्यानल छैन। यदि फाइल ठूलो छ र होस्ट लोड छ भने यो पीडा र पीडा हो। तर यहाँ नियमले काम गर्छ कि ५६.६ Kb/s पनि ० Kb/s भन्दा राम्रो छ। Hyper-V मा, यो चीजलाई PowerShell Direct भनिन्छ। तर यो पहिले मात्र थियो

vSpehere वेब सेवा API vSphere 6.0 बाट सुरु हुँदै (लगभग, यो एपीआई पहिलो संस्करण 5.5 मा प्रस्तुत गरिएको थियो) यो अतिथि मेशिनहरूसँग काम गर्न प्रयोग गरिन्छ र लगभग सबै ठाउँमा VIX विस्थापित भएको छ। वास्तवमा, यो vSphere व्यवस्थापनको लागि अर्को API हो। रुचि राख्नेहरूको लागि, म अध्ययन गर्न सिफारिस गर्दछु отличный म्यानुअल। 

VDDK (भर्चुअल डिस्क विकास किट)। पुस्तकालय, जसमा आंशिक रूपमा छलफल भएको थियो लेख। भर्चुअल डिस्कहरू पढ्न प्रयोग गरियो। एक पटक यो VIX को भाग थियो, तर समय संग यो एक अलग उत्पादन मा सारियो। तर उत्तराधिकारीको रूपमा, यसले VIX को रूपमा उही त्रुटि कोडहरू प्रयोग गर्दछ। तर केही कारणका लागि, SDK मा यी त्रुटिहरूको कुनै विवरण छैन। त्यसकारण, यो प्रायोगिक रूपमा पत्ता लाग्यो कि अन्य कोडहरूसँग VDDK त्रुटिहरू बाइनरीबाट दशमलव कोडमा अनुवाद मात्र हुन्। यसमा दुई भागहरू हुन्छन् - पहिलो आधा सन्दर्भको बारेमा कागजात नभएको जानकारी हो, र दोस्रो भाग परम्परागत VIX / VDDK त्रुटिहरू हो। उदाहरण को लागी, यदि हामी देख्छौं:

VDDK error: 21036749815809.Unknown error

त्यसपछि हामी साहसपूर्वक यसलाई हेक्समा रूपान्तरण गर्छौं र 132200000001 प्राप्त गर्छौं। हामी केवल 132200 को अजानकारी सुरुवातलाई खारेज गर्छौं, र बाँकी हाम्रो त्रुटि कोड (VDDK 1: अज्ञात त्रुटि) हुनेछ। धेरै बारम्बार VDDK त्रुटिहरूको बारेमा, भर्खरै एउटा छुट्टै थियो लेख.

अब हेरौं विन्डोजहरू.

यहाँ, हाम्रो लागि सबैभन्दा आवश्यक र महत्त्वपूर्ण सबै कुरा मानकमा पाउन सकिन्छ कार्यक्रम दर्शक। तर त्यहाँ एउटा क्याच छ: लामो परम्परा अनुसार, विन्डोजले त्रुटिको पूर्ण पाठ लग गर्दैन, तर यसको संख्या मात्र। उदाहरण को लागी, त्रुटि 5 "पहुँच अस्वीकार" हो, र 1722 "RPC सर्भर अनुपलब्ध छ", र 10060 "कनेक्शन टाइम आउट" हो। निस्सन्देह, यो राम्रो छ यदि तपाइँ सबैभन्दा प्रसिद्ध व्यक्तिहरू सम्झनुहुन्छ, तर अहिलेसम्म नदेखेकाहरूको बारेमा के हो? 

र त्यसैले जीवन मह जस्तो लाग्दैन, त्रुटिहरू पनि हेक्साडेसिमल फारममा भण्डार गरिएको छ, उपसर्ग 0x8007 संग। उदाहरण को लागी, 0x8007000e वास्तवमा 14 हो, मेमोरी बाहिर। यो किन र कसको लागि गरिएको थियो त्यो अन्धकारमा ढाकेको रहस्य हो। यद्यपि, त्रुटिहरूको पूर्ण सूची निःशुल्क र बिना SMS बाट डाउनलोड गर्न सकिन्छ devcenter.

खैर, कहिलेकाहीँ त्यहाँ अन्य उपसर्गहरू छन्, ०x0 मात्र होइन। यस्तो दुखद स्थितिमा, HRESULT ("नतिजा ह्यान्डल") बुझ्नको लागि, तपाईंले अझ गहिरो अध्ययन गर्न आवश्यक छ। कागजात विकासकर्ताहरूको लागि। सामान्य जीवनमा, म तपाईंलाई यो गर्न सल्लाह दिँदिन, तर यदि तपाईं अचानक पर्खालमा थिच्नुभयो वा केवल उत्सुक हुनुहुन्छ भने, अब तपाईलाई थाहा छ के गर्ने।

तर माइक्रोसफ्टका कमरेडहरूले हामीप्रति थोरै दया देखाए र संसारलाई उपयोगिता देखाए ERR। यो कन्सोल खुशीको सानो टुक्रा हो जसले त्रुटि कोडहरूलाई Google प्रयोग नगरी मानवमा अनुवाद गर्न सक्छ। यो यस्तो काम गर्छ।

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

एक वैध प्रश्न उठ्छ: किन हामी लगहरूमा डिक्रिप्शन तुरुन्तै लेख्दैनौं, तर यी रहस्यमय कोडहरू छोड्नुहोस्? जवाफ तेस्रो-पक्ष अनुप्रयोगहरूमा छ। जब तपाइँ केहि WinAPI कल आफैलाई तान्नुहुन्छ, यसको प्रतिक्रिया बुझ्न गाह्रो छैन, किनभने त्यहाँ यसको लागि एक विशेष WinAPI कल पनि छ। तर पहिले नै उल्लेख गरिएझैं, प्रतिक्रियाहरूमा हामीलाई आउने सबै कुरा हाम्रो लगहरूमा आउँछ। र यहाँ, यसलाई डिक्रिप्ट गर्नको लागि, यो चेतनाको स्ट्रिमलाई निरन्तर निगरानी गर्नुपर्दछ, यसबाट विन्डोज त्रुटिहरू भएका टुक्राहरू निकाल्नुपर्छ, तिनीहरूलाई डिक्रिप्ट गर्नुहोस् र तिनीहरूलाई फिर्ता टाँस्नुहोस्। इमानदार बनौं, सबैभन्दा रोमाञ्चक गतिविधि होइन।

विन्डोज फाइल व्यवस्थापन API फाइलहरूसँग काम गर्दा हरेक सम्भावित तरिकामा प्रयोग गरिन्छ। फाइलहरू सिर्जना गर्ने, मेटाउने, लेख्नका लागि खोल्ने, विशेषताहरूसँग काम गर्ने, र यस्तै अन्य कुराहरू।

माथि उल्लेख छ PowerShell प्रत्यक्ष हाइपर-V संसारमा VIX API को एनालगको रूपमा। दुर्भाग्यवश, यति लचिलो छैन: कार्यक्षमतामा धेरै प्रतिबन्धहरू, यसले होस्टको प्रत्येक संस्करणसँग काम गर्दैन र सबै अतिथिहरूसँग होइन।

Rpc (रिमोट प्रोसिजर कल) मलाई लाग्दैन कि विन्डोजमा काम गरेको एक जना व्यक्ति हो जसले RPC-सम्बन्धित त्रुटिहरू देखेको छैन। लोकप्रिय गलत धारणाको बावजुद, यो एकल प्रोटोकल होइन, तर कुनै पनि ग्राहक-सर्भर प्रोटोकल हो जसले धेरै प्यारामिटरहरूलाई सन्तुष्ट गर्दछ। यद्यपि, यदि हाम्रो लगहरूमा RPC त्रुटि छ भने, समयको 90% यो Microsoft RPC बाट त्रुटि हुनेछ, जुन DCOM (डिस्ट्रिब्युटेड कम्पोनेन्ट वस्तु मोडेल) को अंश हो। तपाईंले नेटमा यस विषयमा धेरै कागजातहरू फेला पार्न सक्नुहुन्छ, तर यसको सिंहको अंश धेरै पुरानो छ। तर यदि विषय अध्ययन गर्न तीव्र इच्छा छ भने, म लेख सिफारिस गर्न सक्छु RPC भनेको के हो?, कसरी RPC काम गर्दछ र लामो सूची RPC त्रुटिहरू.

हाम्रो लगहरूमा RPC त्रुटिहरूको मुख्य कारणहरू VBR कम्पोनेन्टहरू (सर्भर > प्रोक्सी, उदाहरणका लागि) र प्रायः सञ्चार समस्याहरूको कारणले गर्दा सञ्चार गर्न असफल प्रयासहरू हुन्।

सबै शीर्षहरूमा शीर्ष शीर्ष त्रुटि हो RPC सर्भर अनुपलब्ध छ (१७२२)। साधारण सर्तहरूमा, ग्राहकले सर्भरसँग जडान स्थापित गर्न सकेन। कसरी र किन - त्यहाँ कुनै एकल जवाफ छैन, तर सामान्यतया यो प्रमाणीकरण वा पोर्ट 1722 मा नेटवर्क पहुँच संग समस्या हो। पछिल्लो गतिशील पोर्ट असाइनमेन्ट संग पूर्वाधार को लागी सामान्य छ। यस विषयमा, त्यहाँ पनि छ अलग HF। र माइक्रोसफ्ट छ विशाल गाइड असफलताको कारण पत्ता लगाउन।

दोस्रो सबैभन्दा लोकप्रिय त्रुटि: अन्तिम बिन्दु म्यापर (1753) बाट त्यहाँ कुनै थप अन्त्य बिन्दुहरू उपलब्ध छैनन्। RPC क्लाइन्ट वा सर्भरले आफैलाई पोर्ट तोक्न असफल भयो। सामान्यतया तब हुन्छ जब सर्भर (हाम्रो मामलामा, अतिथि मेसिन) लाई समाप्त भएको साँघुरो दायराबाट पोर्टहरू गतिशील रूपमा आवंटित गर्न कन्फिगर गरिएको छ। र यदि तपाइँ ग्राहक पक्षबाट लग इन गर्नुहुन्छ (हाम्रो मामलामा, VBR सर्भर), यसको मतलब यो हो कि हाम्रो VeeamVssAgent सुरु भएन वा RPC इन्टरफेसको रूपमा दर्ता गरिएको थिएन। यो विषयमा पनि छ अलग HF.

ठीक छ, शीर्ष 3 RPC त्रुटिहरू पूरा गर्न, RPC प्रकार्य कल असफल भयो (1726) सम्झनुहोस्। जडान स्थापित भएको छ भने देखिन्छ, तर RPC अनुरोधहरू प्रशोधन गरिएको छैन। उदाहरण को लागी, हामी VSS को स्थिति को बारे मा जानकारी को लागी अनुरोध गर्दछौं (अचानक अहिले त्यहाँ छाया माइन बनाइएको छ, र हामी चढ्न कोशिस गर्दैछौं), र हाम्रो जवाफ मा, मौन र बेवास्ता।

विन्डोज टेप ब्याकअप API टेप लाइब्रेरी वा ड्राइभहरूसँग काम गर्न आवश्यक छ। मैले सुरुमा उल्लेख गरेझैं: हामीलाई आफ्नै ड्राइभरहरू लेख्न र त्यसपछि प्रत्येक उपकरणको समर्थनमा पीडामा कुनै आनन्द छैन। तसर्थ, vim सँग यसको आफ्नै ड्राइभरहरू छैनन्। सबै एक मानक API मार्फत, जसको समर्थन हार्डवेयर विक्रेताहरू आफैले लागू गरेको छ। यति धेरै तार्किक, हैन?

SMB / CIFS बानीको कारण, सबैले तिनीहरूलाई छेउछाउमा लेख्छन्, यद्यपि सबैले याद गर्दैनन् कि CIFS (सामान्य इन्टरनेट फाइल प्रणाली) SMB (सर्भर सन्देश ब्लक) को निजी संस्करण मात्र हो। त्यसकारण यी अवधारणाहरूलाई सामान्यीकरण गर्नमा केही गलत छैन। साम्बा पहिले नै लिनक्सयुनिक्स कार्यान्वयन हो, र यसको आफ्नै विशेषताहरू छन्, तर म पछि हट्छु। यहाँ के महत्त्वपूर्ण छ: जब Veeam ले UNC पथ (सर्भर डाइरेक्टरी) मा केहि लेख्न सोध्छ, सर्भरले बलमा लेख्न mup र mrxsmb सहित फाइल प्रणाली ड्राइभरहरूको पदानुक्रम प्रयोग गर्दछ। तदनुसार, यी चालकहरूले त्रुटिहरू उत्पन्न गर्नेछन्।

बिना गर्न सकिदैन Winsock API। यदि नेटवर्कमा केहि गर्न आवश्यक छ भने, VBR ले Windows Socket API मार्फत काम गर्दछ, लोकप्रिय रूपमा Winsock को रूपमा चिनिन्छ। त्यसोभए यदि हामीले IP को गुच्छा देख्यौं: लगमा पोर्ट, यो हो। आधिकारिक कागजातमा सम्भवको राम्रो सूची छ गल्ती.

माथि उल्लेख छ WMI (Windows Management Instrumentation) विन्डोज संसारमा सबै कुरा र सबैलाई प्रबन्ध गर्नको लागि सर्वशक्तिमान API को एक प्रकार हो। उदाहरण को लागी, Hyper-V को साथ काम गर्दा, होस्ट को लागी लगभग सबै अनुरोधहरु यस मार्फत जान्छन्। एक शब्द मा, चीज बिल्कुल अपरिवर्तनीय र यसको क्षमता मा धेरै शक्तिशाली छ। कहाँ र के बिग्रिएको छ भनेर पत्ता लगाउन मद्दत गर्ने प्रयासमा, निर्मित WBEMtest.exe उपकरणले धेरै मद्दत गर्दछ।

र सूचीमा अन्तिम, तर कुनै पनि हिसाबले कम्तिमा महत्त्वमा - VSS (भोल्युम छाया भण्डारण)। यो विषय जति धेरै कागजपत्र लेखिएको छ त्यति नै अकल्पनीय र रहस्यमय छ। छाया प्रतिलिपिलाई विशेष प्रकारको स्न्यापसटको रूपमा बुझिन्छ, जुन सारमा यो हो। उहाँलाई धन्यवाद, तपाइँ VMware मा एप्लिकेसन-संगत ब्याकअपहरू बनाउन सक्नुहुन्छ, र हाइपर-V मा लगभग सबै कुरा। मसँग VSS मा केहि निचोड संग एउटा छुट्टै लेख बनाउने योजना छ, तर अहिलेको लागि तपाईले पढ्ने प्रयास गर्न सक्नुहुन्छ यो विवरण। केवल सावधान रहनुहोस्, किनभने। फ्ल्यासमा VSS बुझ्ने प्रयास गर्दा मस्तिष्कमा चोट लाग्न सक्छ।

यसमा, सायद, हामी रोक्न सक्छौं। मैले सबैभन्दा आधारभूत कुराहरू पूरा भएको व्याख्या गर्ने कार्यलाई विचार गर्छु, त्यसैले अर्को अध्यायमा हामी लगहरू हेर्नेछौं। तर यदि तपाइँसँग कुनै प्रश्नहरू छन् भने, टिप्पणीहरूमा तिनीहरूलाई सोध्न नहिचकिचाउनुहोस्।

स्रोत: www.habr.com