क्या नेटएप स्नैपशॉट का उपयोग बैकअप के रूप में किया जा सकता है?


11

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

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

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


नेटएप स्नैपशॉट्स

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


मैं पूरी तरह से मानता हूं कि मुझे ठीक से समझ नहीं आ रहा है कि नेटएप वॉल्यूम स्नैपशॉट कैसे काम करता है लेकिन अगर मेरी समझ कम या ज्यादा सही है तो नेटएप स्नैपशॉट बैकअप के लिए मेरे मानदंडों को पूरा करने में विफल रहते हैं।

  • वे परमाणु नहीं हैं । "स्नैपशॉट" वास्तव में मूल डेटा का केवल एक समूह है। यदि मूल डेटा अब नहीं है, तो मेटाडेटा बेकार है।
  • स्नैपशॉट सिस्टम से अलग नहीं है। अगर कोई गलत वॉल्यूम हटाता है तो मैं स्नैपशॉट खो देता हूं। यदि नेटएप फाइलर छोटे छोटे बिल्ली के बच्चे में विस्फोट करता है तो मैं बैकअप खो देता हूं। मैं अपने स्नैपशॉट को दूसरे फाइलर में स्थानांतरित करने के लिए SnapMirror का उपयोग कर सकता हूं लेकिन फिर से, यह सिर्फ मेटाडेटा को स्थानांतरित कर रहा है वास्तविक ब्लॉक नहीं। अगर मैं मूल मात्रा खो देता हूं, तो मैं यह नहीं देख सकता कि किसी दूसरे फाइलर को कॉपी किया गया स्नैपशॉट कैसे मदद करेगा।



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


तुम भी पर टोस्टर व्यवस्थापक मेलिंग सूची से कुछ उपयोगी अंतर्दृष्टि / सर्वोत्तम प्रथाओं मिल सकता है teaparty.net/mailman/listinfo/toasters । (डिस्क्लेमर: मैं लिस्ट चलाता हूं।)
मदहैटर

4
मेरा दृढ़ता से मानना ​​है कि बैकअप को ऑफ-साइट और ऑफलाइन दोनों होना चाहिए। दुर्भावनापूर्ण हमलावर एक इलेक्ट्रॉनिक हमले को लॉन्च नहीं कर सकता है जो लॉक बॉक्स में एक टेप को मिटा देता है। एक बार जब आप बैकअप ऑफ़लाइन लेते हैं तो आप एक हमलावर गतिज साधन बना रहे हैं।
इवान एंडरसन

जैसा कि आपने स्वयं प्रश्न में कहा था, आपको पहले से ही पता है कि स्नैपशॉट डेटा की प्रतिलिपि नहीं है। इसलिए SnapMirror की जरूरत है। तो क्यों आप स्नैपशॉट के बारे में पूछ रहे हैं बजाय इसके कि स्नैपशॉट + स्नैपड्रायर एक वैध बैकअप तंत्र है?
२००_सफल

आप अक्सर उन चीजों का बैकअप लेते हैं जो प्रतिबिंबित नहीं होती हैं। उदाहरण के लिए, नॉनप्रोड वातावरण। वे पुनर्निर्माण के लिए एक लंबा समय लेते हैं, लेकिन यदि आप उन्हें खो देते हैं तो व्यवसाय को नीचे नहीं लाएंगे।
तुलसी

जवाबों:


15

बैकअप दो कार्य करता है।

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

कोई अवधारण नीति नहीं

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

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

इस स्थिति पर विचार करें:

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

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

सारांश

Netapp स्नैपशॉट आपको वास्तविक डेटा हानि के विरुद्ध कवर नहीं करता है। फ़ाइल पर एक गलत हटाए गए वॉल्यूम या डेटा हानि से आपको डेटा को फिर से बनाना होगा।

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


Deletion of snapshots is determined only by available snapshot space, and if it needs to delete snapshots that are required for your retention policy- यह कुछ ऐसा है जिस पर मैंने भी विचार नहीं किया। बहुत बढ़िया बिंदु।

आप कुछ मज़ा करना चाहते हैं? लक्ष्य के flexclones के लिए एक स्नैपशॉट की मात्रा पर स्नैपशॉट करने का प्रयास करें। फिर स्रोत पर गैर-आरक्षित स्थान के 100% का उपयोग करने का प्रयास करें। यह तब तक काम करता है जब तक स्नैपशॉट समर्थन नहीं करता कि फ्लेक्सक्लोन स्रोत मात्रा पर हटा दिया जाता है, जिस बिंदु पर प्रतिकृति बंद हो जाती है
तुलसी

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

बैकअप के दो (तुलनात्मक रूप से महत्वपूर्ण) कार्यों के बीच अच्छा अंतर, जिसे क्रमशः आपदा वसूली और मोरन रिकवरी के रूप में संदर्भित किया जा सकता है।
मैडहैटर

8

वे एक बैकअप हैं, हाँ। मैंने व्यक्तिगत रूप से उन्हें दैनिक वृद्धिशील की जगह पहले इस्तेमाल किया है, लेकिन हमने अभी भी टेप करने के लिए साप्ताहिक पूर्ण किया है।

वे किसी भी गैर-नेटएप्प (सिस्टम तक पहुँचने वाले सिस्टम) उपयोगकर्ता या व्यवस्थापक त्रुटियों या समस्याओं से काफी अच्छी तरह से रक्षा करते हैं।

वे स्वयं नेटैप की भयावह हार्डवेयर विफलताओं से रक्षा नहीं करते हैं। मेरी समझ यह है कि SnapMirror दूसरे फाइलर [1] में सभी डेटा (स्नैपशॉट में) की प्रतिलिपि बनाता है, इसलिए SnapMirroring से दूसरे फाइलर को उस डेटासेट को किसी एक फाइलर की भयावह विफलता से सुरक्षित रखना चाहिए।

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

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

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

यदि यह मैं होता, तो मैं सभी डेटाबेस को स्थानीय डिस्क पर नियमित बैकअप करने के लिए सेट करता, और उन नौकरियों को एक या दो कॉपी रखने के लिए सेट करता। इससे आपको रिकवरी की बेहतर गारंटी मिलती है।

[१] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us


एक और फाइलर के लिए SnapMirroring का उल्लेख करने के लिए +1; लोग उस कार्यक्षमता को नजरअंदाज करने लगते हैं।
मध्याह्न

1
एक और फाइलर के लिए स्नैपचैट करने से आप अपने रिकवरी पॉइंट को छोटा करते हुए स्नैपशॉट ऑटोडेट से नहीं बचेंगे। यह वॉल्यूम हटाने और फाइलर के नुकसान से बचाता है, हालांकि।
तुलसी

2

आपको अभी @Basil का शानदार जवाब पढ़ना चाहिए लेकिन यहाँ मेरे दो सेंट हैं:

स्नैपशॉट आवेदन के बारे में पता नहीं हैं

सिर्फ इसलिए कि आप अंतर्निहित स्टोरेज वॉल्यूम का स्नैपशॉट लेते हैं इसका मतलब यह नहीं है कि उस वॉल्यूम पर डेटा पुनर्प्राप्त करने योग्य है। MS SQL इसका एक बेहतरीन उदाहरण है - आपको यह सुनिश्चित करने की आवश्यकता है कि आपके डेटाबेस का लेन-देन सुसंगत है, इससे पहले कि आप इसे स्टोरेज को स्नैपशॉट के रूप में उपयोग कर रहे हैं, जैसा कि @freiit ने उल्लेख किया है कि आप हार्ड डाउन विफलता से उबरने से बेहतर नहीं हैं। DBAs को एसक्यूएल के विभिन्न हिस्सों के लिए अलग-अलग LUN का उपयोग करने के लिए स्टोरेज सिस्टम, तेज स्टोरेज पर अस्थायी डेटाबेस, धीमे स्टोरेज पर सिस्टम डेटाबेस, बल्क स्टोरेज पर रीड-ओनली या आर्काइव्ड डेटा और बीच में कहीं डेटा का उपयोग करना पसंद है। यदि आप केवल उन संस्करणों को स्नैपशॉट कर रहे हैं, तो यह अत्यधिक संभावना नहीं है कि आप अपने डेटाबेस को पुनर्प्राप्त कर पाएंगे।

NetApp स्नैपशॉट एप्लिकेशन को जागरूक करने के लिए कई स्नैप टूल की आपूर्ति करता है। SQL के लिए SnapManager उस जागरूकता को प्रदान करता है। Microsoft पारिस्थितिकी तंत्र में मेरा मानना ​​है कि एक्सचेंज और SharePoint के लिए SnapManager उपकरण भी हैं। SnapDrive में यह एप्लिकेशन जागरूकता नहीं है। यह सिर्फ अतिथि के भीतर भंडारण का प्रबंधन करने के लिए एक सुविधाजनक तरीका प्रदान करता है।

यदि आप LUN पर अपने सभी IIS डेटा और कॉन्फ़िगरेशन को संग्रहीत कर रहे हैं और उन LUN को सीधे स्नैप कर रहे हैं, तो आप यह गारंटी नहीं दे सकते कि डेटा पुनर्प्राप्त करने योग्य है। मुझसे पूछो कि मैं कैसे जानता हूं ...


एकाधिक संग्रहण प्रकारों में अलग-अलग स्नैपशॉट शेड्यूल हो सकते हैं

यदि आप अलग-अलग तरीकों से अपने सर्वर पर संग्रहण प्रस्तुत कर रहे हैं तो यह आपके स्नैपशॉट और पुनर्प्राप्ति चित्र को जटिल कर सकता है। NetApp का ONTAP एक बहु-प्रोटोकॉल पेशकश है और यह बहुत संभव है कि आप किसी विशेष सर्वर के लिए एक से अधिक विधि या संग्रहण प्रकार का उपयोग कर रहे हों। हमारी दुकान में हमारे कुछ सर्वरों को NFS- आधारित डेटास्टोर पर उनका C: \ ड्राइव मिलता है और रॉ डिवाइस मैप्ड LUN पर उनकी "स्टोरेज" ड्राइव। हम RDM LUN के स्नैपशॉट ले रहे थे, लेकिन NFS आधारित डेटस्टोर्स नहीं। इससे सर्वर ठीक हो गया, मुश्किल हो गया।


स्नैपशॉट में गारंटीकृत अवधारण नीति नहीं है

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


स्नैपशॉट इनलाइन हैं

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


स्नैपशॉट खराब परिचालन प्रथाओं को जारी रखने में सक्षम बनाता है

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

और फिर स्नैपशॉट आओ! हमें अपने कुछ मौलिक परिचालन अभ्यासों को वापस करने और उन्हें संबोधित करने की आवश्यकता नहीं है क्योंकि हम अपने सभी सर्वरों को केवल स्नैपशॉट दे सकते हैं! और हम उन स्नैपशॉट को ऑफ-साइट स्थानांतरित करने के लिए SnapMirror का उपयोग कर सकते हैं ताकि हम उन्हें बैकअप के रूप में उपयोग कर सकें!

मुझे लगता है कि यह यहां सीखने का गलत सबक है। सीखने के लिए एक बेहतर सबक यह है कि विन्यास प्रबंधन ढांचा, भले ही यह चैंज की तरह सरल हो, नंगे-धातु की बहाली के उद्देश्यों के लिए बैकअप होना चाहिए। स्नैपशॉट एक शानदार उपकरण है, लेकिन मुझे वहाँ महत्वपूर्ण बुनियादी बातों के उल्लंघन के लिए उन पर अत्यधिक निर्भर होने का एक प्रलोभन है।

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