SQL बैकअप पर "बैकअप अक्षतता सत्यापित करें" बंद करने के प्रभाव / जोखिम को समझना


12

वर्तमान में हम अपने वातावरण में SQL Server 2005/2008 / 2008R2 / 2012 सर्वर पर बैकअप के लिए मानक रखरखाव योजनाओं का उपयोग करते हैं, और "बैकअप अक्षतता सत्यापित करें" बॉक्स हमेशा चेक किया गया है।

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

मैं इस विकल्प के उपयोग और इतिहास को समझता हूं, बैकअप कार्य के लिए समय को दोगुना करना मेरे लिए अनावश्यक लगता है जब (मेरी राय में), कोई भी त्रुटि जो बैकअप चरण के दौरान होने की संभावना है , सत्यापन के दौरान नहीं।

क्या मै गलत हु? क्या यह बंद करने के लिए कम से कम जोखिम है, अगर मैं डिस्क का बैकअप ले रहा हूं और टेप या कुछ और स्ट्रीमिंग नहीं कर रहा हूं? (यदि यह प्रासंगिक है तो हम नेटवर्क को EMC DD-800 बैकअप उपकरण पर वापस कर देते हैं।)

क्या इस बंद करने के लिए सुरक्षित होने के लिए कोई आधिकारिक एमएस सिफारिशें हैं?

क्या आप अपने वातावरण में हर बैकअप पर "सत्यापन" चलाते हैं? क्या आप उनकी जांच करते हैं?

संपादित करें :, स्पष्ट करने के लिए जब आप की जाँच रखरखाव योजना में "बैकअप अखंडता को सत्यापित", एसक्यूएल एक पूर्ण करना होगा VERIFYONLY पुनर्स्थापित प्रत्येक डेटाबेस पर तुरंत प्रत्येक बैकअप के बाद। यह मूल बैकअप के समान ही डेटा / आईओ गहन है, और (मूल रूप से) बैकअप नौकरी के समग्र समय को दोगुना कर देता है। यह बैकअप पर "चेकसम" विकल्प को सक्षम करने के समान नहीं है (जो विज़ार्ड में नहीं किया जा सकता है, जहां तक ​​मुझे पता है)।


सभी को धन्यवाद। SQL अनुरक्षण योजनाओं का उपयोग करते समय, बैकअप पर चेकसम को सक्षम करने के लिए ट्रेस ध्वज का उपयोग करने के बारे में मेरे स्वयं के संदर्भ के लिए एक और लिंक जोड़ना: nebraskasql.blogspot.com/2014/03/…
ब्रैड

जवाबों:


5

क्या मै गलत हु? क्या यह बंद करने के लिए कम से कम जोखिम है, अगर मैं डिस्क का बैकअप ले रहा हूं और टेप या कुछ और स्ट्रीमिंग नहीं कर रहा हूं?

नहीं, आप सही हैं :-)

RESTORE VERIFYONLYकेवल यह सुनिश्चित नहीं करेगा कि आप भ्रष्टाचार की स्थिति में अपने डेटाबेस को पुनर्प्राप्त कर पाएंगे। स्वभाव से, यह कोई अखंडता जांच नहीं करेगा।

एक बेहतर तरीका यह होगा कि आप समय-समय पर अपने बैकअप लें और एक अलग सर्वर पर एक वैध पुनर्स्थापना करें और उस पर DBCC CHECKDB प्रदर्शन करें।

यह एक कारण है, क्यों मैं रखरखाव योजनाओं का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि जीयूआई बहुत सारे विकल्पों को उजागर नहीं करता है जैसे backup .. with CHECKSUMकि टी-एसक्यूएल द्वारा प्राप्त किया जा सकता है।

से पॉल रैंडल के मिथक ब्लॉग

24p) का उपयोग कर… अधिक पूरी तरह से बैकअप की पुष्टि करता है

नहीं। केवल वैयक्तिकृत का उपयोग करने से केवल बैकअप हेडर बैकअप हेडर की तरह दिखता है। यह केवल तभी होता है जब आप CHECKSUM के साथ बैकअप का उपयोग करते हैं और RESTORE करते हैं ... पूरी तरह से और CHECKSUM के साथ उपयोग करते हुए कि पुनर्स्थापना पूरे बैकअप पर चेकसम सहित अधिक व्यापक चेक करता है।

क्या आप अपने वातावरण में हर बैकअप पर "सत्यापन" चलाते हैं? क्या आप उनकी जांच करते हैं?

मैं बहुत भाग नहीं करता। इसके बजाय मैं CHECKSUM के साथ बैकअप लेता हूं और फिर उन्हें एक अलग सर्वर पर + CHECKDB'ed पुनर्स्थापित किया है। यदि आप रचनात्मक बनना चाहते हैं, तो आप डेटाबेस बैकअप सत्यापन के लिए सांख्यिकीय नमूने का पालन कर सकते हैं ।

यह बैकअप पर "चेकसम" विकल्प को सक्षम करने के समान नहीं है (जो विज़ार्ड में नहीं किया जा सकता है, जहां तक ​​मुझे पता है)।

आप सक्षम कर सकते हैं ट्रेस ध्वज 3023 ताकि CHECKSUMविकल्प स्वचालित रूप से बैकअप आदेश के लिए सक्षम है। हमेशा की तरह, अपने वातावरण में किसी भी ट्रेस झंडे के व्यवहार का परीक्षण करें!

लब्बोलुआब यह है कि - रखरखाव की योजनाएं और अधिक समझदार बैकअप समाधान (संकेत: ओला का बैकअप समाधान) का उपयोग करें जो आपको अपनी आवश्यकताओं के आधार पर इसे अनुकूलित करने की अनुमति देगा।

(यदि यह प्रासंगिक है तो हम नेटवर्क को EMC DD-800 बैकअप उपकरण पर वापस कर देते हैं।)

स्थानीय रूप से डिस्क पर बैकअप लें और फिर एक PowerShell स्थानांतरण कार्य करें जो बैकअप को सर्वर से नेटवर्क साझा (बैकअप सर्वर) में स्थानीय रूप से कॉपी करेगा। यह एक नेटवर्क शेयर को सीधे कॉपी करने की तुलना में अधिक तेज़ होगा।

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

एक अच्छा पढ़ा जाएगा: बैकअप: रिकवरी रणनीति की योजना बनाना


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

@ ब्रैड ग्लैड कि मेरा उत्तर आपके लिए उपयोगी है। मेरे उत्तर का अभिप्राय विरोधाभासों (मुख्य योजनाओं) के TSQLरूप में उपयोग करना है GUIताकि आप लचीलेपन का लाभ उठा सकें और इसे खुले हाथों से अनुकूलित कर सकें। एक FYI के रूप में .. रखरखाव योजनाओं को SQL Server 2016 में बढ़ाया गया है CTP 2.4जिसे MS SQL सर्वर स्मार्ट रखरखाव योजना के रूप में कहता है - सर्वोत्तम प्रथाओं को एकीकृत करता है, और मक्खी पर इष्टतम रणनीतियों की पहचान कर सकता है। फिर भी कोई GUI TSQL :-)
परिजन शाह

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

2

लब्बोलुआब यह है कि जब तक आप एक डेटाबेस को कहीं भी बहाल नहीं करते हैं, आप पूरी तरह से आश्वस्त नहीं हो सकते हैं कि किसी दिए गए बैकअप फ़ाइल अच्छी है।

आपके बैकअप को सत्यापित करने के लिए आदर्श परीक्षण एक ऐसे वातावरण को सेटअप करना है जहां डेटाबेस बैकअप, और डेटाबेस लॉग बैकअप, को आपके दिन-प्रतिदिन की प्रक्रिया के हिस्से के रूप में हर समय बहाल किया जाता है। यह लॉग-शिपिंग का उपयोग करने के लाभों में से एक है ...

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

अंत में, क्या आपने रखरखाव योजनाओं से दूर जाने पर विचार किया है? ओला की लिपियों जैसे स्क्रिप्ट बैकअप और रखरखाव के अलावा हैं: https://ola.hallengren.com/


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

1

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


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

सही है, केवल वास्तविक चेक imo वास्तव
MrG
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.