[होम](https://servhidden.com/hi) /
[गोपनीयता होस्टिंग Guides](https://servhidden.com/hi/guides) /
Website को Offshore Hosting पर बिना Downtime के कैसे Migrate करें






परिचालन


# बिना Downtime के Offshore Hosting पर Migration



लगभग हर तकलीफ़देह migration एक technical नहीं बल्कि ordering की गड़बड़ी होती है — TTL दो दिन पहले की बजाय उसी रात घटाया गया, certificate DNS बदलने से पहले की बजाय बाद में जारी किया गया, cron job किसी ऐसे server पर चालू छोड़ दिया गया जो अब authoritative नहीं रहा। यह वह क्रम है जो downtime window को पूरी तरह हटा देता है, साथ ही वह हिस्सा जिसे आम guides छोड़ देती हैं: यह move आपके बारे में हमेशा के लिए क्या दर्ज कर देता है, और आप अब भी उसके बारे में क्या कर सकते हैं।


[गाइड पढ़ें](#guide-body)
[FAQ](#guide-faq)






## इस पेज पर




- [गाइड](#guide-body)

- [FAQ](#guide-faq)

- [संबंधित गाइड्स](#guide-related)

- [सुझाए गए पेज](#guide-cta)






KYC नहीं
केवल क्रिप्टो
लॉग नहीं
DMCA अनदेखा
पूर्ण रूट
NVMe SSD





17 मिनट पढ़ें
Aug 2026 को अपडेट किया

इस पेज पर

[01असल में "zero downtime" का मतलब क्या है](#असल-म-zero-downtime-क-मतलब-कय-ह)
[02move की योजना बनाने से दिनों पहले DNS TTL घटाएँ](#move-क-यजन-बनन-स-दन-पहल-dns-ttl-घटए)
[03जो move कर रहे हैं उसकी inventory बनाएँ, जो याद है उसकी नहीं](#ज-move-कर-रह-ह-उसक-inventory-बनए-ज-यद-ह-उसक-नह)
[04पहले नया server बनाएँ, और उस पर कुछ भी रखने से पहले उसे harden करें](#पहल-नय-server-बनए-और-उस-पर-कछ-भ-रखन-स-पहल-उस-harden-कर)
[05data को दो बार copy करें: पहले एक धीमा pass, फिर एक तेज़ pass](#data-क-द-बर-copy-कर-पहल-एक-धम-pass-फर-एक-तज-pass)
[06DNS को इसके होने का पता चलने से पहले नए server को test करें](#dns-क-इसक-हन-क-पत-चलन-स-पहल-नए-server-क-test-कर)
[07Cutover, क्रम में](#cutover-करम-म)
[08migration पीछे क्या छोड़ जाता है](#migration-पछ-कय-छड-जत-ह)
[09Domain का सवाल: उसे साथ ले जाएँ, या नए सिरे से शुरू करें?](#domain-क-सवल-उस-सथ-ल-जए-य-नए-सर-स-शर-कर)
[10पुराने host को सही तरीक़े से decommission करें](#परन-host-क-सह-तरक-स-decommission-कर)
[11पूरा क्रम, एक ही page पर](#पर-करम-एक-ह-page-पर)
[FAQCommon प्रश्न](#guide-faq)
[→सुझाए गए पेज](#guide-cta)







कोई भी 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 को चुनें।

दोनों servers एक साथ चलते हैं और DNS सबसे आख़िर में बदलता है — यही वजह है कि सही क्रम में किया गया cutover कोई window छोड़ता ही नहीं।

## 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।** .env files, 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](https://servhidden.com/hi/guides/first-hour-vps-hardening-checklist) बिल्कुल यही list है, और इसे किसी ऐसी machine पर लागू करना कहीं आसान है जिस पर अभी कुछ भी नहीं है। अगर data इतना संवेदनशील है कि आप उसके लिए jurisdiction बदल रहे हैं, तो यही सही पल है [आराम की हालत में encryption](https://servhidden.com/hi/guides/full-disk-encryption-on-a-vps) पर फ़ैसला लेने का, क्योंकि इसे बाद में जोड़ने का मतलब है एक और 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](https://servhidden.com/hi/guides/vps-backup-strategy) से 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 बंद करें।** नए वाले पर इन्हें शुरू करने से पहले यह करें, बाद में कभी नहीं।

- आख़िरी rsync delta 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](https://servhidden.com/hi/guides/server-opsec-staying-anonymous) उन आदतों को बताती है जो बाद में इसे साफ़ बनाए रखती हैं।

## 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](https://servhidden.com/hi/guides/anonymous-domain-registration-with-crypto) 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 या cpanel subdomain।

- उस 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](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction) से शुरुआत करें।





FAQ

## Host migration — अक्सर पूछे जाने वाले सवाल





### 01
मुझे असल में कितने downtime की उम्मीद रखनी चाहिए?



किसी static site के लिए, बिल्कुल कुछ नहीं — दोनों servers एक साथ वही content serve कर सकते हैं, इसलिए DNS बदलाव किसी को दिखता ही नहीं। database वाली किसी भी चीज़ के लिए, आपका downtime ठीक आपके write freeze जितना लंबा होता है, जो आमतौर पर दो से दस मिनट का होता है अगर आपने पहले से एक पूरी data copy चला रखी हो। जो संख्या मायने रखती है वह यह नहीं कि DNS कितनी तेज़ी से बदलता है; यह है कि आप window के दौरान कितना copy करते हैं। लगभग सब कुछ दिनों पहले copy कर लें, और window सिकुड़कर बस delta जितना रह जाता है।





### 02
DNS propagation में कितना समय लगता है?



कोई propagation होता ही नहीं — यह शब्द असल में एक ऐसी चीज़ बताता है जो होती ही नहीं। Resolvers बस आपके record को उतनी देर तक cache करते हैं जितना उसका TTL कहता है, और expire होने पर दोबारा पूछते हैं। अगर उस वक़्त लागू TTL 86400 था, तो कुछ resolvers अगले 24 घंटों तक पुराना IP ही देते रहेंगे। TTL को cutover से कम से कम एक पूरे पुराने-TTL period पहले 300 seconds तक घटा दें, और पूरा internet आपके बदलाव को पाँच मिनट के भीतर अपना लेता है।





### 03
क्या मुझे अपना domain भी move करना पड़ेगा?



नहीं। registrar और host पूरी तरह स्वतंत्र हैं, और domain को बिल्कुल जहाँ है वहीं छोड़कर site move करना पूरी तरह ठीक से चलता है। क्या आपको इसे move करना चाहिए, यह आपके migrate करने की वजह पर निर्भर करता है: अगर वजह jurisdiction, price या DMCA posture थी, तो domain को छेड़ें ही नहीं। अगर वजह anonymity थी, तो ध्यान रखें कि domain अपनी अलग history साथ लेकर चलता है — WHOIS archives वही details रखते हैं जिनके साथ वह पहली बार register हुआ था, और hosting में बदलाव उसे छूता ही नहीं।





### 04
क्या मैं बिना पुराने host को यह पता चले कि मैं कहाँ गया, migrate कर सकता हूँ?



नहीं, अगर आप दोनों machines के बीच सीधे copy करते हैं — एक सिरा दूसरे से जुड़ता है, और दोनों तरफ़ के access logs इसे दर्ज कर लेते हैं। अगर यह link सचमुच आपके threat model के लिए मायने रखता है, तो host से host copy करें ही नहीं: इसके बजाय नए server को अपने ख़ुद के off-site encrypted backup से restore करें, ताकि दोनों providers कभी कोई packet आपस में साझा ही न करें। जो भी करें, transfer को कभी ऐसे connection से शुरू न करें जो आपकी पहचान बताता हो, और पुराने provider के पास खोले गए किसी भी support ticket में destination का ज़िक्र न आने दें।





### 05
क्या मुझे OS या stack को भी उसी समय upgrade कर देना चाहिए?



नहीं, और यही सबसे आम ख़ुद-थोपी हुई migration विफलता है। एक बार में एक ही चीज़ बदलें। अगर cutover के बाद site बदतमीज़ी करे तो आप चाहते हैं कि उसकी वजह बताने वाला उम्मीदवार सिर्फ़ एक हो, न कि नई machine, नए PHP version और नए database major के बीच का कोई चुनाव। पुराने environment से version-दर-version मेल बिठाएँ, move पूरा करें, एक हफ़्ते के साफ़ logs की पुष्टि करें, फिर rollback की क्षमता के साथ अलग से upgrade करें।





### 06
क्या migrate करने से मेरी search rankings को नुक़सान पहुँचेगा?



कोई ख़ास फ़र्क़ नहीं, बशर्ते domain, URLs और content वही रहें — Google URLs को index करता है, IP addresses को नहीं, और सिर्फ़ host बदलना अपने आप में कोई ranking signal नहीं है। URL structure को बिल्कुल वही रखें, वही status codes लौटाएँ, और move को किसी redesign या URL scheme बदलाव के साथ न मिलाएँ। अगर आप इसकी बजाय किसी नए domain पर जा रहे हैं, तो सही 301 redirects के साथ भी कुछ समय के लिए गिरावट की उम्मीद रखें, और यह समझें कि वे redirects दोनों नामों को publicly भी जोड़ देते हैं।





### 07
क्या मुझे TLS certificates दोबारा जारी करने होंगे?



हाँ — नए server को अपना ख़ुद का certificate और private key चाहिए, और पुरानी key को आगे copy करते रहना एक बुरी आदत है, भले ही यह technically चल जाए। इसे cutover से पहले एक DNS-01 challenge के ज़रिए जारी करें, जो एक TXT record के ज़रिए validate होता है और इसलिए तब भी कामयाब रहता है जब A record अब भी पुराने host की तरफ़ इशारा कर रहा हो। DNS बदलने के बाद HTTP-01 का इंतज़ार करना, ठीक उसी window में certificate चेतावनियों का एक सिलसिला तय कर देता है जिसे आप बचाने की कोशिश कर रहे थे।





### 08
पुराने server को cancel करना कब सुरक्षित है?



पुरानी machine पर एक-दो हफ़्ते के ख़ामोश logs और नई पर साफ़ logs के बाद — यह देरी ही आपका rollback है, और इसकी क़ीमत बस कुछ dollars है। cancel करने से पहले जाँच लें कि अब कोई बाहरी चीज़ पुराने IP की तरफ़ इशारा नहीं करती, उस पर कभी रहे हर secret को rotate करें, फिर अपना data delete करके खाली जगह को overwrite कर दें। cancel सबसे आख़िर में करें। पहले terminate दबाना आपका database ऐसी disk पर छोड़ देता है जिस पर अब आपका control नहीं।




संबंधित गाइड्स

## पढ़ते रहें


[### How to चुनें an ऑफशोर होस्टिंग न्यायक्षेत्र in 2026

खरीदारी


ऑफशोर न्यायक्षेत्र चुनने के लिए एक व्यावहारिक decision framework: data-retention कानून, MLAT exposure, DMCA stance, अदालत की speed, और real-world प्रवर्तन — देश दर देश।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction)
[### Privacy-Critical Workloads के लिए VPS बनाम Dedicated सर्वर

खरीदारी


कब VPS पर्याप्त है, कब shared tenancy liability बन जाती है, और कब bare metal ही ईमानदार जवाब है। Hardware isolation, हाइपरवाइज़र risk, और cost बनाम जोखिम मॉडल।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/vps-vs-dedicated-for-privacy)
[### No-KYC VPS पर Self-Hosted VPN: WireGuard बनाम OpenVPN

परिचालन


स्व-होस्टेड VPN व्यावसायिक प्रदाताओं को क्यों मात देता है, और 2026 में WireGuard और OpenVPN गोपनीयता, प्रदर्शन और परिचालन जोखिम पर वास्तव में कैसे तुलना करते हैं।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### AI Inference के लिए RTX 4090 बनाम H100 SXM5 (और RTX 5090 कहाँ फिट होता है)

खरीदारी


2026 में self-होस्टेड LLM, image, video, voice और finetuning वर्कलोड के लिए कौन सा NVIDIA GPU चुनें: RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token और कब कौन जीतता है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/rtx-4090-vs-h100-for-ai-inference)
[### MT4 / MT5 / cTrader Forex Trading के लिए ऑफशोर Windows RDP

परिचालन


पूर्ण guide: forex trading के लिए Windows RDP क्यों, low-latency offshore क्षेत्राधिकार कैसे चुनें, MT4/MT5/cTrader/Expert Advisor सेटअप, broker servers पर latency, और no-KYC checkout path।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA-Ignored Hosting समझाया गया: 2026 में इसका असली मतलब क्या है

खरीदारी


"DMCA ignored" hosting वास्तव में आपको क्या देती है, कौन-सी jurisdictions इसे सच में back करती हैं, किन workloads को इसकी ज़रूरत है, और कौन-से copyright जाल इस शब्द के दायरे में नहीं आते।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/dmca-ignored-hosting-explained)
[### Crypto से Anonymous Domain Registration: 2026 में WHOIS Privacy

गोपनीयता


2026 की practical guide: बिना identity reveal किए domains register करने का तरीका — TLD के अनुसार WHOIS regimes, registrar चुनाव, crypto payment options, और वे operational गलतियाँ जो आपको leak करती हैं।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/anonymous-domain-registration-with-crypto)
[### क्रिप्टो Payments for होस्टिंग: Monero vs Bitcoin vs USDT

गोपनीयता


भुगतान कॉइन आपके होस्ट को आपके बारे में क्या पता चलता है इसे कैसे प्रभावित करता है। XMR, BTC और USDT के लिए गोपनीयता, शुल्क, finality और चेन विश्लेषण जोखिम — स्पष्ट सिफारिश के साथ।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### क्या Offshore Hosting सच में Anonymous है? एक ईमानदार जवाब

गोपनीयता


Offshore, no-KYC hosting वह identity हटा देती है जो एक normal host collect करता है — लेकिन "anonymous" होना payment, provider logging और आपकी अपनी opsec पर निर्भर करता है। यहाँ बताया गया है कि असल में क्या traceable है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/is-offshore-hosting-truly-anonymous)
[### VPS Hardening का पहला घंटा: एक Checklist

परिचालन


एक नए VPS को एक घंटे से कम में secure करने के लिए एक concrete, ordered checklist: SSH keys, एक firewall, fail2ban, automatic updates, और वह attack-surface reduction जो ज़्यादातर opportunistic attacks को रोकती है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/first-hour-vps-hardening-checklist)
[### No-KYC होस्टिंग क्या है? परिभाषा, वैधता और यह कैसे काम करती है

गोपनीयता


No-KYC होस्टिंग आपको बिना किसी पहचान सत्यापन के सर्वर किराये पर लेने देती है — न नाम, न ईमेल, न ID। यहाँ जानें इसका अर्थ, यह तकनीकी रूप से कैसे काम करता है, क्या यह कानूनी है, और असली प्रदाता को कैसे पहचानें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/what-is-no-kyc-hosting)
[### क्या ऑफशोर होस्टिंग कानूनी है? 2026 का स्पष्ट जवाब

खरीदारी


ऑफशोर होस्टिंग कानूनी है — आपके लिए भी और सेवा प्रदाता के लिए भी। यहाँ जानिए इस शब्द का वास्तविक अर्थ, कानूनी सीमा कहाँ है, कौन-सी भ्रांतियाँ छोड़ने योग्य हैं, और इसे जिम्मेदारी से कैसे उपयोग करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/is-offshore-hosting-legal)
[### Monero (XMR) से होस्टिंग का भुगतान कैसे करें — चरण-दर-चरण मार्गदर्शिका

गोपनीयता


VPS या डेडिकेटेड सर्वर के लिए Monero (XMR) से भुगतान की चरण-दर-चरण मार्गदर्शिका: XMR सबसे निजी विकल्प क्यों है, इसे कैसे प्राप्त करें, और चेकआउट प्रक्रिया कैसे काम करती है — इनवॉइस से लेकर कुछ ही मिनटों में चालू सर्वर तक।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-pay-for-hosting-with-monero)
[### गुमनाम तरीके से वेबसाइट होस्ट कैसे करें — एक व्यावहारिक 2026 गाइड

गोपनीयता


एक व्यावहारिक, बहु-स्तरीय गाइड जो बताती है कि बिना किसी पहचान के वेबसाइट कैसे होस्ट की जाए — अकाउंट, भुगतान, डोमेन, अधिकार क्षेत्र, कनेक्शन और कंटेंट — हर परत को विस्तार से समझाया गया है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-host-a-website-anonymously)
[### VPS पर WireGuard VPN कैसे सेटअप करें — चरण-दर-चरण गाइड

परिचालन


WireGuard से अपना निजी VPN बनाएं एक VPS पर: यह जानें कि self-hosted VPN किसी व्यावसायिक VPN से बेहतर क्यों है, इंस्टॉलेशन से लेकर कनेक्टेड क्लाइंट तक का पूरा सेटअप, और इसे कैसे सुरक्षित करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### GPU सर्वर पर LLM को स्व-होस्ट कैसे करें — 2026 गाइड

परिचालन


किराये के GPU सर्वर पर अपना खुद का लार्ज लैंग्वेज मॉडल चलाएँ: API की तुलना में स्व-होस्टिंग क्यों बेहतर है, कौन-सा GPU और मॉडल चुनें, Ollama या vLLM के साथ सेटअप कैसे करें, और इसकी लागत क्या है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting बनाम Offshore Hosting — क्या है अंतर?

खरीदारी


Bulletproof hosting और offshore hosting को अक्सर एक-दूसरे का पर्याय मान लिया जाता है — लेकिन ये एक नहीं हैं। यहाँ जानें असली अंतर, यह क्यों मायने रखता है, और आपको वास्तव में किसकी जरूरत है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/bulletproof-vs-offshore-hosting)
[### Bitcoin से VPS कैसे खरीदें — चरण-दर-चरण गाइड (2026)

खरीदारी


Bitcoin से VPS खरीदने की शुरुआती-अनुकूल मार्गदर्शिका: BTC प्राप्त करना, प्लान चुनना, इनवॉइस का भुगतान करना और क्या मिलता है — बिना कार्ड और बिना नाम के एक चालू सर्वर।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-buy-a-vps-with-bitcoin)
[### 2026 में DMCA-ignored होस्टिंग के लिए सर्वश्रेष्ठ देश

खरीदारी


जब आप ऐसे सर्वर चाहते हैं जो US-शैली के टेकडाउन से परे हों — तो कहाँ होस्ट करें: वे क्षेत्राधिकार जो काम करते हैं, DMCA-ignored का वास्तविक अर्थ, और सही चुनाव कैसे करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/best-countries-for-dmca-ignored-hosting)
[### Tor हिडन सर्विस (.onion साइट) कैसे होस्ट करें — 2026 गाइड

परिचालन


VPS पर Tor onion सर्विस सेट करें: हिडन सर्विस क्या है, यह अनाम होस्टिंग का सबसे मज़बूत रूप क्यों है, पूरा सेटअप, और इसे वास्तव में अनाम कैसे रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-host-a-tor-hidden-service)
[### ऑफशोर मेल सर्वर सेटअप — 2026 में खुद का प्राइवेट ईमेल होस्ट करें

परिचालन


एक ऑफशोर VPS पर अपना खुद का प्राइवेट ईमेल सर्वर चलाएं: सेल्फ-होस्ट ईमेल क्यों करें, इसके लिए क्या चाहिए, ऑल-इन-वन मेल स्टैक के साथ व्यावहारिक सेटअप, और डिलीवरेबिलिटी कैसे सही रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/offshore-mail-server-setup)
[### क्रिप्टो नोड होस्टिंग गाइड — VPS पर ब्लॉकचेन नोड चलाएं

परिचालन


सर्वर पर ब्लॉकचेन नोड कैसे होस्ट करें: अपना नोड चलाने के फायदे, Bitcoin, Ethereum, Monero आदि के लिए सर्वर का आकार, सेटअप प्रक्रिया और इसे निजी रखने के तरीके।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/crypto-node-hosting-guide)
[### Stable Diffusion के लिए GPU होस्टिंग — अपना खुद का इमेज सर्वर चलाएं

परिचालन


अपने खुद के GPU सर्वर पर Stable Diffusion चलाएं: इमेज जनरेशन को सेल्फ-होस्ट क्यों करें, कौन सा GPU चुनें, वेब UI के साथ सेटअप कैसे करें, और होस्टेड सेवा की तुलना में इसकी लागत क्या है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/gpu-hosting-for-stable-diffusion)
[### सर्वर OpSec — सर्वर चलाते समय गुमनाम कैसे रहें

गोपनीयता


गुमनाम सर्वर चलाने वाले किसी भी व्यक्ति के लिए परिचालन सुरक्षा: वे गलतियाँ जो पहचान उजागर करती हैं, वे आदतें जो उन्हें रोकती हैं, और पहचान को वास्तव में अलग कैसे रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/server-opsec-staying-anonymous)
[### Seedbox सेटअप गाइड — 2026 में अपना निजी Seedbox बनाएँ

परिचालन


अपने सर्वर पर खुद का seedbox कैसे बनाएँ: seedbox क्या होता है, उसकी साइज़िंग, web UI के साथ torrent client की इंस्टॉलेशन, और उसे निजी व सुरक्षित रखना।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/seedbox-setup-guide)
[### अपने खुद के VPS से DPI सेंसरशिप को कैसे बायपास करें (2026 गाइड)

गोपनीयता


आपका VPN काम करना बंद कर चुका है? अपने खुद के VPS से DPI सेंसरशिप बायपास करने का तरीका: डीप पैकेट इंस्पेक्शन असल में क्या पहचानता है, 2026 के पांच प्रोटोकॉल में से कौन-सा किस ब्लॉक को मात देता है, और एक पूरा VLESS+REALITY वॉकथ्रू।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/bypass-dpi-censorship-with-your-own-vps)
[### VPS पर फुल-डिस्क एन्क्रिप्शन: LUKS सेटअप और यह असल में क्या सुरक्षित करता है

परिचालन


LUKS से VPS एन्क्रिप्ट करने का तरीका: एन्क्रिप्टेड डेटा वॉल्यूम, SSH पर रिमोट अनलॉक वाला फुल-रूट एन्क्रिप्शन, छोटे सर्वर पर मायने रखने वाली सेटिंग्स, और डिस्क एन्क्रिप्शन असल में क्या रोकता है इसका ईमानदार ब्योरा।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/full-disk-encryption-on-a-vps)
[### ओरिजिन सर्वर IP छुपाना: CDN, रिवर्स प्रॉक्सी और जो फिर भी लीक होता है

गोपनीयता


ऑफ़शोर सर्वर के आगे CDN लगाएँ या नहीं: यह क्या छुपाता है, साथ में कौन-सी शिकायत डेस्क मिलती है, वे छह तरीके जिनसे ओरिजिन IP फिर भी लीक होता है, और अपना ऑडिट कैसे करें।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/hiding-your-origin-server-ip)
[### VPS Backup कैसे लें: Encrypted, Off-Site और भरोसेमंद Restore

परिचालन


आपका host कोई backup नहीं रखता। server को असल में क्या बर्बाद करता है, push backup साथ में क्यों मरता है, restic बनाम BorgBackup, और restore टेस्ट करने का तरीक़ा।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/vps-backup-strategy)
[### खुद का Matrix Server Self-Host करें: Federation, Metadata और E2EE की सीमाएँ

परिचालन


अपने खुद के Matrix homeserver से असल में क्या मिलता है: Synapse बनाम Conduit, वह server_name जिसे आप बदल नहीं सकते, डिस्क भरने वाला media, और federation का एक्सपोज़र।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-a-matrix-server)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

परिचालन


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-a-crypto-payment-gateway)




## Migration को उतरने के लिए एक जगह दें



सात jurisdictions में offshore KVM servers, $7.50/माह से शुरू, पूरे root access, NVMe storage और unmetered bandwidth के साथ, crypto payment confirm होते ही पाँच मिनट से भी कम में deploy। destination को जल्दी खड़ा करें, अपनी रफ़्तार से copy करें, और जब तैयार हो तब cut over करें।


[VPS प्लान देखें](https://servhidden.com/hi/vps)
[ऑफशोर होस्टिंग](https://servhidden.com/hi/offshore-hosting)
[सभी लोकेशन](https://servhidden.com/hi/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "7 ऑफशोर न्यायक्षेत्रों में ऑफशोर VPS और डेडिकेटेड सर्वर। KYC नहीं, लॉग नहीं, केवल क्रिप्टो। आर्किटेक्चर से ही गोपनीयता।",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Website को Offshore Hosting पर बिना Downtime के कैसे Migrate करें",
    "description": "host migration को उबाऊ बनाने वाला क्रम: DNS TTL दिनों पहले घटाएँ, दोनों servers साथ चलाएँ, writes को घंटों की बजाय मिनटों तक freeze करें — और migration के पीछे छूटी passive-DNS, Certificate Transparency और WHOIS trail को साफ़ करें।",
    "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-29T00:00:00+00:00",
    "dateModified": "2026-08-29T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting",
    "inLanguage": "hi",
    "keywords": "website ko offshore hosting par kaise migrate karein, bina downtime ke hosting provider badalna, zero downtime server migration, VPS ko naye host par move karna, DNS TTL cutover kaise karein, no-KYC host par website migrate karna, website migration checklist, rsync se server migration",
    "articleSection": "परिचालन",
    "wordCount": 3271
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "मुझे असल में कितने downtime की उम्मीद रखनी चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "किसी static site के लिए, बिल्कुल कुछ नहीं — दोनों servers एक साथ वही content serve कर सकते हैं, इसलिए DNS बदलाव किसी को दिखता ही नहीं। database वाली किसी भी चीज़ के लिए, आपका downtime ठीक आपके write freeze जितना लंबा होता है, जो आमतौर पर दो से दस मिनट का होता है अगर आपने पहले से एक पूरी data copy चला रखी हो। जो संख्या मायने रखती है वह यह नहीं कि DNS कितनी तेज़ी से बदलता है; यह है कि आप window के दौरान कितना copy करते हैं। लगभग सब कुछ दिनों पहले copy कर लें, और window सिकुड़कर बस delta जितना रह जाता है।"
            }
        },
        {
            "@type": "Question",
            "name": "DNS propagation में कितना समय लगता है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "कोई propagation होता ही नहीं — यह शब्द असल में एक ऐसी चीज़ बताता है जो होती ही नहीं। Resolvers बस आपके record को उतनी देर तक cache करते हैं जितना उसका TTL कहता है, और expire होने पर दोबारा पूछते हैं। अगर उस वक़्त लागू TTL 86400 था, तो कुछ resolvers अगले 24 घंटों तक पुराना IP ही देते रहेंगे। TTL को cutover से कम से कम एक पूरे पुराने-TTL period पहले 300 seconds तक घटा दें, और पूरा internet आपके बदलाव को पाँच मिनट के भीतर अपना लेता है।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मुझे अपना domain भी move करना पड़ेगा?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं। registrar और host पूरी तरह स्वतंत्र हैं, और domain को बिल्कुल जहाँ है वहीं छोड़कर site move करना पूरी तरह ठीक से चलता है। क्या आपको इसे move करना चाहिए, यह आपके migrate करने की वजह पर निर्भर करता है: अगर वजह jurisdiction, price या DMCA posture थी, तो domain को छेड़ें ही नहीं। अगर वजह anonymity थी, तो ध्यान रखें कि domain अपनी अलग history साथ लेकर चलता है — WHOIS archives वही details रखते हैं जिनके साथ वह पहली बार register हुआ था, और hosting में बदलाव उसे छूता ही नहीं।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मैं बिना पुराने host को यह पता चले कि मैं कहाँ गया, migrate कर सकता हूँ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं, अगर आप दोनों machines के बीच सीधे copy करते हैं — एक सिरा दूसरे से जुड़ता है, और दोनों तरफ़ के access logs इसे दर्ज कर लेते हैं। अगर यह link सचमुच आपके threat model के लिए मायने रखता है, तो host से host copy करें ही नहीं: इसके बजाय नए server को अपने ख़ुद के off-site encrypted backup से restore करें, ताकि दोनों providers कभी कोई packet आपस में साझा ही न करें। जो भी करें, transfer को कभी ऐसे connection से शुरू न करें जो आपकी पहचान बताता हो, और पुराने provider के पास खोले गए किसी भी support ticket में destination का ज़िक्र न आने दें।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मुझे OS या stack को भी उसी समय upgrade कर देना चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं, और यही सबसे आम ख़ुद-थोपी हुई migration विफलता है। एक बार में एक ही चीज़ बदलें। अगर cutover के बाद site बदतमीज़ी करे तो आप चाहते हैं कि उसकी वजह बताने वाला उम्मीदवार सिर्फ़ एक हो, न कि नई machine, नए PHP version और नए database major के बीच का कोई चुनाव। पुराने environment से version-दर-version मेल बिठाएँ, move पूरा करें, एक हफ़्ते के साफ़ logs की पुष्टि करें, फिर rollback की क्षमता के साथ अलग से upgrade करें।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या migrate करने से मेरी search rankings को नुक़सान पहुँचेगा?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "कोई ख़ास फ़र्क़ नहीं, बशर्ते domain, URLs और content वही रहें — Google URLs को index करता है, IP addresses को नहीं, और सिर्फ़ host बदलना अपने आप में कोई ranking signal नहीं है। URL structure को बिल्कुल वही रखें, वही status codes लौटाएँ, और move को किसी redesign या URL scheme बदलाव के साथ न मिलाएँ। अगर आप इसकी बजाय किसी नए domain पर जा रहे हैं, तो सही 301 redirects के साथ भी कुछ समय के लिए गिरावट की उम्मीद रखें, और यह समझें कि वे redirects दोनों नामों को publicly भी जोड़ देते हैं।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या मुझे TLS certificates दोबारा जारी करने होंगे?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "हाँ — नए server को अपना ख़ुद का certificate और private key चाहिए, और पुरानी key को आगे copy करते रहना एक बुरी आदत है, भले ही यह technically चल जाए। इसे cutover से पहले एक DNS-01 challenge के ज़रिए जारी करें, जो एक TXT record के ज़रिए validate होता है और इसलिए तब भी कामयाब रहता है जब A record अब भी पुराने host की तरफ़ इशारा कर रहा हो। DNS बदलने के बाद HTTP-01 का इंतज़ार करना, ठीक उसी window में certificate चेतावनियों का एक सिलसिला तय कर देता है जिसे आप बचाने की कोशिश कर रहे थे।"
            }
        },
        {
            "@type": "Question",
            "name": "पुराने server को cancel करना कब सुरक्षित है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "पुरानी machine पर एक-दो हफ़्ते के ख़ामोश logs और नई पर साफ़ logs के बाद — यह देरी ही आपका rollback है, और इसकी क़ीमत बस कुछ dollars है। cancel करने से पहले जाँच लें कि अब कोई बाहरी चीज़ पुराने IP की तरफ़ इशारा नहीं करती, उस पर कभी रहे हर secret को rotate करें, फिर अपना data delete करके खाली जगह को overwrite कर दें। cancel सबसे आख़िर में करें। पहले terminate दबाना आपका database ऐसी disk पर छोड़ देता है जिस पर अब आपका control नहीं।"
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "होम",
            "item": "https://servhidden.com/hi/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "गोपनीयता होस्टिंग Guides",
            "item": "https://servhidden.com/hi/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Website को Offshore Hosting पर बिना Downtime के कैसे Migrate करें",
            "item": "https://servhidden.com/hi/guides/migrate-website-to-offshore-hosting"
        }
    ]
}
```