VPS माइग्रेशन चेकलिस्ट: बैकअप, DNS, TLS और रोलबैक
स्वयं-होस्ट किए गए एप्लिकेशन के लिए एक व्यावहारिक माइग्रेशन क्रम: इन्वेंटरी, सुसंगत बैकअप, परीक्षित गंतव्य, नियंत्रित लेखन, DNS कटओवर और रिस्टोर पथ।
एक नज़र में
एक नियंत्रित VPS माइग्रेशन सेवाओं और डेटा की इन्वेंटरी बनाता है, सुसंगत बैकअप बनाता है, रिस्टोर किए गए गंतव्य को सत्यापित करता है, होस्टनाम और TLS रूटिंग का परीक्षण करता है, अंतिम लेखन और DNS का समन्वय करता है, और डेटा-जागरूक रोलबैक संरक्षित करता है। कोई भी चेकलिस्ट अकेले शून्य डाउनटाइम की गारंटी नहीं देती।
स्थानांतरित करने से पहले एप्लिकेशन की इन्वेंटरी बनाएँ
एप्लिकेशन के काम करने के लिए आवश्यक सेवाएँ, संस्करण, पोर्ट, निर्धारित कार्य, डेटाबेस, अपलोड की गई फ़ाइलें और कॉन्फ़िगरेशन सूचीबद्ध करें। पहचानें कि लेखन कहाँ होता है और यह किन बाहरी सेवाओं पर निर्भर है। जब डेटा कहीं और रहता है तो कॉपी की गई वेब डायरेक्टरी पूर्ण माइग्रेशन नहीं है।
वर्तमान DNS नाम, सक्रिय IPv4 और IPv6 रिकॉर्ड, प्रमाणपत्र नवीनीकरण विधियाँ और रिकवरी एक्सेस पथ रिकॉर्ड करें। सीक्रेट को अपनी निजी डिप्लॉयमेंट टूलिंग में रखें। पासवर्ड, निजी कुंजी या डेटाबेस डंप को सार्वजनिक डॉक्यूमेंट रूट या साझा माइग्रेशन चेकलिस्ट में न रखें।
सुसंगत बैकअप बनाएँ और सिद्ध करें कि वह रिस्टोर होता है
लेखन जारी रहते समय मनमानी फ़ाइलें कॉपी करने के बजाय डेटाबेस-समर्थित बैकअप तंत्र का उपयोग करें। SQLite के लिए, Online Backup API एक सुसंगत डेटाबेस स्नैपशॉट बनाता है। WAL मोड में, WAL फ़ाइल स्थायी डेटाबेस स्थिति में भाग लेती है, इसलिए केवल मुख्य डेटाबेस फ़ाइल कॉपी करने से कमिट किए गए परिवर्तन छूट सकते हैं।
एक सुसंगत डेटाबेस बैकअप स्वतः अलग से संग्रहीत अपलोड, क्यू या फ़ाइलों के साथ सुसंगत नहीं होता। अपने एप्लिकेशन के साथ उनके कैप्चर का समन्वय करें। अलग परीक्षण स्थान में रिस्टोर करें और बैकअप को उपयोग योग्य मानने से पहले रिकॉर्ड, फ़ाइल संदर्भ और एप्लिकेशन व्यवहार सत्यापित करें।
DNS बदलने से पहले गंतव्य तैयार करें
नए सर्वर पर इच्छित उपयोगकर्ता, अनुमतियाँ, रनटाइम संस्करण, सेवाएँ और एप्लिकेशन डायरेक्टरी बनाएँ। परीक्षण बैकअप को उसके गंतव्य डेटा स्थान में रिस्टोर करें, जहाँ उपयुक्त हो सार्वजनिक वेब रूट के बाहर। उस सेवा खाते का उपयोग करके स्वामित्व और एक्सेस जाँचें जो वास्तव में एप्लिकेशन चलाएगा।
साझा सर्वर पर असंबंधित साइटों को संरक्षित रखें। समर्पित डॉक्यूमेंट रूट, वर्चुअल होस्ट और रनटाइम का उपयोग करें, वेब-सर्वर कॉन्फ़िगरेशन मान्य करें और ऐसा रोलबैक तैयार करें जो केवल इस परिवर्तन के स्वामित्व वाली फ़ाइलें और कॉन्फ़िगरेशन बहाल करे।
नए सर्वर पर वास्तविक होस्टनाम और प्रमाणपत्र का परीक्षण करें
किसी नंगे IP पते पर ब्राउज़र अनुरोध होस्टनाम-आधारित रूटिंग या प्रमाणपत्र सत्यापन को दोहराता नहीं। curl --resolve किसी परीक्षण को इच्छित होस्टनाम और चुना गया गंतव्य IP उपयोग करने देता है, जबकि सामान्य होस्टनाम और TLS जाँच बनी रहती है। HTTP स्थिति और अपेक्षित एप्लिकेशन सामग्री भी जाँचें। उदाहरण केवल-दस्तावेज़ीकरण मानों का उपयोग करता है; उन्हें अपने स्वयं के सत्यापित डोमेन और गंतव्य से बदलें।
उस परीक्षण के पास होने के लिए एक वैध प्रमाणपत्र और अनुमत नेटवर्क पथ पहले से मौजूद होना चाहिए। माइग्रेशन को तैयार कहने के लिए प्रमाणपत्र सत्यापन कभी बंद न करें। DNS-आधारित ACME सत्यापन किसी डोमेन को उसका वेब-सर्वर पता बदले बिना मान्य कर सकता है; HTTP-आधारित सत्यापन की पहुँच आवश्यकताएँ अलग होती हैं। नवीनीकरण का परीक्षण प्रारंभिक जारी करने से अलग करें।
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/लेखन-नियंत्रण और अंतिम-सिंक योजना चुनें
एक छोटी रखरखाव अवधि या एप्लिकेशन-उपयुक्त अन्य सुसंगतता तंत्र निर्धारित करें। आपके द्वारा पहचाने गए लेखकों को रोकें या रीडायरेक्ट करें, अंतिम सुसंगत डेटाबेस बैकअप लें, संबंधित परिवर्तनशील फ़ाइलों को सिंक करें और परिणाम सत्यापित करें। सार्वजनिक इंटरफ़ेस शांत दिखने पर भी क्यू वर्कर, वेबहुक और क्रॉन कार्य लिख सकते हैं।
फ़ाइल सिंक्रनाइज़ेशन से पहले ड्राई रन का उपयोग करें। शॉर्टकट के रूप में डिलीशन फ़्लैग न जोड़ें और न ही पूरी सिस्टम डायरेक्टरी कॉपी करें। नए एप्लिकेशन की जाँच करने और यह स्थापित करने तक पुरानी सेवा को रिकवर करने योग्य रखें कि लेखन के लिए कौन सा स्थान आधिकारिक है।
DNS बदलें, फिर दोनों पता परिवारों का निरीक्षण करें
सेवा के लिए आवश्यक रिकॉर्ड अपडेट करें और मौजूदा रिज़ॉल्वर कैश का ध्यान रखें। आधिकारिक उत्तर और कई सामान्य क्लाइंट पथ जाँचें। यदि कोई अप्रचलित AAAA रिकॉर्ड सक्रिय रहता है, तो IPv6 क्लाइंट पुराने सर्वर तक पहुँचते रह सकते हैं जबकि IPv4 क्लाइंट नए सर्वर तक पहुँचते हैं।
नई सेवा पर साइन-इन, पढ़ना, लिखना, अपलोड, बैकग्राउंड जॉब और बाहरी कॉलबैक का परीक्षण करें। संक्रमण के दौरान एक ही एप्लिकेशन की दो स्वतंत्र लेखन-योग्य प्रतियाँ न चलाएँ। उस ट्रैफ़िक को संभालने के लिए स्पष्ट नियम रखें जो अभी भी पुराने गंतव्य तक पहुँचता है।
रोलबैक को DNS निर्णय के साथ-साथ डेटा निर्णय भी बनाएँ
वे विफलता स्थितियाँ परिभाषित करें जो रोलबैक शुरू करती हैं और कटओवर को कौन नियंत्रित करता है। गंतव्य तक नए लेखन पहुँचने के बाद केवल DNS वापस लेना पर्याप्त नहीं है: पुरानी प्रति पर लौटने से पहले उस डेटा को संरक्षित या समाधान करना होगा।
स्रोत और बैकअप को उचित रिकवरी अवधि तक रखें। पुराने एक्सेस हटाएँ और संसाधन तभी डीकमीशन करें जब गंतव्य, बैकअप, नवीनीकरण और निगरानी की जाँच हो चुकी हो। प्रतिधारण और विलोपन वास्तविक सेवा नीति का पालन करना चाहिए, किसी सामान्य निश्चित घंटों की संख्या का नहीं।