एक टेराबाइट सीमा नहीं है। क्षतिग्रस्त Microsoft SQL सर्वर डेटाबेस के उदाहरण का उपयोग करके अतिरिक्त-बड़े डेटा को पुनर्प्राप्त करना

दूषित फ़ाइलों से डेटा को पुनर्प्राप्त करते समय, डेटा संग्रहण की आंतरिक संरचना का गहन ज्ञान, डेटा संरचना में त्रुटियों को दरकिनार और सही करने के लिए एल्गोरिदम आमतौर पर महत्वपूर्ण होते हैं। लेकिन कभी-कभी अतिरिक्त कारक होते हैं जिन्हें टूटे हुए डेटा और इसकी वसूली की प्रक्रिया पर विचार किया जाना चाहिए। इस लेख में मैं जिन कारकों के बारे में बात करना चाहता हूं, उनमें से एक फ़ाइल का आकार है।

हमारे काम में आने वाली अधिकांश भ्रष्ट फाइलें कार्यालय (दस्तावेजों, तालिकाओं, प्रस्तुतियों) या ग्राफिक प्रारूपों से संबंधित हैं। साथ ही, उनका हॉलमार्क अपेक्षाकृत छोटा आकार (10 एमबी से कम) है। इसके दो कारण हैं। सबसे पहले, उपयोगकर्ताओं की एक बड़ी संख्या के साथ जो इन प्रारूपों की फाइलें बनाते हैं और उनका उपयोग करते हैं। दूसरे, आमतौर पर इस तरह के छोटे और, जैसा कि अक्सर माना जाता है, बहुत महत्वपूर्ण फाइलें कॉर्पोरेट डेटा सुरक्षा के दायरे में नहीं आती हैं। ऐसी फ़ाइलों को अक्सर पोर्टेबल डेटा स्टोरेज (USB फ्लैश, और कभी-कभी फ्लॉपी डिस्क) पर संग्रहीत किया जाता है, जो उनकी सुरक्षा पर भी बहुत बुरा प्रभाव डालता है। फ़ाइलों के इस वर्ग को संसाधित करते समय, आमतौर पर इनपुट डेटा के आकार के साथ कोई समस्या नहीं होती है - इनपुट फ़ाइल, यदि वांछित है, तो पूरी तरह से रैम में प्रोजेक्ट किया जा सकता है और सीधे इसमें चला सकता है।

इसके अलावा, फ़ाइल पुनर्प्राप्ति के लिए हमारे पास आने वाली फ़ाइलों का एक महत्वपूर्ण प्रतिशत विभिन्न डेटाबेस हैं। उनका आकार आमतौर पर सैकड़ों मेगाबाइट से लेकर दसियों गीगाबाइट तक होता है। आमतौर पर, ऐसी फाइलें कॉर्पोरेट डेटा सुरक्षा उपायों के अधीन होती हैं, लेकिन यह एक पूर्ण गारंटी नहीं देता है कि डेटा पूर्ण विफलता की स्थिति में सहेजा जाएगा। इन फ़ाइलों में से अधिकांश मेमोरी में स्टोर करने के लिए अनुचित या असंभव हैं। इसलिए, जब उन्हें रैम में संसाधित किया जाता है, तो फ़ाइल में डेटा के स्थान का कुछ मार्कअप पहली बार बनता है, जिसके अनुसार पुनर्प्राप्ति के लिए उपयुक्त डेटा पढ़ा जाता है और अगले पुनर्प्राप्ति चरण में आउटपुट डेटा उत्पन्न होता है। फ़ाइल मार्कअप द्वारा संभावित रूप से बड़ी मात्रा में कब्जे के मामले में, साथ ही साथ पुनर्प्राप्ति प्रक्रिया के दौरान डेटा के असमान टुकड़ों को एक वस्तु बनाने के लिए कनेक्ट करना आवश्यक होगा (उदाहरण के लिए, एक्सचेंज सर्वर स्टोरेज डेटाबेस के लिए पत्र), एक अस्थायी डेटाबेस का उपयोग किया जाता है जो मार्कअप को संग्रहीत करता है।

लेकिन असाधारण मामले हैं - टूटे हुए डेटाबेस आकार में सैकड़ों गीगाबाइट से लेकर कई टेराबाइट तक हैं। बेशक, इस तरह की मात्रा का डेटा महत्वहीन नहीं हो सकता है, और अक्सर पूरी कंपनी का काम ऐसे डेटाबेस के आसपास बनाया जाता है। जाहिर है, भंडारण की विश्वसनीयता सुनिश्चित करने के लिए, सभी बैकअप योजनाओं को ऐसे डेटा पर लागू किया जाना चाहिए, लेकिन इन सबके साथ, डेटाबेस गिरने के मामले भी हैं। इनमें से एक मामले पर बाद में चर्चा की जाएगी।

समस्या का विवरण

हमारी कंपनी को एक उपयोगकर्ता द्वारा संपर्क किया गया था जिसे 1.8 टेराबाइट MS SQL सर्वर डेटाबेस को पुनर्स्थापित करने की आवश्यकता थी। इस मामले से पहले हमें जो सबसे बड़ी फ़ाइल संसाधित करनी थी, वह 200-गीगाबाइट एक्सचेंज सर्वर डेटाबेस थी, इसलिए इस आकार की फ़ाइलों के साथ काम करने का कोई अनुभव नहीं था। एक उपयोगकर्ता ने इस डेटाबेस प्रारूप की वसूली के लिए हमारे उत्पाद को खरीदा - SQL सर्वर के लिए रिकवरी ( www.officerecovery.com/mssql/ ), लेकिन डेटाबेस को पुनर्स्थापित करने का प्रयास करते समय, प्रोग्राम ने तालिकाओं में से एक की पहली 99999 sql स्क्रिप्ट फ़ाइलों को रिकॉर्ड किया और फिर कुछ भी नहीं देखा। इस समस्या का हल आउटपुट फ़ाइल के नाम पर sql स्क्रिप्ट काउंटर की थोड़ी गहराई को बढ़ाना और प्रत्येक फ़ाइल को लिखे गए डेटा की मात्रा को बढ़ाना था। कार्यक्रम के अद्यतन निर्माण को भेजे जाने के बाद, उपयोगकर्ता ने डेटाबेस को पुनर्स्थापित करने के लिए इसे फिर से शुरू किया, लेकिन कुछ दिनों के बाद कार्यक्रम क्रैश हो गया। उपयोगकर्ता ने कार्यक्रम के बहुत तेज काम नहीं होने की भी शिकायत की। हमारा आगे का काम इन्हीं दो शिकायतों पर आधारित था।

इन समस्याओं को हल करने की प्रक्रिया को तेज करने के लिए, हमने उपयोगकर्ता से कहा कि वह हमें समस्या के आधार की एक प्रति भेजें, जिसमें हमारी ओर से एक गैर-प्रकटीकरण समझौते (एनडीए) पर हस्ताक्षर किए जाएं। डेटाबेस एक हार्ड ड्राइव पर आया था, जिसे हमने कैलिफोर्निया में अपने एक सर्वर से जोड़ा था। असली डेटा पर आगे के रन वहां हुए।

कार्यक्रम में बदल जाते हैं

इस अनुरोध पर काम करते समय, कार्यक्रम में सुधार करने से दो मुख्य लक्ष्य सामने आए:

• अतिरिक्त-बड़ी मात्रा की फ़ाइलों को पुनर्स्थापित करने की एक मौलिक संभावना - यदि 3 टेराबाइट्स के डेटाबेस को पुनर्स्थापित करना संभव हो जाता है, तो हम लगभग किसी भी आकार के डेटाबेस को पुनर्स्थापित करने की संभावना के बारे में बात कर सकते हैं।
• कार्यक्रम का त्वरण - ठीक होने के लिए 4 और 6 घंटे के बीच का अंतर ज्यादातर महत्वहीन है, 20 और 30 दिनों के बीच का अंतर महत्वपूर्ण है।

सबसे पहले, इस फाइल पर इसके पतन के मुद्दे पर कार्यक्रम का एक अध्ययन किया गया था। एक विकल्प था कि गिरावट गलत डेटा से एल्गोरिथ्म की अपर्याप्त सुरक्षा के कारण थी - इस मामले में, जहां ये गलत डेटा थे, उनसे निपटने और इस तरह की कड़वाहट के खिलाफ सुरक्षा का परिचय देने के लिए आवश्यक था। मुझे लगभग ५०० व्यक्तिगत फाइलों में से एक को खोजना होगा जो इस डेटाबेस को बनाते हैं। लेकिन गिरावट के एक और संस्करण की पुष्टि की गई - अस्थायी डेटाबेस से मार्कअप पढ़ने के लिए गैर-इष्टतम एल्गोरिथ्म के कारण, सुपर-बड़ी मात्रा में डेटा में पर्याप्त रैम नहीं था। एल्गोरिथ्म को फिर से डिज़ाइन किया गया है, गिरावट को समाप्त कर दिया गया है। आगे के काम की प्रक्रिया में अन्य गिरावट उत्पन्न नहीं हुई।

कार्यक्रम की गति में दो तरह से सुधार हुआ है:

• आधार के प्रारंभिक विश्लेषण की गति। शुरू में, यह लगभग दो दिन था। रीड बफर के अपने स्वयं के कार्यान्वयन के लिए सिस्टम बफरिंग की अस्वीकृति के साथ फाइल के पठन को संसाधित करने के बाद, पार्सिंग का समय 6-7 घंटे तक कम हो गया। सिस्टम फाइल रीड बफर के साथ रैम के क्लॉगिंग की समस्या भी हल हो गई थी।
• उत्पादन पीढ़ी दर। चूंकि आउटपुट sql स्क्रिप्ट है, इसलिए अधिकांश समय प्रोसेसर बाइनरी डेटा से स्ट्रिंग्स जेनरेट करने पर खर्च होता है। वर्ग-लिपि जनरेटर का बड़े पैमाने पर अनुकूलन किया गया। परिणाम - हार्ड ड्राइव (लेकिन सभी आउटपुट के गठन के साथ) को लिखे बिना डेटाबेस रिकवरी का एक पूरा रन - 6 दिन 8 घंटे। प्रारंभ में (अनुकूलन से पहले आंशिक फ़ाइल पुनर्प्राप्ति पर आधारित गणना के अनुसार), बहाली में 25-27 दिन लगेंगे।

हार्ड ड्राइव पर आउटपुट फ़ाइलों को लिखने के बिना "वर्चुअल" डेटाबेस रिकवरी की पूरी दौड़ के बाद, एक और समस्या स्पष्ट हो गई - डेटाबेस को फिर से बनाने के लिए आउटपुट स्क्रिप्ट को 12 730 132 244 866 बाइट्स (11.6 टेराबाइट्स) पर कब्जा करना पड़ा, और वे बस स्टोर करने के लिए कहीं नहीं थे।

आउटपुट फ़ाइलों को संग्रहीत करने की समस्या को हल करने के लिए, साइकल लिपियों को मक्खी पर ज़िप अभिलेखागार में संपीड़ित किया गया था। पैकेजिंग को लगभग 20 गीगाबाइट के स्क्रिप्ट पैक की अलग-अलग धाराओं में लॉन्च किया गया था, पैकेजिंग के बाद संबंधित लिपियों को हटा दिया गया था। लेकिन चूंकि स्क्रिप्ट्स पहले की तुलना में तेजी से उत्पन्न हुई थीं, इसलिए पैक किए गए थे, और थ्रेड्स की संख्या में वृद्धि के साथ, हार्ड डिस्क पर लोड तेजी से बढ़ा, पैकेजिंग पर एक साथ काम करने वाले थ्रेड्स की संख्या चार तक सीमित थी। जब यह सीमा समाप्त हो गई, तो मुख्य वसूली प्रवाह बंद हो गया और पैकेजिंग के पूरा होने का इंतजार किया।

परिणामस्वरूप, डेटाबेस पुनर्प्राप्ति सफल रही। पुनर्प्राप्ति समय 17 दिन है, डेटा संग्रह ने प्रक्रिया को धीमा कर दिया, लेकिन मुझे यह समझौता करना पड़ा। पैकेज्ड स्क्रिप्ट का आकार 1.1 टेराबाइट है। स्क्रिप्ट को एक अलग हार्ड ड्राइव पर रिकॉर्ड किया गया और उपयोगकर्ता को भेजा गया। सभी लिपियों को निष्पादित करने और आधार को सिस्टम में वापस करने के लिए कुछ समय की आवश्यकता के बाद, उपयोगकर्ता से सकारात्मक प्रतिक्रिया मिली।

निष्कर्ष

डेटा के इतने बड़े संस्करणों को पुनर्प्राप्त करना भी संभव है, हालांकि सबसे अधिक संभावना है, इसे पुनर्प्राप्ति सेवा से एक व्यक्तिगत दृष्टिकोण और किसी विशिष्ट मामले के लिए कार्यक्रम के अंतिम रूप या ट्यूनिंग की आवश्यकता होगी।

यदि आप समस्याओं का सामना करते हैं, तो इस वर्ग के डेटाबेस को एक प्रोग्राम फेंकने की आवश्यकता नहीं है जो क्षतिग्रस्त फ़ाइल को तुरंत बहाल नहीं कर सकता है। ऐसे मामलों में हमारे साथ प्रत्यक्ष संचार कार्यक्रम को एक स्तर तक परिष्कृत करने में मदद करेगा जो ऐसी फ़ाइलों को भी महारत हासिल करने की अनुमति देता है। OfficeRecovery इस तरह का एकमात्र मामला नहीं है - हम 200-500 गीगाबाइट के डेटाबेस को पुनर्प्राप्त करने के कई और मामलों से अवगत हैं, और हमें यकीन है कि हम ऐसे सभी मामलों के बारे में नहीं जानते हैं।

सभी प्रदर्शन संकेतक निम्नलिखित कॉन्फ़िगरेशन पर प्रोग्राम से हटा दिए गए थे - इंटेल कोर i7 920, 8 जीबी रैम, 1 टीबी (सिस्टम) + 2 टीबी (इनपुट) + 2 टीबी (आउटपुट) एसएटीए -2 एचडीडी। पुनर्प्राप्ति को गति देने के लिए, पैकेजिंग के लिए इच्छित स्क्रिप्ट के अस्थायी भंडारण के लिए एक अलग एसएसडी बहुत मददगार होगा।

बैकअप लेने और विश्वसनीय भंडारण विधियों का उपयोग करने के लिए मत भूलना। लेकिन याद रखें कि डेटा हानि से कोई भी सुरक्षित नहीं है। और अगर डेटा हानि अभी भी हुई है - OfficeRecovery आपके लिए प्रतीक्षा कर रही है।