खराब मॉड अपडेट के बाद आपकी Minecraft दुनिया दूषित हो जाती है। टूटे हुए परिनियोजन के बाद आपका डिस्कॉर्ड बॉट डेटाबेस गायब हो गया है। आपका वीपीएस ऑनलाइन है, लेकिन जिन फ़ाइलों की आपको वास्तव में आवश्यकता है वे ऑनलाइन नहीं हैं। यही कारण है कि सर्वर बैकअप केवल मायने रखता है - क्योंकि अकेले अपटाइम आपके डेटा को नहीं बचाता है।
बैकअप आपके सर्वर डेटा की एक उपयोगी प्रति है जिसे आप बाद में पुनर्स्थापित कर सकते हैं। कोई वादा नहीं. ऐसा स्नैपशॉट नहीं जिसका आपने कभी परीक्षण नहीं किया। यह वह फ़ोल्डर नहीं है जिसे आप पिछले महीने डाउनलोड करना चाहते थे। एक वास्तविक बैकअप आपको कुछ विफल होने के बाद फ़ाइलों, डेटाबेस, कॉन्फ़िगरेशन और कभी-कभी पूरे सिस्टम को पुनर्प्राप्त करने देता है।
छोटे समुदायों, बॉट डेवलपर्स और गेम सर्वर व्यवस्थापकों के लिए, बैकअप केवल एंटरप्राइज़ सुविधा नहीं है। वे सामान्य समस्याओं के विरुद्ध बुनियादी सुरक्षा हैं: मानवीय त्रुटि, विफल अपडेट, हैक किए गए खाते, डिस्क समस्याएं, खराब प्लगइन्स और आकस्मिक डिलीट। यदि आपका प्रोजेक्ट 24/7 चलता है, तो बैकअप भी विश्वसनीय रूप से चलना चाहिए।
सर्वर बैकअप को सरलता से समझाया गया: बैकअप में वास्तव में क्या शामिल होता है
अधिकांश लोग सोचते हैं कि बैकअप का मतलब हर चीज़ की प्रतिलिपि बनाना है। कभी-कभी यह सच होता है, लेकिन अक्सर यह बेकार होता है। एक अच्छा बैकअप उस डेटा को कवर करता है जिसे खोने से नुकसान हो सकता है और सेवा को तेजी से वापस लाने के लिए आवश्यक टुकड़े भी शामिल होते हैं।
गेम सर्वर पर, इसका मतलब आमतौर पर विश्व डेटा, प्लेयर डेटा, कॉन्फ़िगरेशन फ़ाइलें, प्लगइन फ़ोल्डर्स और कस्टम संपत्तियां होती हैं। डिस्कॉर्ड बॉट पर, इसका मतलब स्रोत कोड, पर्यावरण कॉन्फ़िगरेशन, अपलोड की गई संपत्ति और विशेष रूप से डेटाबेस हो सकता है।वीपीएस पर, इसमें वेबसाइट फ़ाइलें, डेटाबेस, सिस्टम कॉन्फ़िगरेशन, एसएसएल फ़ाइलें, शेड्यूल की गई नौकरियां और परिनियोजन स्क्रिप्ट शामिल हो सकती हैं।
मुख्य विचार सरल है: यदि इसे नए सिरे से बनाने में समय, पैसा लगेगा, या डाउनटाइम का कारण होगा, तो यह संभवतः आपकी बैकअप योजना में शामिल है।
इसका मतलब यह नहीं है कि प्रत्येक बैकअप में संपूर्ण ऑपरेटिंग सिस्टम शामिल होना चाहिए। पूर्ण सर्वर छवियां उपयोगी होती हैं, लेकिन वे बड़ी होती हैं, संग्रहीत करने में धीमी होती हैं, और प्रत्येक पुनर्स्थापना परिदृश्य के लिए हमेशा आवश्यक नहीं होती हैं। कभी-कभी आपको एक डेटाबेस तालिका की आवश्यकता होती है, संपूर्ण मशीन रोलबैक की नहीं। यहीं पर बैकअप प्रकार मायने रखते हैं।
तीन बैकअप प्रकार जिन्हें अधिकांश उपयोगकर्ताओं को जानना आवश्यक है
एक पूर्ण बैकअप दायरे में मौजूद हर चीज़ की प्रतिलिपि बनाता है। इसे समझना सबसे आसान है और इसे पुनर्स्थापित करना भी सबसे आसान है, लेकिन यह सबसे अधिक संग्रहण का उपयोग करता है और इसे बनाने में अधिक समय लग सकता है।
एक वृद्धिशील बैकअप केवल वही सहेजता है जो किसी भी प्रकार के अंतिम बैकअप के बाद से बदल गया है। यह कुशल और तेज़ है, जो इसे बार-बार बैकअप शेड्यूल के लिए बढ़िया बनाता है। व्यापार-बंद जटिलता को पुनर्स्थापित करना है। यदि श्रृंखला में एक लिंक गायब या क्षतिग्रस्त है, तो पुनर्प्राप्ति गड़बड़ हो सकती है।
एक विभेदक बैकअप पिछले पूर्ण बैकअप के बाद से बदली गई सभी चीज़ों को सहेजता है। यह बीच में बैठता है. वृद्धिशील बैकअप की तुलना में पुनर्स्थापना आसान है, लेकिन भंडारण का उपयोग समय के साथ बढ़ता है जब तक कि अगला पूर्ण बैकअप चक्र को रीसेट नहीं कर देता।
अधिकांश छोटी तैनाती के लिए, सबसे अच्छा सेटअप किसी एक को हमेशा के लिए नहीं चुनना है। यह उनका संयोजन कर रहा है. साप्ताहिक पूर्ण बैकअप और दैनिक वृद्धिशील बैकअप आम है क्योंकि यह गति, भंडारण और पुनर्प्राप्ति समय को संतुलित करता है।
सर्वर बैकअप आपको किससे सुरक्षा नहीं देता है?
बैकअप पुनर्प्राप्ति में सहायता करता है। वे सुरक्षा, निगरानी या रखरखाव का स्थान नहीं लेते।
यदि आपके सर्वर से छेड़छाड़ हो जाती है और हमलावर आपका बैकअप भी हटा देता है, तो आपकी योजना विफल हो गई है। यदि रैंसमवेयर उत्पादन डेटा और कनेक्टेड बैकअप स्टोरेज दोनों को एन्क्रिप्ट करता है, तो आपकी योजना विफल हो गई है। यदि आपके पास बैकअप हैं लेकिन कभी भी रिस्टोर का परीक्षण नहीं किया है, तो आप वास्तव में नहीं जानते कि वे काम करते हैं या नहीं।
यही कारण है कि स्मार्ट सेटअप उत्पादन को बैकअप स्टोरेज से अलग करते हैं और कई संस्करण रखते हैं। एक मौजूदा बैकअप किसी भी बैकअप से बेहतर नहीं है। एकाधिक पुनर्स्थापना बिंदु एक से बेहतर हैं। ऑफ़लाइन या पृथक प्रतिलिपियाँ अभी भी बेहतर हैं।
बहुत सारा डाउनटाइम घटना के बाद होता है, उसके दौरान नहीं। तकनीकी विफलता एक समस्या है. धीमी, भ्रमित पुनर्स्थापना प्रक्रिया बड़ी है।
आपको कितनी बार सर्वर का बैकअप लेना चाहिए?
यह इस बात पर निर्भर करता है कि डेटा में कितना परिवर्तन होता है और इसके कुछ घंटे खोना कितना दर्दनाक होगा।
यदि आप एक छोटा निजी प्रोजेक्ट चलाते हैं जो सप्ताह में एक बार बदलता है, तो दैनिक बैकअप पर्याप्त से अधिक हो सकता है। यदि आप एक सक्रिय होस्ट करते हैंमाइनक्राफ्ट सर्वर, खिलाड़ी की प्रगति हर मिनट बदल सकती है। यदि आपका डिस्कोर्ड बॉट पूरे दिन टिकट, इकोनॉमी डेटा, लॉग या उपयोगकर्ता सेटिंग्स लिखता है, तो छह घंटे भी बर्बाद करना एक वास्तविक समस्या हो सकती है।
एक बेहतर प्रश्न यह है: आप कितना डेटा खोने का जोखिम उठा सकते हैं? यह आपका पुनर्प्राप्ति बिंदु लक्ष्य है, भले ही आप इसे ऐसा कभी न कहें।
यदि उत्तर एक दिन है, तो कम से कम प्रतिदिन बैकअप लें। यदि उत्तर एक घंटा है, तो दैनिक बैकअप पर्याप्त नहीं है। सक्रिय वातावरण के लिए, कई व्यवस्थापक एक स्तरित दृष्टिकोण का उपयोग करते हैं: लगातार डेटाबेस बैकअप, दैनिक एप्लिकेशन बैकअप और साप्ताहिक पूर्ण सिस्टम बैकअप।
आपको प्रतिधारण के बारे में भी सोचने की ज़रूरत है। केवल नवीनतम बैकअप रखना जोखिम भरा है। यदि भ्रष्टाचार तीन दिन पहले शुरू हुआ और आपने इसे अभी नोटिस किया है, तो आपके नवीनतम बैकअप में पहले से ही समस्या हो सकती है। कई संस्करण रखने से आपको साफ़ डेटा पुनर्प्राप्त करने की गुंजाइश मिलती है।
गेम सर्वर, बॉट और वीपीएस उपयोगकर्ताओं के लिए सर्वर बैकअप को सरलता से समझाया गया है
गेम सर्वर के लिए, निरंतरता मायने रखती है। जब दुनिया सक्रिय रूप से सहेज रही हो तो लाइव फ़ाइलों की प्रतिलिपि बनाने से पुनर्स्थापना टूट सकती है। कुछ प्लेटफ़ॉर्म और स्क्रिप्ट इसे अच्छी तरह से संभालते हैं, लेकिन सामान्य नियम सरल है: बैकअप इस तरह से बनाएं कि आधा-अधूरा लिखा डेटा कैप्चर न हो। कम गतिविधि वाली विंडोज़ के दौरान शेड्यूल किए गए बैकअप से मदद मिलती है।
के लिए कलह बॉट, डेटाबेस अक्सर बॉट कोड से अधिक मूल्यवान होता है। कोड आमतौर पर संस्करण नियंत्रण में रहता है या फिर से तैनात किया जा सकता है। उपयोगकर्ता-जनित डेटा नहीं कर सकता. यदि आपका बॉट मॉडरेशन इतिहास, लेवलिंग डेटा, टिकट या सर्वर सेटिंग्स संग्रहीत करता है, तो पहले डेटाबेस बैकअप को प्राथमिकता दें।
वीपीएस उपयोगकर्ताओं के लिए, सबसे बड़ी गलती यह मान लेना है कि प्रदाता सब कुछ स्वचालित रूप से संभाल लेता है। कुछ होस्ट स्नैपशॉट या प्रबंधित बैकअप प्रदान करते हैं, कुछ नहीं करते हैं, और कुछ केवल बुनियादी ढांचे-स्तर की विफलता को कवर करते हैं। यह उपयोगी है, लेकिन यह आपको अपनी गलतियों से नहीं बचा सकता है। यदि आप अपनी ऐप फ़ाइलें हटाते हैं या किसी डेटाबेस को ओवरराइट करते हैं, तो इंफ्रास्ट्रक्चर रिडंडेंसी जादुई रूप से आपके प्रोजेक्ट को पुनर्स्थापित नहीं करती है।
इसीलिए यह जांचना उचित है कि आपके पास वास्तव में किस प्रकार का बैकअप है: फ़ाइल-स्तर, डेटाबेस-स्तर, स्नैपशॉट-आधारित, या पूर्ण छवि बैकअप। पुनर्स्थापना परिणाम की तुलना में नाम कम मायने रखता है।
व्यवहार में एक अच्छी बैकअप रणनीति कैसी दिखती है
डिज़ाइन के हिसाब से एक अच्छी बैकअप रणनीति उबाऊ होती है। यह शेड्यूल पर चलता है, डेटा को एक अलग स्थान पर संग्रहीत करता है, कई पुनर्स्थापना बिंदु रखता है, और आपात्कालीन स्थिति से पहले परीक्षण किया जाता है।
कई उपयोगकर्ताओं के लिए, व्यावहारिक संस्करण इस तरह दिखता है: मैन्युअल के बजाय स्वचालित बैकअप, कम से कम एक ऑफ-सर्वर कॉपी, विलंबित मुद्दों को पकड़ने के लिए पर्याप्त लंबी अवधारण विंडो, और नियमित आधार पर परीक्षण बहाल करना। यदि आपकी सेवा राजस्व उत्पन्न करने वाली या समुदाय-महत्वपूर्ण है, तो निगरानी और अलर्ट जोड़ें ताकि विफल बैकअप पर किसी का ध्यान न जाए।
संपीड़न और एन्क्रिप्शन भी मायने रखता है, खासकर यदि बैकअप में व्यक्तिगत डेटा, टोकन या रहस्यों के साथ कॉन्फ़िगरेशन शामिल हो। छोटे बैकअप को स्टोर करना और स्थानांतरित करना आसान होता है। यदि भंडारण उजागर या स्थानांतरित हो जाता है तो एन्क्रिप्टेड बैकअप अधिक सुरक्षित होते हैं।
फिर भी, सौदेबाज़ी होती रहती है। अधिक लगातार बैकअप का अर्थ है अधिक संग्रहण उपयोग और अधिक I/O। लंबे समय तक प्रतिधारण का मतलब अधिक लागत है। पूर्ण छवि बैकअप सुविधाजनक हैं, लेकिन छोटी घटनाओं के लिए फ़ाइल-स्तरीय पुनर्स्थापना अक्सर तेज़ होती है। सही सेटअप वह है जिसे आप लगातार बनाए रख सकते हैं, न कि वह जो प्रभावशाली लगता है।
पुनर्स्थापना परीक्षण वह हिस्सा है जिसे अधिकांश लोग छोड़ देते हैं
बैकअप तभी सिद्ध होता है जब आप उसे पुनर्स्थापित करते हैं।
यह वह जगह है जहां सरल सेटअप जटिल सेटअपों को मात देते हैं। यदि आपकी पुनर्स्थापना प्रक्रिया में दस पृष्ठों के नोट्स लगते हैं, यह एक लापता स्क्रिप्ट पर निर्भर करता है, या मैन्युअल सुधार की आवश्यकता होती है जिसे आप केवल दबाव में याद रखते हैं, तो पुनर्प्राप्ति अपेक्षा से धीमी होगी।
परीक्षण पुनर्स्थापना को कुछ बुनियादी प्रश्नों का उत्तर देना चाहिए। क्या आप नवीनतम बैकअप पुनर्प्राप्त कर सकते हैं? क्या आप पुराना संस्करण पुनर्प्राप्त कर सकते हैं? इसमें कितना समय लगता है? क्या ऐप या सर्वर वास्तव में पुनर्स्थापना के बाद सही ढंग से प्रारंभ होता है? क्या अनुमतियाँ, कॉन्फ़िगरेशन और डेटाबेस कनेक्शन बरकरार हैं?
इसे अच्छी तरह से करने के लिए आपको एंटरप्राइज़ टूलींग की आवश्यकता नहीं है। आपको दोहराव की आवश्यकता है. यदि बैकअप स्वचालित हो और पुनर्स्थापना का अभ्यास किया जाए तो एक छोटी टीम या एकल डेवलपर भी एक विश्वसनीय प्रक्रिया बना सकता है।
प्रदर्शन-केंद्रित होस्टिंग वातावरण के लिए, यह और भी अधिक मायने रखता है। तेजी से तैनाती बढ़िया है. तेजी से पुनर्प्राप्ति ही उपयोगकर्ताओं को लंबे समय तक समस्या पर ध्यान देने से रोकती है। यही कारण है कि ACLClouds जैसे प्रदाता केवल मूल विशेषताओं के बजाय व्यावहारिक बुनियादी ढांचे की सुविधाओं पर इतना जोर देते हैं।
सामान्य बैकअप गलतियाँ जो वास्तविक डाउनटाइम का कारण बनती हैं
पहली गलती उसी सर्वर पर बैकअप लेना है। यदि डिस्क विफल हो जाती है, तो उत्पादन और बैकअप डेटा दोनों एक साथ गायब हो सकते हैं।
दूसरा मैनुअल बैकअप पर निर्भर है। मैन्युअल काम छूट जाते हैं. उन्हें देरी हो जाती है. वे अपडेट से ठीक पहले भूल जाते हैं, यानी ठीक उसी समय जब आपको उनकी सबसे अधिक आवश्यकता होती है।
तीसरा है डेटाबेस को अनदेखा करना। लोग अक्सर फ़ाइलों की प्रतिलिपि बनाते हैं और मान लेते हैं कि इसमें सब कुछ शामिल है, फिर उन्हें एहसास होता है कि उनकी ऐप स्थिति हमेशा SQL में रहती है।
चौथा कभी भी अवधारण या भंडारण सीमा की जाँच नहीं करना है। जब स्थान समाप्त हो जाता है या पुराने संस्करण बहुत आक्रामक तरीके से हटा दिए जाते हैं तो बैकअप चुपचाप विफल हो सकते हैं।
पांचवां पूर्ण सुरक्षा के साथ भ्रमित करने वाला स्नैपशॉट है। स्नैपशॉट उपयोगी होते हैं, लेकिन वे हमेशा अपने आप में एक पूर्ण बैकअप रणनीति नहीं होते हैं। वे योजना का हिस्सा हो सकते हैं, पूरी योजना का नहीं.
सबसे सुरक्षित मानसिकता सरल है: मान लें कि अंततः विफलता होगी, फिर पुनर्प्राप्ति को तेज़ और पूर्वानुमानित बनाएं।
बैकअप कोई आकर्षक बुनियादी ढांचा नहीं है. जब सर्वर लॉन्च ठीक से हो जाता है तो कोई भी उनका दिखावा नहीं करता। लेकिन जब एक प्लगइन एक दुनिया को तोड़ देता है, एक तैनाती एक कॉन्फ़िगरेशन को मिटा देती है, या एक डेटाबेस तालिका 2:13 बजे गायब हो जाती है, तो बैकअप एक संक्षिप्त सुधार और पूर्ण पुनर्निर्माण के बीच का अंतर है। उन्हें स्वचालित रखें, उन्हें अलग रखें, और सुनिश्चित करें कि जब आवश्यक हो तब वे पुनर्स्थापित हो जाएँ।