अक्सर, मैं देखता हूं कि लोग बैकअप रणनीतियों के बारे में प्रश्न पूछते हैं जिन्हें उन्हें अपने डेटाबेस के लिए नियोजित करना चाहिए। ऐसा लगता है कि यह कभी विफल नहीं होता है, इस तरह के हर प्रश्न जो मैंने विभिन्न मंचों में देखे हैं, उनमें कभी भी उनकी पुनर्प्राप्ति आवश्यकताओं को शामिल नहीं किया जाता है। मैं अक्सर आपकी बैकअप रणनीति तैयार करने से पहले आपकी पुनर्प्राप्ति आवश्यकताओं पर विचार करने के लिए स्टम्प्ड हो जाता हूं। आवश्यकताओं के लिए दबाए जाने पर, मुझे अक्सर बैकअप आवश्यकताएं मिलेंगी, उदाहरण के लिए:
- बैकअप में कोई डाउनटाइम नहीं होना चाहिए
- संग्रहीत पुन:लॉग का बैकअप लेने में सक्षम होने की आवश्यकता है
- बैकअप टेप करने के लिए लिखा जाना चाहिए
ये आवश्यकताएं अच्छी और अच्छी हैं, लेकिन मेरी राय में, आपको पहले अपनी पुनर्प्राप्ति आवश्यकताओं का दस्तावेजीकरण किए बिना और प्रबंधन घटना प्राप्त किए बिना अपनी बैकअप रणनीति तैयार नहीं करनी चाहिए।
तो यहां कुछ प्रश्न हैं जो मैं बैकअप रणनीति तैयार करते समय खुद से पूछता हूं। ध्यान दें कि ये सभी प्रश्न चीजों के पुनर्प्राप्ति पक्ष पर केंद्रित हैं।
- डेटाबेस को पुनर्स्थापित करने पर मैं कितना डेटा हानि उठा सकता हूं? शून्य डेटा हानि? क्या डेटाबेस की पुनर्प्राप्ति के बाद एक घंटे का डेटा हानि स्वीकार्य है?
- क्या मुझे किसी भी लेन-देन को आगे बढ़ाने की ज़रूरत है, यानी पॉइंट-इन-टाइम रिस्टोर करना है?
- क्या मुझे अन्य स्कीमाओं को बरकरार रखते हुए एक स्कीमा की सामग्री को पुनर्स्थापित करने की आवश्यकता होगी?
- एक विफलता के बाद मुझे डेटाबेस को कब तक चालू और चालू करना होगा?
- मुझे किस तरह की विफलताओं से उबरने की आवश्यकता है? जाहिर है, मुझे एक पूर्ण सर्वर विफलता या डिस्क के नुकसान से पुनर्स्थापित करने में सक्षम होना चाहिए। लेकिन क्या मुझे किसी ऐसे व्यक्ति की तरह मानवीय विफलताओं से उबरने में सक्षम होने की आवश्यकता है जिसने गलती से किसी तालिका को हटा दिया हो?
- क्या मुझे उत्पादन की एक प्रति से ताज़ा विकास या परीक्षण डेटाबेस के भाग के रूप में अन्य सर्वरों पर बैकअप को पुनर्स्थापित करने की आवश्यकता होगी?
यदि आप इन दिनों Oracle समुदाय के अधिकांश लोगों से पूछते हैं, तो वे आपको अपने डेटाबेस का बैकअप लेने के लिए RMAN का उपयोग करने के लिए कहेंगे। RMAN एक बेहतरीन उत्पाद है और कई चीजों के लिए, पुरानी शैली के उपयोगकर्ता प्रबंधित हॉट या कोल्ड बैकअप से बेहतर है। कुछ Oracle DBA आपको हॉट बैकअप करने और अपने प्रोडक्शन डेटाबेस को आर्काइव लॉग मोड में चलाने के लिए RMAN का उपयोग करने के लिए कहेंगे। ऐसा करने से, आप कई पुनर्प्राप्ति परिदृश्यों को कवर करेंगे जिनका आपको सामना करने की संभावना है। लेकिन क्या होगा यदि प्रश्न 4 का आपका उत्तर यह है कि आपके पास बैकअप लेने और चलाने के लिए 1 घंटा है और आपका डेटाबेस आकार में 10TB है। RMAN के साथ 1 घंटे में 10TB डेटाबेस को पूरी तरह से पुनर्स्थापित करने का प्रयास करने में शुभकामनाएँ। और RMAN प्रश्न 3 में मदद नहीं कर पाएगा क्योंकि RMAN स्कीमा-स्तर पर बैकअप नहीं लेता है।
डेटाबेस में डेटा का बैकअप लेने और पुनर्प्राप्त करने के लिए DBA के निपटान में कई उपकरण हैं। उन टूल में शामिल हैं, लेकिन ये भी सीमित नहीं हैं:
- Oracle का रिकवरी मैनेजर (RMAN)
- Oracle उपयोगकर्ता-प्रबंधित बैकअप
- Oracle निर्यात/आयात या डेटा पंप
- डिस्क आधारित स्नैपशॉट
- डिस्क आधारित प्रतिकृति
- Oracle का डेटा गार्ड
तो आप किसका उपयोग करते हैं? वैसे प्रत्येक के अपने फायदे और नुकसान हैं। एक बार जब आप अपनी पुनर्प्राप्ति आवश्यकताओं को जान लेते हैं, तो आपके डेटाबेस का बैकअप लेने के लिए उपकरण स्पष्ट होने लगते हैं। और आपको अपनी सभी पुनर्प्राप्ति आवश्यकताओं को पूरा करने के लिए एक से अधिक बैकअप टूल को नियोजित करने की आवश्यकता हो सकती है। यदि आप कुछ सुझाव के रूप में, आर्काइव लॉग मोड के साथ RMAN का उपयोग करते हैं और कुछ नहीं, और आपका प्रबंधक आपके पास आता है और कहता है "आपको इस 10TB डेटाबेस को 1 घंटे में बैक अप और चलाने की आवश्यकता है!" आपका काम अच्छी तरह से लाइन पर हो सकता है।
जो अगले बिंदु की ओर ले जाता है, अपनी पुनर्प्राप्ति आवश्यकताओं का दस्तावेजीकरण करें और उन्हें अपने सेवा स्तर अनुबंध (SLA) में शामिल करें। SLA लिखते और उसकी समीक्षा करते समय, आपका प्रबंधन कह सकता है कि वे शून्य डेटा हानि चाहते हैं। यह इस समय है कि आप शून्य डेटा हानि समाधान को लागू करने के लिए पेशेवरों और विपक्षों को ला सकते हैं … और लागतों का भी उल्लेख कर सकते हैं! कई कंपनियां शून्य डेटा हानि समाधान की उच्च लागत पर झुकती हैं लेकिन अन्य कंपनियों के लिए, किसी भी लेनदेन को खोने के वित्तीय बोझ की तुलना में लागत कम होती है। यहीं से सौदेबाजी और वस्तु विनिमय चलन में आते हैं। यदि प्रबंधन शून्य डेटा हानि समाधान पर जोर देता है, तो उन्हें इसका समर्थन करने के लिए धन के साथ आना होगा क्योंकि आरएमएएन (फ्री) इसे प्रदान नहीं करने जा रहा है। एक बार जब आप SLA में अपनी पुनर्प्राप्ति आवश्यकताओं का दस्तावेजीकरण कर लेते हैं, तो प्रबंधन के लिए आपसे कुछ ऐसा पुनर्प्राप्त करने के लिए कहना मुश्किल होगा, जिसे समर्थन देने के लिए आपकी बैकअप रणनीति तैयार नहीं की गई है। यदि SLA मौजूद है और वे आपसे प्रत्येक लेन-देन को पुनर्प्राप्त करने के लिए कहते हैं और आपकी बैकअप रणनीति इसकी अनुमति नहीं देगी, तो आपके पास एक दस्तावेज़ है जो कहता है कि शून्य डेटा हानि की कभी आवश्यकता नहीं थी और यह आपकी नौकरी को बचाने में मदद कर सकता है। पी>
कहा जा रहा है, एक बार जब आप SLA में अपनी पुनर्प्राप्ति आवश्यकताओं का दस्तावेजीकरण कर लेते हैं, तो सुनिश्चित करें कि आपकी बैकअप रणनीति आपको SLA में दर्ज़ किए गए प्रत्येक पुनर्प्राप्ति परिदृश्य को निष्पादित करने की अनुमति देगी। आपका काम इस पर निर्भर हो सकता है। यदि SLA शून्य डेटा हानि कहता है और आप डेटा गार्ड को लागू नहीं करते हैं, भले ही प्रबंधन इसे निधि देने के लिए तैयार था, तो वे आपको समाप्त कर सकते हैं क्योंकि आप अपने काम का पालन नहीं कर रहे थे।
अंत में, कोई भी बैकअप/पुनर्प्राप्ति रणनीति तब तक पूरी नहीं होती जब तक कि इसका पूरी तरह से परीक्षण नहीं किया जाता है। आपको यह सुनिश्चित करने के लिए प्रत्येक आवश्यक पुनर्प्राप्ति रणनीति का परीक्षण करना चाहिए कि आप SLA में बताई गई सभी आवश्यकताओं को पूरा कर सकते हैं। परीक्षण दो कारणों से वर्ष में एक बार से कम नहीं किया जाना चाहिए ... एक, यह सुनिश्चित करता है कि सिस्टम में परिवर्तन आवश्यक पुनर्प्राप्ति करने की आपकी क्षमता को नकारात्मक रूप से प्रभावित नहीं करते हैं और दूसरा, आपको पुनर्प्राप्ति करने के तरीके के बारे में अप-टू-डेट रखता है ताकि यदि आपको इसे वास्तविक रूप से करना है, तो आप प्रक्रिया के लिए लड़खड़ा नहीं रहे हैं। परीक्षण में, आप पा सकते हैं कि आपकी बैकअप पद्धति पुनर्प्राप्ति परिदृश्यों का समर्थन करेगी जो आवश्यक हैं, लेकिन यदि आपको उनकी आवश्यकता है तो अच्छा है।
और मैं इसे पर्याप्त नहीं कह सकता... परीक्षण, परीक्षण और परीक्षण!