कोई भी live site को मनोरंजन के लिए नहीं ले जाता। यह तब होता है जब मौजूदा host अचानक आपके passport की तस्वीर माँगने लगता है, या 24 घंटे की समय-सीमा वाली कोई complaint आगे भेज देता है, या क्योंकि जिस देश में उसका datacentre बैठा है वह अब आपका data रखने के लिए समझदारी वाली जगह नहीं लगता। वजह जो भी रही हो, move ख़ुद ही सबसे ख़तरनाक हिस्सा होता है — यही वह एक पल है जब site बंद हो सकती है, और यही वह एक पल है जब एक लापरवाह क़दम नए server को उसी पहचान से जोड़ सकता है जिसे आप पीछे छोड़ने की कोशिश कर रहे थे।
दोनों जोखिमों का इलाज एक ही है, और वह कोई tool नहीं है। वह है ordering। सही क्रम में चलाया गया migration ऐसा कोई window नहीं छोड़ता जिसमें site पहुँच से बाहर हो, क्योंकि दोनों servers एक साथ ज़िंदा रहते हैं और DNS सबसे आख़िर में बदलता है। ग़लत क्रम में चलाया गया migration एक साथ outage और एक trail, दोनों पैदा कर देता है। आगे वही क्रम दिया गया है, उस इंसान के लिए लिखा गया जो दो mainstream providers के बीच अदला-बदली की बजाय किसी offshore, no-KYC host की तरफ़ जा रहा है — तरीक़ा वही है, पर बाद की सफ़ाई वैसी नहीं।
असल में "zero downtime" का मतलब क्या है
यह वाक्यांश ढीले ढंग से इस्तेमाल होता है, और यही ढिलाई है जहाँ लोग मार खाते हैं। दो machines से एक साथ HTTP serve करना आसान है। दो machines के एक साथ serve करते समय state को consistent बनाए रखना ही असली मुश्किल हिस्सा है, और यही इकलौता हिस्सा है जो कभी data खोता है। इसलिए कुछ भी plan करने से पहले यह तय करें कि आप असल में इनमें से क्या चला रहे हैं, क्योंकि यही जवाब पूरी रात का ढाँचा तय करता है।
| आप क्या move कर रहे हैं | असल में तकलीफ़ कौन सा हिस्सा देता है | plan क्या होना चाहिए |
|---|---|---|
| Static site, brochure site, generated output | कुछ नहीं। यहाँ बाँटने के लिए कोई state ही नहीं है | Copy करें, verify करें, cut over करें। सचमुच zero downtime |
| database वाला कोई CMS — WordPress, Ghost, कोई forum | Comments, logins और posts का एक साथ दो databases पर पहुँचना | एक read-only freeze, जो मिनटों में नापा जाए — आपके सबसे शांत घंटे पर |
| कोई store, या ऐसा कुछ भी जो orders लेता हो | एक split brain चुपचाप paid orders खो देता है | छोटा maintenance window लें। यह reconciliation से सस्ता पड़ता है |
| cron jobs या background workers वाला कुछ भी | दोनों servers पर एक ही job का चलना — दोगुने emails, दोगुने charges | नए वाले के शुरू होने से पहले पुराने host पर schedule बंद करें, बाद में नहीं |
| उसी domain पर Mail | MX records अपने ही समय पर caches से expire होते हैं, आपके A record से बेपरवाह | mail को अलग रात को move करें, और पुराने MX को एक हफ़्ते तक स्वीकार करते रहने दें |
ग़ौर करें कि सिर्फ़ पहली row ही सचमुच मुफ़्त है। बाक़ी हर जगह, "zero downtime" का मतलब है "इतना छोटा write freeze कि कोई उसके लिए ticket ही न खोले"। सुबह 04:00 बजे के दो मिनट का read-only एक rounding error है; दो databases पर दो घंटे के split writes एक पूरे weekend की reconciliation है। freeze को चुनें।
move की योजना बनाने से दिनों पहले DNS TTL घटाएँ
यह इकलौता ऐसा क़दम है जिसमें lead time लगता है, इसीलिए यह सबसे पहले आता है और इसीलिए लोग इसे छोड़ भी देते हैं। आपका TTL — यानी time to live — internet के हर resolver को बताता है कि वह आपके record को दोबारा पूछने से पहले कितनी देर तक cache कर सकता है। अगर आपके A record का TTL 86400 है, तो जिस resolver ने इसे एक घंटे पहले देखा था वह अगले 23 घंटों तक वही पुराना IP देता रहेगा, चाहे आप registrar पर कुछ भी बदल दें।
सबसे अहम बात यह है कि TTL घटाना ख़ुद भी पुराने TTL के अधीन है। Resolvers को नए, छोटे मान का पता तभी चलता है जब पुरानी cached copy expire होती है। इसलिए TTL को 300 seconds तक cutover से कम से कम एक पूरे पुराने-TTL period पहले घटा दें — एक दिन-भर के TTL के साथ, इसका मतलब है यह काम 24 से 48 घंटे पहले करना। फिर पूरी दुनिया बदलाव के पाँच मिनट के भीतर आपके नए record पर आ जाती है, और cutover किसी रोमांचक घटना की बजाय एक सामान्य बात रह जाता है।
move के कुछ दिन बाद TTL को वापस किसी समझदार मान पर ले आएँ। 300-second TTL एक बढ़िया tool है पर एक ख़राब स्थायी setting — यह आपके query volume को कई गुना बढ़ा देता है और आपके DNS provider को कहीं ज़्यादा तीखा single point of failure बना देता है।
जो move कर रहे हैं उसकी inventory बनाएँ, जो याद है उसकी नहीं
हर असफल migration का post-mortem एक जैसा होता है: जिस चीज़ को किसी ने list ही नहीं किया, वह copy नहीं हुई। web root और database — ये दो चीज़ें हर किसी को याद रहती हैं; नीचे दी गई list बाक़ी सब कुछ है, और इसे याददाश्त से नहीं बल्कि शब्दशः चलकर देखना समझदारी है।
- Scheduled work।
crontab -lहर user के लिए, साथ ही systemd timers। Renewal hooks और रात की jobs यहीं छुपी होती हैं। - Service definitions। Custom systemd units, web server vhosts, PHP-FPM pools, कोई भी supervisor config।
- Secrets और environment।
.envfiles, API keys, database passwords, application salts — और ध्यान रखें कि इन्हें सिर्फ़ copy नहीं, rotate किया जाना चाहिए। - TLS material। Certificates और, इससे भी ज़्यादा अहम, ACME account और renewal configuration।
- Mail identity। DKIM private keys, SPF और DMARC records। यहाँ की कोई गड़बड़ शोर मचाकर नहीं टूटती; यह बस चुपचाप आपकी mail को spam में भेज देती है।
- Uploaded media। अक्सर web root से बाहर, और अक्सर आपकी सबसे बड़ी चीज़।
- हर वह बाहरी चीज़ जो आपके IP पर भरोसा करती है। Payment gateway allowlists, webhook destinations, database firewalls, IP restrictions वाले third-party APIs। रात 03:00 बजे "site चल रही है पर checkout टूटा है" की यही सबसे बड़ी वजह होती है।
- Package list।
dpkg --get-selectionsया उसके बराबर कुछ, ताकि नए box में लगभग वही नहीं बल्कि बिल्कुल वही extensions और libraries हों।
copying शुरू करने से पहले यह list लिख लें। यह inventory बाद में आपका test plan भी बनती है — इसकी हर पंक्ति वह चीज़ है जिसे DNS को नए server के बारे में पता चलने से पहले वहाँ जाँचना है।
पहले नया server बनाएँ, और उस पर कुछ भी रखने से पहले उसे harden करें
destination server जल्दी order करें और उसे एक-दो दिन ख़ाली चलता रहने दें। overlap का कोई नुक़सान नहीं है — एक छोटा offshore VPS महीने के बस कुछ dollars का होता है — और इसका बहुत फ़ायदा है कि आप build उस समय-दबाव में न करें जब कोई freeze किया हुआ database इंतज़ार कर रहा हो।
पुराने environment से जान-बूझकर मेल बिठाएँ: वही distribution और major version, वही PHP या Node या Python major version, वही database major version। जब आप वहाँ हों तो modernise करने का लालच बहुत बड़ा होता है और इसे पूरी तरह टालना चाहिए। अगर cutover के बाद site टूटती है, तो आप चाहते हैं कि बदला हुआ variable बिल्कुल एक ही हो। stack को दो हफ़्ते बाद, किसी उबाऊ दोपहर में, rollback की क्षमता के साथ upgrade करें।
जब तक यह ख़ाली है, इसे harden कर लें। सिर्फ़-keys वाला SSH, एक default-deny firewall, automatic security updates — पहले घंटे की hardening checklist बिल्कुल यही list है, और इसे किसी ऐसी machine पर लागू करना कहीं आसान है जिस पर अभी कुछ भी नहीं है। अगर data इतना संवेदनशील है कि आप उसके लिए jurisdiction बदल रहे हैं, तो यही सही पल है आराम की हालत में encryption पर फ़ैसला लेने का, क्योंकि इसे बाद में जोड़ने का मतलब है एक और migration।
data को दो बार copy करें: पहले एक धीमा pass, फिर एक तेज़ pass
स्वाभाविक सोच यह होती है कि सब कुछ maintenance window के दौरान ही copy किया जाए। इसका उल्टा करें। जब पुरानी site आराम से traffic serve कर रही हो, तब दिनों पहले एक पूरी copy चला लें, फिर cutover पर एक दूसरा pass चलाएँ जो सिर्फ़ बदली हुई चीज़ें move करे। पहला pass छह घंटे ले सकता है और किसी को पता भी नहीं चलता। दूसरा नब्बे seconds लेता है, और वही आपका पूरा downtime budget है।
files के लिए, rsync -aHAX --numeric-ids permissions, ownership, hard links और extended attributes बनाए रखता है; --numeric-ids flag इसलिए मायने रखता है क्योंकि दो नई बनी machines के बीच UIDs शायद ही कभी मेल खाते हैं। इसे एक बार पहले चला लें, फिर cutover से ठीक पहले उन्हीं arguments के साथ दोबारा — दूसरी बार सिर्फ़ delta transfer होता है।
Databases को भी वही two-phase treatment चाहिए, पर अलग tools के साथ। एक mysqldump --single-transaction या pg_dump आपको एक consistent early snapshot देता है जिस पर build और test किया जा सके। cutover पर, या तो अपने छोटे write freeze के दौरान दूसरा dump ले लें, या — किसी बड़े database के लिए जहाँ एक छोटा freeze भी तकलीफ़ देता हो — नए server को दिनों पहले पुराने के एक replica के रूप में खड़ा करें, उसे catch up करने दें, और फिर उसे promote कर दें। Replication freeze को घटाकर seconds का कर देता है। यह दो घंटे के migration को दो दिन के project में भी बदल देता है, इसलिए इसे तभी इस्तेमाल करें जब size सचमुच इसकी माँग करे।
Pull करें, push नहीं, और कभी अपने laptop के ज़रिए नहीं। copy को नए server से शुरू करें ताकि transfer host से host, datacentre की रफ़्तार से चले। gigabytes को अपने घर के connection से route करना धीमा है, और यह आपके residential IP को दोनों machines के access logs में डाल देता है — जो ठीक वही link है जिससे बचने के लिए privacy-motivated migration किया जाता है। अगर पुराने host को आपका नया IP पता चलना भी स्वीकार्य नहीं है, तो सीधे copy करें ही नहीं: इसके बजाय नए server को अपने ख़ुद के off-site encrypted backup से restore करें, और दोनों machines कभी आपस में बात ही नहीं करतीं।
DNS को इसके होने का पता चलने से पहले नए server को test करें
आप बिना किसी एक भी public record को बदले असली hostname को नए IP से serve कर सकते हैं, और आपको करना भी चाहिए — यही चीज़ cutover को बेरौनक़ बना देती है। अपने local /etc/hosts में एक line जोड़ें जो domain को नए IP पर इशारा करे, या इसे छोड़ें और एक request के लिए curl से यह काम करवा लें:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/
अब inventory से गुज़रें। front page और तीन गहरे pages load करें। Login करें। एक form submit करें। एक file upload करें। जाँचें कि database connection नया, local वाला है, न कि अब भी internet पर पुराने host की तरफ़ इशारा कर रहा — एक ऐसी ग़लती जो तब तक बिल्कुल सही चलती है जब तक आप पुराना server रद्द नहीं कर देते। cron jobs को हाथ से चलाकर उनका output पढ़ें। redirects जाँचें, और यह भी कि कोई ग़ायब URL अब भी 200 की बजाय 404 ही लौटाए।
TLS certificate अभी जारी करें, cutover से पहले, बाद में नहीं। एक DNS-01 challenge इस्तेमाल करें, जो एक TXT record के ज़रिए domain पर control साबित करता है और इसलिए तब भी काम करता है जब A record अब भी पुराने server की तरफ़ इशारा कर रहा हो। अगर आप DNS बदलने के बाद HTTP-01 validation का इंतज़ार करते हैं, तो उस अंतराल में हर शुरुआती visitor को certificate की चेतावनी मिलती है — यानी ठीक उसी window में एक ख़ुद-थोपा outage जिसे आप बचाने की कोशिश कर रहे थे।
Cutover, क्रम में
इस बिंदु तक नया server बन चुका है, harden हो चुका है, भर चुका है, असली hostname के तहत test हो चुका है, और उसके पास एक valid certificate है। अब cutover ख़ुद एक छोटी, उबाऊ list भर है — और यही मक़सद है।
- अगर site पर कोई और भी निर्भर है तो window का ऐलान करें, फिर पुरानी site को read-only या maintenance mode में डाल दें।
- पुराने host पर cron और background workers बंद करें। नए वाले पर इन्हें शुरू करने से पहले यह करें, बाद में कभी नहीं।
- आख़िरी
rsyncdelta pass और आख़िरी database dump चलाएँ, और उसे import करें। - नए server पर application शुरू करें और अपने smoke tests
--resolveके ज़रिए, आख़िरी data पर दोबारा चलाएँ। - A और AAAA records को नए IP पर बदलें। 300-second TTL के साथ, पूरी दुनिया पाँच मिनट के भीतर इसका अनुसरण कर लेती है।
- नए host पर cron और workers चालू करें।
- दोनों access logs साथ-साथ देखें। Traffic पुराने server से निकलकर नए पर दिखने लगता है; जब पुराना ख़ामोश हो जाए, cutover पूरा हो चुका है।
- पुराने server को एक हफ़्ते तक चलता, serve करता और अछूता छोड़ दें। यही आपका rollback है।
आठवाँ क़दम वही है जिसे लोग काट देते हैं, और यह इस list का सबसे सस्ता बीमा है। कुछ dollars की क़ीमत पर आप DNS को वापस इशारा करने की क्षमता बनाए रखते हैं — यानी पाँच मिनट की recovery — जब तक यक़ीन न हो जाए।
migration पीछे क्या छोड़ जाता है
यह वह हिस्सा है जिसे आम migration guides छोड़ देती हैं, और यही वह हिस्सा है जो सबसे ज़्यादा मायने रखता है अगर आप price की बजाय privacy के लिए move हुए हैं। किसी site को move करना उसकी history नहीं मिटाता। पुराने बंदोबस्त के कई public और semi-public records move के बाद भी हमेशा के लिए बचे रहते हैं, और यह जानना कि कौन-से बचते हैं, एक साफ़ break और उसके सिर्फ़ भ्रम के बीच का फ़र्क़ है।
| move को कौन record करता है | उसे कौन पढ़ सकता है | आप असल में क्या कर सकते हैं |
|---|---|---|
| Passive DNS — पुराने A records | कोई भी, commercial history services के ज़रिए | कुछ नहीं। पुराना IP हमेशा के लिए उस नाम से जुड़ा रहता है। ऐसे plan करें जैसे यह public है, क्योंकि यह है ही |
| Certificate Transparency logs | कोई भी, हमेशा के लिए, domain से खोजा जा सकने वाला | अब तक जारी हर certificate list में है — उन internal-सी लगने वाली subdomains समेत जिन्हें आप भूल चुके हैं। descriptive नामों की बजाय एक wildcard को तरजीह दें |
| पुराने host के account records | पुराना host, और वह कोई भी जो उन्हें मजबूर कर सके | Card details, signup email, login IPs। कोई no-KYC destination भविष्य को बचाता है, अतीत को नहीं |
| WHOIS history | Commercial WHOIS-history archives | अगर domain कभी असली details के तहत register हुआ था, तो वह snapshot दर्ज हो चुका है। बाद में लगाई गई privacy उसे वापस नहीं लेती |
| Analytics और ad identifiers | Vendor, और कोई भी जो आपका page source पढ़ ले | एक जैसा tracking ID साथ ले जाना दोनों sites को निर्णायक रूप से जोड़ देता है। एक नया जारी करें, या इसे छोड़ दें |
| पुरानी disk पर छूटे Dumps और backups | वह जिसे भी वह storage अगली बार allocate हो | cancel करने से पहले delete और overwrite करें। shared storage पर मान लें कि deletion एक गारंटी नहीं, बस एक संकेत भर है |
Received: headers, भेजी गई mail में | हर recipient, हमेशा के लिए | कुछ भी पीछे जाकर नहीं बदलता। सिर्फ़ वह mail जो आप move के बाद भेजते हैं, नया path लेकर चलती है |
| copy के दौरान आपके अपने connections | आपका ISP, और दोनों hosts के access logs | यह पूरी तरह आपके control में है। किसी भी machine को कभी ऐसे IP से न छुएँ जो आपकी पहचान बताता हो |
ईमानदार सार यह है कि कोई migration अतीत को दोबारा नहीं लिख सकता — यह बस उसमें और कुछ जुड़ने से रोक सकता है। यह अब भी बहुत मायने रखता है, पर इससे फ़ैसला बदल जाता है: अगर आपके threat model को यह चाहिए कि कोई observer नई site को पुरानी से जोड़ ही न सके, तो वही domain किसी नए host पर ले जाना यह हासिल नहीं करता, और cutover के दौरान की गई कोई भी सावधानी भी नहीं करेगी। उस स्थिति को एक नए नाम और एक साफ़ शुरुआत की ज़रूरत है, जिसकी बात आगे होगी। पर अगर आपका मक़सद बस आज से पहचान बताने वाले records बनना बंद करना है, और legal centre of gravity को अपनी चुनी हुई jurisdiction में ले जाना है, तो यह move बिल्कुल यही करता है। हमारी server OpSec guide उन आदतों को बताती है जो बाद में इसे साफ़ बनाए रखती हैं।
Domain का सवाल: उसे साथ ले जाएँ, या नए सिरे से शुरू करें?
site और domain दो अलग-अलग फ़ैसले हैं, और इन्हें एक मान लेना आम बात है। आप आज ही hosting move कर सकते हैं और registrar को हमेशा के लिए वैसे ही छोड़ सकते हैं; server के बदलने में domain को छूने की कोई ज़रूरत नहीं। क्या आपको ऐसा करना चाहिए, यह पूरी तरह इस पर निर्भर करता है कि domain पहले से आपके बारे में क्या जानता है।
- Domain रखें, registrar बदलें। समझदारी तब है जब domain की क़ीमत हो — links, rankings, ऐसा नाम जो लोग type करते हों। यह WHOIS record के भविष्य को ठीक करता है, उसकी history को नहीं, और हर ranking signal को बरक़रार रखता है। ज़्यादातर commercial sites के लिए यही सही जवाब है।
- Domain रखें, host के अलावा कुछ न बदलें। पूरी तरह वाजिब जब आप anonymity की बजाय jurisdiction, uptime या DMCA posture के लिए move हुए हों। सबसे सरल संभव move, zero SEO risk।
- नया domain, पुराने को redirect करें। rankings बचाता है, और दोनों नामों को publicly और हमेशा के लिए जोड़ देता है। इसे continuity के लिए चुनें, privacy के लिए कभी नहीं — redirect ख़ुद ही वह link है।
- नया domain, साफ़ break। यही इकलौता option है जो जुड़ाव को सचमुच काट देता है, और इसकी क़ीमत आपकी हर ranking और inbound link होती है जो आपके पास थी। इसे शुरू से privately register करें, क्योंकि कोई domain उतना ही anonymous होता है जितना उसका पहला registration। हमारी crypto से anonymous domain registration guide इसे सही तरीक़े से करना बताती है।
सोच-समझकर चुनें, और cutover के दौरान नहीं, उससे पहले चुनें। DNS move होने के बाद domain को लेकर मन बदलना मतलब है नाज़ुक हिस्से को दो बार करना।
पुराने host को सही तरीक़े से decommission करें
cutover के एक-दो हफ़्ते बाद, जब नए server के logs उबाऊ हो चुके हों और पुराने के ख़ाली, तब पुराना account बंद करने का वक़्त है। इसे इसी क्रम में करें, क्योंकि जो शॉर्टकट लुभाता है — सीधे cancel दबा देना — वही आपका data किसी और की disk पर छोड़ जाता है।
- पुष्टि करें कि अब कुछ भी पुराने IP की तरफ़ इशारा नहीं करता: third-party webhooks, allowlists, monitoring में hardcoded addresses जाँचें, और कोई भी भूला हुआ DNS record, जैसे कोई भूला-भटका
mailयाcpanelsubdomain। - उस machine पर कभी रहा हर secret rotate करें — database passwords, API keys, application salts, DKIM keys, SSH keys। इन्हें आगे copy न करें।
- अपनी SSH public keys और कोई भी support access पुराने server से हटा दें।
- application, dumps और backups delete करें, फिर खाली जगह को overwrite कर दें ताकि recycled volume को यूँ ही पढ़ने पर कुछ भी हाथ न लगे।
- तभी जाकर service terminate करें, और पुराने account से कोई भी सहेजा हुआ payment method हटा दें।
जो कुछ भी ऐसे hardware पर रहा जिस पर अब आपका control नहीं, वह परिभाषा से ही compromised है। इसलिए नहीं कि आपका पुराना host बदनीयत है, बल्कि इसलिए क्योंकि वह disk वापस किसी pool में जा रही है और आपको कभी पता नहीं चलेगा कि wipe के बाद क्या बचा। database password rotate करने में दो मिनट लगते हैं। महीनों बाद यह पता चलना कि किसी decommissioned server की एक key अब भी कुछ खोल देती है, कहीं ज़्यादा समय लेता है।
पूरा क्रम, एक ही page पर
तर्क हटा दें तो host migration नौ क़दमों का है, जिनमें से सिर्फ़ दो में ही कोई जल्दबाज़ी है:
- दो दिन पहले: DNS TTL को 300 seconds तक घटाएँ।
- दो दिन पहले: destination server order करें और उसे harden करें, पुराने stack से version-दर-version मेल बिठाते हुए।
- कई दिन पहले: inventory लिखें — cron, secrets, TLS, mail keys, media, IP allowlists, packages।
- कई दिन पहले: पहली पूरी data copy चलाएँ, host से host।
- window से पहले: DNS-01 से certificate जारी करें और सब कुछ
--resolveके ज़रिए test करें। - Window (मिनट): writes freeze करें, पुराना cron बंद करें, delta copy और आख़िरी dump चलाएँ, नया app शुरू करें।
- Window (seconds): A record बदलें, फिर नए host पर cron चालू करें।
- अगले हफ़्ते: पुराने server को rollback के तौर पर ज़िंदा रखें, दोनों log files देखते रहें, फिर TTL को दोबारा बढ़ा दें।
- बाद में: secrets rotate करें, wipe करें, cancel करें — और याद रखें कि move क्या नहीं मिटा सका।
उस list में कुछ भी मुश्किल नहीं है। जो भी क़दम तकलीफ़ देता है, वह ग़लत क्रम में उठाया गया क़दम होता है — रात को घटाया गया TTL, DNS बदलने के बाद जारी किया गया certificate, कोई cron job किसी ऐसी machine पर चालू छोड़ा गया जो अब authoritative नहीं रही। क्रम सही रखें, और फिर migration का दिलचस्प हिस्सा यह तय करना रह जाता है कि server कहाँ रखा जाए, न कि move ख़ुद। अगर आपने अभी तक यह तय नहीं किया, तो jurisdiction guide से शुरुआत करें।