ویب سائٹ کو نئے ہوسٹ پر تقریباً صفر ڈاؤن ٹائم کے ساتھ منتقل کرنے کا طریقہ

ویب سائٹ منتقلی ڈاؤن ٹائم کیوں پیدا کرتی ہے (اور اس سے کیسے بچا جائے)

زیادہ تر ویب سائٹ منتقلیاں اس لیے ناکام نہیں ہوتیں کہ فائلوں کی منتقلی مشکل ہوتی ہے، بلکہ DNS پروپیگیشن کی تاخیر کی وجہ سے ناکام ہوتی ہیں۔ جب آپ اپنے ڈومین کو نئے سرور کی طرف موڑتے ہیں، تو آپ کے DNS ریکارڈ کے TTL (Time To Live) کی بنیاد پر کچھ وزیٹرز منٹوں یا گھنٹوں تک پرانے سرور تک ہی رسائی جاری رکھتے ہیں۔ اگر اس دوران پرانا سرور بند کر دیا جائے یا ڈیٹابیس بیک وقت کئی جگہوں پر موجود ہو، تو آپ ٹرانزیکشنز اور سبمیشنز کھو دیں گے۔

اس کا حل یہ ہے کہ اصل سائٹ کو مکمل طور پر فعال رکھا جائے جبکہ نئے ہوسٹ پر اس کی ایک مکمل کام کرنے والی کاپی تیار کی جائے۔ سوئچ کرنے سے پہلے اسے اچھی طرح ٹیسٹ کریں، تیز کٹ اوور کے لیے پہلے سے اپنا TTL کم کر دیں، اور پھر ہی DNS ریکارڈز کو اپ ڈیٹ کریں۔ یہ طریقہ عام PHP/MySQL انسٹالیشنز (WordPress، Laravel، حسبِ ضرورت ایپلیکیشنز) کے لیے کام کرتا ہے، چاہے آپ اپنا سرور خود مینیج کر رہے ہوں یا cPanel/ویب ہوسٹنگ استعمال کر رہے ہوں۔

مرحلہ 1 — سب سے پہلے اپنا DNS TTL کم کریں (24–48 گھنٹے پہلے)

یہ سب سے اہم واحد قدم باقی ہر کام سے پہلے ہونا چاہیے۔ TTL یہ طے کرتا ہے کہ ریزولورز آپ کے ریکارڈز کو کتنی دیر تک کیش کرتے ہیں۔ 14400 سیکنڈ (4 گھنٹے) کے A ریکارڈ TTL کے ساتھ، آپ کے کٹ اوور کو مکمل طور پر پروپیگیٹ ہونے میں 4 گھنٹے تک لگ سکتے ہیں۔

اپنے 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 — نیا ہوسٹ مہیا کریں اور فائلیں کاپی کریں

سب سے پہلے نئے ہوسٹ پر اپنا اکاؤنٹ یا سرور بنائیں۔ نئے سرور کا IP ایڈریس نوٹ کر لیں۔

ان سرورز کے لیے جن پر SSH رسائی موجود ہے، rsync سب سے تیز اور قابلِ اعتماد کاپی فراہم کرتا ہے — یہ پرمیشنز محفوظ رکھتا ہے، دوبارہ شروع کیا جا سکتا ہے، اور صرف تبدیلیوں کو سنک کرنے کے لیے دوبارہ چلایا جا سکتا ہے:

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 سے زیادہ آسان ہوتی ہے۔ بہت سے فراہم کنندہ یہ منتقلی آپ کے لیے انجام دے دیں گے۔

مرحلہ 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. مانیٹرنگ، cron jobs، اور اپنی ایپ یا فائر وال میں کسی بھی ہارڈ کوڈڈ IPs کو اپ ڈیٹ کریں۔
4. لائیو نئے سرور پر فارمز اور پیمنٹس کو دوبارہ ٹیسٹ کریں۔

منتقلی چیک لسٹ

• [ ] TTL کو 300 پر کم کیا گیا (24–48 گھنٹے پہلے)
• [ ] نیا ہوسٹ مہیا کیا گیا، فائلیں rsync کے ذریعے کاپی کی گئیں
• [ ] ڈیٹابیس ایکسپورٹ اور امپورٹ کی گئی، کنفیگ اپ ڈیٹ کی گئی
• [ ] نئی سائٹ کو hosts فائل کے ذریعے ٹیسٹ کیا گیا
• [ ] پرانی سائٹ کو ریڈ-اونلی پر سیٹ کیا گیا، حتمی سنک مکمل
• [ ] DNS کو نئے IP کی طرف موڑ دیا گیا
• [ ] پرانے سرور کو 24–48 گھنٹے لائیو رکھا گیا
• [ ] ای میل/MX اور SSL کی تصدیق کی گئی
• [ ] TTL واپس بڑھا دیا گیا، پرانا سرور بند کر دیا گیا

احتیاط سے انجام دی جائے تو آپ کے وزیٹرز کبھی کوئی ایرر نہیں دیکھتے — صرف ایک تیز تر، اِن-کنگڈم سائٹ۔