SQL Server 2008: बैकअप बुद्धिमानी से। भाग 1: सिद्धांत

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

पहला कदम

यदि ऐसा होता है कि आप डेटाबेस को बनाए रखने और SQL सर्वर के निर्बाध कामकाज के लिए ज़िम्मेदार हैं, तो आपके बारे में सोचने वाली पहली बात बैकअप होगी - यह सामान्य है क्योंकि अगर आपके डेटाबेस के साथ कुछ होता है -कभी भी परेशानी, लेकिन आपके पास बैकअप नहीं है, तो आपको सबसे सुखद भविष्य नहीं मिलेगा। लेकिन बैकअप की आवश्यकता के उज्ज्वल विचार के साथ, सबसे विविध सवालों के एक लाख आते हैं: कहां से शुरू करें? सभी ठिकानों को एक साथ आरक्षित करना, या अलग-अलग करना बेहतर है? एक पूर्ण बैकअप करते हैं? या केवल लॉग को आरक्षित करना बेहतर है? खैर, यह पता लगाने की कोशिश करते हैं।

सबसे पहले, दो बुनियादी सवालों का फैसला किया जाना चाहिए:

1. कंपनी के लिए प्रत्येक व्यक्तिगत डेटाबेस की भूमिका कितनी बड़ी है? और
2. किस अवधि में डेटा हानि स्वीकार्य मानी जा सकती है?

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

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

केवल जब आपके पास इन सवालों के विशिष्ट और अस्पष्ट उत्तर हैं, तो आप बैकअप बनाने के लिए विभिन्न तरीकों के पेशेवरों और विपक्षों का सही आकलन कर सकते हैं।

पूर्ण बैकअप

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

पूर्ण बैकअप से संबंधित मुख्य प्रश्न यह है कि उन्हें कितनी बार किया जाना चाहिए? कोई सार्वभौमिक जवाब नहीं है। यह समझा जाता है कि सप्ताह में कम से कम एक बार पूर्ण आरक्षण किया जाना चाहिए। यदि आपके पास बहुत बड़े डेटाबेस नहीं हैं और बैकअप के लिए जगह के साथ कोई विशेष समस्याएं नहीं हैं, तो शायद दिन में एक बार बैकअप एक अधिक उपयुक्त विकल्प होगा। दूसरी ओर, बहुत अधिक बार पूर्ण बैकअप आपके सर्वर को लोड कर देगा और बैकअप स्टोर करने के लिए अनुचित रूप से बहुत सारे डिस्क स्थान की आवश्यकता होगी। सटीक संख्या आपके डेटाबेस के आकार, सर्वर के प्रदर्शन और लोड, "मूल प्रश्न संख्या दो" के उत्तर पर निर्भर करती है, और कितनी बार आप अन्य प्रकार के बैकअप बनाएंगे, उदाहरण के लिए, लॉग बैकअप या अंतर बैकअप।

बैकअप लॉग करें

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

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

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

विभेदक बैकअप

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

पोस्टस्क्रिप्ट के बजाय

अंत में, मैं आपको कुछ सलाह देना चाहूँगा जिन्हें मुख्य कथा में जगह नहीं मिली, लेकिन जिनके बारे में चुप रहना बहुत ज़रूरी है।

• प्रतिलिपि करने से पहले प्रत्येक डेटाबेस की जांच करने के लिए DBCC CHECKDB का उपयोग करें, यह आपको आसन्न समस्याओं के समय पर तरीके से चेतावनी देगा।
• यह सत्यापित करने के लिए कि सब कुछ ठीक हो गया, चेक-इन विकल्प के साथ बैकअप का उपयोग करें। इस समाधान का नुकसान यह है कि बड़े डेटाबेस के लिए, चेकसम सत्यापन सिस्टम को गंभीरता से लोड कर सकता है।
• यदि आपको बैकअप स्टोर करने के लिए उपलब्ध डिस्क स्थान की समस्या है, तो बैकअप विकल्प के साथ बैकअप का उपयोग करें। संपीड़न आपको बैकअप फ़ाइल के कुल आकार को कई बार कम करने की अनुमति देता है, आमतौर पर 3-5। चेकसम सत्यापन के साथ, इस ऑपरेशन का प्रदर्शन पर बहुत गंभीर प्रभाव पड़ता है, खासकर बड़े डेटाबेस के लिए। याद रखें कि संपीड़न विकल्प केवल SQL Server 2008 के एंटरप्राइज़ संस्करण और एंटरप्राइज़ और स्टैंडआर्ट संस्करण 2008R2 के लिए उपलब्ध है। विकास वाले सभी अन्य संस्करण, न तो बैकअप के दौरान बैकअप को संपीड़ित कर पाएंगे, न ही पुनर्प्राप्ति के दौरान "रिलीज़"।
• प्रत्येक बैकअप के लिए एक अलग फाइल बनाएं, सभी बैकअप को एक फाइल में स्टोर न करें। इस मामले में, यदि इस फ़ाइल में कुछ होता है, तो आप एक बैकअप खो देंगे, और सभी नहीं।
• स्वाभाविक रूप से, बैकअप को उसी ड्राइव पर संग्रहीत न करें जहां आपका डेटाबेस संग्रहीत है।
• यदि कोई खतरा है कि किसी और के पास आपके बैकअप तक पहुंच होगी, तो पासवर्ड सुरक्षा या एन्क्रिप्शन का उपयोग करें।
• बैकअप बनाने की प्रक्रिया को स्वचालित करें। यह सरल है और आप यह सुनिश्चित करेंगे कि आपके पास हमेशा डेटाबेस की एक नई प्रति हो।
• यदि आप उनका उपयोग नहीं कर सकते, तो बैकअप बेकार है। इसलिए, नियमित रूप से डेटाबेस बहाल करने में प्रशिक्षित करें, ताकि यदि आवश्यक हो, तो आप तनावपूर्ण स्थिति में सब कुछ जल्दी और सही तरीके से कर सकें।

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