किसी वेबसाइट को नए होस्ट पर लगभग शून्य डाउनटाइम के साथ कैसे माइग्रेट करें

माइग्रेशन डाउनटाइम क्यों पैदा करते हैं (और इससे कैसे बचें)

ज़्यादातर वेबसाइट ट्रांसफ़र इसलिए डाउन नहीं होते क्योंकि फ़ाइलें कॉपी करना कठिन है — वे DNS प्रोपेगेशन की वजह से डाउन होते हैं। जिस क्षण आप अपना डोमेन किसी नए सर्वर की ओर पॉइंट करते हैं, कुछ विज़िटर मिनटों या घंटों तक पुराने सर्वर पर ही पहुँचते रहते हैं, और यह आपके DNS रिकॉर्ड के TTL (Time To Live) द्वारा नियंत्रित होता है। यदि उस समय-अंतराल में पुराना सर्वर पहले ही मिटा दिया गया हो या डेटाबेस दो जगहों के बीच बँटा हुआ हो, तो आप रिक्वेस्ट, ऑर्डर या फ़ॉर्म सबमिशन खो देते हैं।

लगभग शून्य-डाउनटाइम माइग्रेशन की तरकीब सैद्धांतिक रूप से सरल है: पुरानी साइट को पूरी तरह लाइव रखें, नए होस्ट पर एक संपूर्ण कार्यशील प्रति बनाएँ, स्विच करने से पहले साबित करें कि वह काम करती है, समय से पहले अपना TTL कम कर दें ताकि कटओवर तेज़ हो, और तभी DNS बदलें। यह गाइड एक सामान्य PHP/MySQL साइट (WordPress, Laravel, कस्टम ऐप्स) के लिए इस प्रक्रिया को समझाती है और यह उतनी ही समान रूप से उस सर्वर पर लागू होती है जिसे आप स्वयं नियंत्रित करते हैं या किसी cPanel/वेब होस्टिंग अकाउंट पर।

यदि आप PDPL/NCA अनुपालन के लिए डेटा को सऊदी अरब के भीतर रखने हेतु माइग्रेट कर रहे हैं, तो Skyline Cloud किंगडम के भीतर होस्ट करता है — लेकिन नीचे दिए गए चरण सार्वभौमिक हैं।

चरण 1 — पहले अपना DNS TTL कम करें (24–48 घंटे पहले)

यह सबसे महत्वपूर्ण अकेला चरण है, और यह बाकी सब कुछ करने से पहले होना चाहिए। TTL रिज़ॉल्वर को बताता है कि आपके रिकॉर्ड कितने समय तक कैश करने हैं। यदि आपके A रिकॉर्ड का TTL 14400 (4 घंटे) है, तो कटओवर को पूरी तरह प्रोपेगेट होने में 4 घंटे तक लग सकते हैं।

अपने DNS प्रदाता में (या प्रबंधित DNS में), अपने A, AAAA, CNAME और www रिकॉर्ड पर TTL को एक कम मान पर सेट करें — 300 सेकंड (5 मिनट) एक सुरक्षित विकल्प है:

Type   Name    Value             TTL
A      @       <OLD_SERVER_IP>   300
A      www     <OLD_SERVER_IP>   300

अभी IP न बदलें — केवल TTL बदलें। फिर कम से कम उतनी देर प्रतीक्षा करें जितना पुराना TTL था ताकि हर कैश की गई प्रति समाप्त हो जाए। कटओवर के बाद आप TTL को वापस 3600 या उससे अधिक कर सकते हैं।

चरण 2 — नया होस्ट प्रोविज़न करें और फ़ाइलें कॉपी करें

पहले अपने नए होस्ट पर अपना अकाउंट या सर्वर बनाएँ। यदि आप Skyline Cloud पर हैं, तो अपना VPS या वेब होस्टिंग प्लान शुरू करें और नए सर्वर का IP नोट कर लें।

जिस सर्वर तक आपके पास SSH एक्सेस है, उसके लिए rsync सबसे तेज़ और सबसे विश्वसनीय कॉपी है — यह अनुमतियाँ (permissions) संरक्षित रखता है, फिर से शुरू किया जा सकता है, और केवल बदलावों को सिंक करने के लिए दोबारा चलाया जा सकता है:

rsync -avz --progress -e ssh /var/www/html/ user@NEW_SERVER_IP:/var/www/html/

• -a अनुमतियाँ, स्वामित्व, टाइमस्टैम्प और सिमलिंक संरक्षित रखता है
• -v विस्तृत आउटपुट (verbose), -z ट्रांज़िट में कम्प्रेस करता है
• स्रोत पर अंत में लगा स्लैश फ़ोल्डर की बजाय उसकी सामग्री कॉपी करता है

cPanel-से-cPanel ट्रांसफ़र के लिए, बिल्ट-इन Backup → Full Account Backup या होस्ट-समर्थित ट्रांसफ़र आमतौर पर मैनुअल rsync से सरल होता है। Skyline सहित कई प्रदाता आपके लिए ट्रांसफ़र चला देंगे।

चरण 3 — डेटाबेस माइग्रेट करें

पुराने सर्वर पर डेटाबेस एक्सपोर्ट करें:

mysqldump -u DB_USER -p --single-transaction --quick DB_NAME > backup.sql

--single-transaction लाइव साइट को लॉक किए बिना InnoDB टेबल्स का एक संगत स्नैपशॉट देता है। डंप को आर-पार कॉपी करें और इसे नए सर्वर पर इम्पोर्ट करें:

scp backup.sql user@NEW_SERVER_IP:~/
mysql -u DB_USER -p NEW_DB_NAME < backup.sql

फिर अपने एप्लिकेशन के कॉन्फ़िग को नए डेटाबेस क्रेडेंशियल्स के साथ अपडेट करें — WordPress के लिए wp-config.php, Laravel के लिए .env, या इसके समकक्ष।

चरण 4 — DNS बदलने से पहले नई साइट का परीक्षण करें

यही वह चीज़ है जो माइग्रेशन को लगभग शून्य-डाउनटाइम बनाती है: आप नए सर्वर को पूरी तरह सत्यापित करते हैं जबकि लाइव साइट अभी भी पुराने सर्वर पर है। अपनी hosts फ़ाइल संपादित करके केवल अपनी मशीन को डोमेन को नए IP पर रिज़ॉल्व करने के लिए बाध्य करें।

macOS/Linux पर, /etc/hosts संपादित करें; Windows पर, C:\Windows\System32\drivers\etc\hosts:

NEW_SERVER_IP   example.com www.example.com

अब आपका ब्राउज़र example.com के लिए नया सर्वर लोड करेगा जबकि बाकी दुनिया अभी भी पुराना सर्वर देखेगी। पेजों पर क्लिक करके देखें, लॉग इन करें, फ़ॉर्म, चेकआउट और एडमिन का परीक्षण करें। जो कुछ टूटा हो उसे ठीक करें। जब सब कुछ काम करने लगे, तो hosts एंट्री हटा दें।

चरण 5 — अंतिम सिंक और DNS कटओवर

पुरानी साइट को थोड़ी देर के लिए मेंटेनेंस/रीड-ओनली मोड में डाल दें ताकि अंतिम सिंक के दौरान कोई नया डेटा न लिखा जाए। rsync दोबारा चलाएँ (यह केवल बदलाव कॉपी करता है) और अंतिम-क्षण के राइट्स को कैप्चर करने के लिए एक अंतिम mysqldump/इम्पोर्ट करें। फिर DNS अपडेट करें:

Type   Name    Value             TTL
A      @       <NEW_SERVER_IP>   300
A      www     <NEW_SERVER_IP>   300

चूँकि TTL 300 है, अधिकांश विज़िटर पाँच मिनट के भीतर स्विच हो जाते हैं। ट्रैफ़िक पूरी तरह से निकल जाने तक पुराने सर्वर को चालू रखें — आमतौर पर 24–48 घंटे — ताकि जो कोई अभी भी कैश किए गए रिकॉर्ड पर है, उसे सही ढंग से सर्व किया जा सके। यही ओवरलैप खोई हुई रिक्वेस्ट को रोकता है।

चरण 6 — ईमेल, SSL और सत्यापन को न भूलें

• ईमेल (MX रिकॉर्ड): यदि आपके डोमेन का ईमेल अलग से होस्ट किया गया है, तो वेब ट्रांसफ़र के दौरान MX रिकॉर्ड को अछूता छोड़ दें। मेलबॉक्स माइग्रेट करना एक अलग प्रक्रिया है — किंगडम के भीतर मेल सेटअप के लिए बिज़नेस ईमेल होस्टिंग देखें।
• SSL: कटओवर से पहले नए होस्ट पर एक नया प्रमाणपत्र जारी करें (Let's Encrypt या आपके पैनल का ऑटो-SSL) ताकि DNS फ्लिप होते ही HTTPS तुरंत काम करे।
• प्रोपेगेशन सत्यापित करें: कई स्थानों से जाँचें:

dig +short example.com

इसे कुछ अलग-अलग नेटवर्क से चलाएँ, या किसी ग्लोबल DNS-प्रोपेगेशन चेकर का उपयोग करें, जब तक कि हर कोई नए IP पर रिज़ॉल्व न हो जाए।

चरण 7 — कटओवर के बाद

एक बार ट्रैफ़िक पूरी तरह से स्थानांतरित हो जाने और पुराना सर्वर एक-दो दिन निष्क्रिय रहने के बाद:

1. स्थिरता और कम DNS लुकअप के लिए अपना TTL वापस 3600 या उससे अधिक पर बढ़ा दें।
2. पुराने सर्वर का एक अंतिम बैकअप लें, फिर उसे डीकमिशन कर दें।
3. मॉनिटरिंग, क्रॉन जॉब्स, और अपने ऐप या फ़ायरवॉल में किसी भी हार्डकोडेड IP को अपडेट करें।
4. लाइव नए सर्वर पर फ़ॉर्म और भुगतान का फिर से परीक्षण करें।

माइग्रेशन चेकलिस्ट

• [ ] TTL को 300 तक कम किया गया (24–48 घंटे पहले)
• [ ] नया होस्ट प्रोविज़न किया गया, फ़ाइलें rsync के ज़रिए कॉपी की गईं
• [ ] डेटाबेस एक्सपोर्ट और इम्पोर्ट किया गया, कॉन्फ़िग अपडेट किया गया
• [ ] नई साइट का hosts फ़ाइल के ज़रिए परीक्षण किया गया
• [ ] पुरानी साइट रीड-ओनली पर सेट की गई, अंतिम सिंक हो गया
• [ ] DNS को नए IP पर पॉइंट किया गया
• [ ] पुराने सर्वर को 24–48 घंटे लाइव रखा गया
• [ ] ईमेल/MX और SSL सत्यापित किए गए
• [ ] TTL वापस बढ़ाया गया, पुराना सर्वर डीकमिशन किया गया

सावधानी से किया जाए, तो आपके विज़िटर कभी कोई त्रुटि नहीं देखते — केवल एक तेज़, किंगडम के भीतर की साइट देखते हैं।

स्थानांतरण के लिए तैयार हैं? अपना Skyline Cloud अकाउंट बनाएँ और PDPL/NCA-अनुरूप डेटा रेज़िडेंसी, पारदर्शी मूल्य निर्धारण, और स्थानीय अरबी समर्थन के साथ सऊदी अरब के भीतर होस्ट करें।