SSH کے ذریعے rsync کمانڈ کے ساتھ دو سرورز کے درمیان بڑے فائلوں کی تیز رفتار منتقلی

SSH کے ذریعے rsync کمانڈ، دو سرورز کے درمیان بڑی فائلوں کو تیز، محفوظ اور مستحکم طریقے سے منتقل کرنے کے لیے استعمال ہونے والے سب سے عملی لینکس طریقوں میں سے ایک ہے۔ خاص طور پر جب سیکڑوں GB کی ویب سائٹ کی فائلیں، بیک اپ آرکائیو، میڈیا فولڈرز یا ایپلیکیشن کے ڈیٹا منتقل کیے جا رہے ہوں تو rsync صرف تبدیل ہونے والے بلاکس کو منتقل کرنے کی وجہ سے روایتی کاپی کرنے کے طریقوں کے مقابلے میں نمایاں رفتار کا فائدہ فراہم کرتا ہے۔ بنیادی استعمال کا نظریہ یہ ہے: ماخذ سرور پر موجود فائلیں، SSH سرنگ کے ذریعے ہدف سرور پر خفیہ طور پر ہم آہنگ کی جاتی ہیں؛ اگر کنکشن ٹوٹ جائے تو عمل وہیں سے جاری رکھا جا سکتا ہے۔

سرور کی منتقلی، ہوسٹنگ کی ترقی، ڈیٹا سینٹر کی تبدیلی یا بیک اپ آپریشنز میں رفتار کے ساتھ ساتھ ڈیٹا کی سالمیت بھی اہم ہے۔ ایک بڑی آرکائیو کو ایک ہی بار میں ڈاؤن لوڈ اور دوبارہ اپ لوڈ کرنا وقت کا ضیاع کرتا ہے اور کنکشن کی خرابیوں کی صورت میں آپ کو دوبارہ شروع ہونے پر مجبور کر سکتا ہے۔ rsync یہاں مدد کرتا ہے کہ وہ فائل کے ٹائم اسٹیمپ، اجازتیں، ملکیت کی معلومات اور فولڈر کی ساخت کو محفوظ رکھ سکتا ہے۔ اس لیے لینکس سسٹم کے منتظمین، ڈی اوپس ٹیموں اور ویب ہوسٹنگ کے ماہرین روزانہ کی کارروائیوں میں اس کا اکثر انتخاب کرتے ہیں۔

اس رہنما میں، ہم دو لینکس سرورز کے درمیان SSH کے ذریعے rsync کے ساتھ بڑی فائلوں کو منتقل کرنے کے عمل کو حقیقی کمانڈ کی مثالوں کے ساتھ مرحلہ وار پیش کریں گے۔ ہم کارکردگی بڑھانے کے پیرامیٹرز، سیکیورٹی چیک، غلطی کے منظرنامے، ٹیسٹ کی منتقلی کے طریقے اور پروڈکشن ماحول میں جانے سے پہلے جن چیزوں کا خیال رکھنا ہے ان کا بھی اشتراک کریں گے۔ اگر آپ ایک نئے VPS یا ہوسٹنگ ماحول میں منتقل ہونے کا منصوبہ بنا رہے ہیں تو اس رہنما کو نافذ کرنے سے پہلے اپنے ماخذ اور ہدف سرور پر کافی ڈسک کی گنجائش، SSH تک رسائی اور درست صارف کی اجازتوں کو یقینی بنائیں۔ متعلقہ بنیادی ڈھانچے کے انتخاب کے لیے Hostragons VPS سرور کے حل اور لینکس ہوسٹنگ کے پیکج صفحات کا جائزہ لے سکتے ہیں۔

rsync کیا ہے اور بڑے فائلوں کی منتقلی میں اسے کیوں ترجیح دی جاتی ہے؟

rsync، فائلوں اور ڈائریکٹریوں کو مقامی سسٹم یا دور دراز کے سرورز کے درمیان ہم آہنگ کرنے کے لیے ایک طاقتور کمانڈ لائن ٹول ہے۔ اس کی سب سے اہم خصوصیت ڈیٹا کی منتقلی کا الگورڈم ہے۔ یہ الگورڈم، ہر بار فائل کو دوبارہ بھیجنے کے بجائے صرف تبدیل ہونے والے حصے کو دوسری طرف منتقل کرتا ہے۔ مثلاً اگر 80 GB کے بیک اپ فائل میں صرف 2 GB کی تبدیلی ہے تو مناسب حالات میں پوری فائل کو دوبارہ منتقل کرنے کے بجائے صرف تبدیل ہونے والے بلاکس کو منتقل کرنا ممکن ہے۔

SSH، منتقلی کو خفیہ بناتا ہے۔ اس طرح rsync کمانڈ، نیٹ ورک کے ذریعے ڈیٹا منتقل کرتے وقت فائل کے مواد کو سادہ متن کے طور پر نہیں بھیجتا۔ یہ خصوصیت خاص طور پر صارف کے ڈیٹا، ای کامرس آرڈر ریکارڈز، میڈیا آرکائیو، ڈیٹا بیس کے بیک اپ اور خصوصی ایپلیکیشن کی فائلوں کے لیے اہم ہے۔ ہوسٹنگ کی دنیا میں، ڈیٹا کی سیکیورٹی صرف SSL سرٹیفکیٹ تک محدود نہیں ہے؛ سرورز کے درمیان منتقل ہونے والا چینل بھی محفوظ ہونا چاہیے۔ ویب سائٹ کے ٹریفک کے لیے SSL سرٹیفکیٹ استعمال کرتے وقت، سرورز کے درمیان فائل کی منتقلی میں بھی SSH کے ساتھ خفیہ کاری کو ترجیح دینی چاہیے۔

rsync، FTP یا دستی ڈاؤن لوڈ-اپ لوڈ طریقوں کے مقابلے میں زیادہ لچکدار ہے۔ یہ اجازتوں کو محفوظ رکھ سکتا ہے، علامتی روابط منتقل کر سکتا ہے، ہدف پر حذف کردہ فائلوں کو بھی حذف کر سکتا ہے، بینڈوڈتھ کو محدود کر سکتا ہے اور منتقلی سے پہلے کیا کرنا ہے اس کی جانچ کر سکتا ہے۔ بڑے فائلوں کی منتقلی جیسے خطرناک عمل میں یہ کنٹرول کی سطح اہم فوائد فراہم کرتی ہے۔

آپ کو کب SSH کے ذریعے rsync کمانڈ استعمال کرنی چاہیے؟

SSH کے ذریعے rsync کمانڈ خاص طور پر بڑی، متعدد یا بار بار تبدیل ہونے والی فائلوں کی منتقلی کے لیے مثالی ہے۔ سادہ بصری فولڈر کے لیے دستی SFTP کافی ہو سکتا ہے؛ تاہم ہزاروں فائلوں، مختلف اجازتوں اور بڑی آرکائیو کی صورت میں rsync زیادہ قابل اعتماد آپشن بن جاتا ہے۔

• اگر آپ پرانے سرور سے نئے VPS سرور پر ویب سائٹ منتقل کر رہے ہیں۔
• اگر آپ ورڈپریس اپ لوڈ فولڈر جیسے ہزاروں میڈیا فائلوں پر مشتمل ڈائریکٹریز منتقل کر رہے ہیں۔
• اگر آپ روزانہ، ہفتہ وار یا ماہانہ بیک اپ کو مختلف سرور پر کاپی کر رہے ہیں۔
• اگر آپ ڈیٹا سینٹر یا ہوسٹنگ فراہم کنندہ کی تبدیلی کر رہے ہیں۔
• اگر آپ ایپلیکیشن کی فائلوں کو پروڈکشن اور بیک اپ ماحول کے درمیان ہم آہنگ کر رہے ہیں۔
• اگر آپ طویل مدتی منتقلی کی منصوبہ بندی کر رہے ہیں جس میں کنکشن کے ٹوٹنے کا امکان ہو۔

مثال کے طور پر، اگر آپ 250 GB کا میڈیا فولڈر اپنے ڈیسک ٹاپ کمپیوٹر پر ڈاؤن لوڈ کرتے ہیں اور پھر اسے نئے سرور پر اپ لوڈ کرتے ہیں تو اس کا مطلب ہے کہ آپ کو دو علیحدہ منتقلی کرنی ہوں گی۔ یہ مجموعی وقت کو بڑھاتا ہے اور آپ کے گھر یا دفتر کے انٹرنیٹ کنکشن کو ناکافی بنا دیتا ہے۔ rsync کے ذریعے، آپ ماخذ سرور سے ہدف سرور پر براہ راست منتقلی کر کے اس درمیانی مرحلے کو ختم کر سکتے ہیں۔

شروع کرنے سے پہلے ضروریات

ایک کامیاب rsync آپریشن کے لیے کمانڈ جاننا کافی نہیں ہے۔ ماخذ اور ہدف سرور کی حالتوں کو چیک کرنا، عمل کے دوران ممکنہ ڈیٹا کے نقصان یا آدھی منتقلی کے خطرے کو کم کرتا ہے۔ ذیل میں دیے گئے چیک پروڈکشن ماحول میں ضرور کیے جانے چاہئیں۔

1. SSH کی رسائی کی تصدیق کریں

ماخذ سرور سے ہدف سرور پر SSH کنکشن قائم کیا جا سکنا چاہیے۔ معیاری کنکشن کو اس طرح جانچا جا سکتا ہے: ssh صارف@ہدف-سرور-ip۔ اگر SSH مختلف پورٹ پر چل رہا ہے تو کنکشن کو اس منطقی طریقے سے آزمایا جا سکتا ہے: ssh -p 2222 صارف@ہدف-سرور-ip۔ اگر یہ ٹیسٹ کامیاب نہیں ہے تو rsync بھی کام نہیں کرے گا۔ سیکیورٹی کی دیوار، Fail2ban، SSH پورٹ، صارف کی اجازت اور پاس ورڈ یا کلید کی تصدیق کو چیک کرنا چاہیے۔

2. rsync پیکیج کی تنصیب کی تصدیق کریں

زیادہ تر لینکس ڈسٹری بیوشن میں rsync پہلے سے ہی انسٹال ہوتا ہے؛ تاہم، اس کی تصدیق کرنا ضروری ہے۔ ڈیبین اور اوبنٹو پر مبنی سسٹمز میں rsync --version کمانڈ استعمال کی جا سکتی ہے۔ اگر یہ انسٹال نہیں ہے تو apt install rsync کے ساتھ انسٹال کیا جا سکتا ہے۔ AlmaLinux، Rocky Linux یا CentOS کی شاخوں میں dnf install rsync یا yum install rsync کمانڈ کا انتخاب کیا جاتا ہے۔ اگر آپ Hostragons پر لینکس پر مبنی VPS استعمال کر رہے ہیں تو تنصیب عام طور پر چند سیکنڈز میں مکمل ہو جاتی ہے۔

3. ڈسک کی جگہ کا حساب لگائیں

اگر ہدف سرور پر کافی خالی جگہ نہیں ہے تو منتقلی ادھوری رہ جائے گی۔ ماخذ ڈائریکٹری کے سائز کو جانچنے کے لیے du -sh /ماخذ/ڈائریکٹری کی منطق استعمال کی جا سکتی ہے۔ ہدف پر df -h کمانڈ کے ذریعے ڈسک کی حالت کو جانچنا چاہیے۔ عملی طور پر، صرف فائل کے سائز کے برابر جگہ نہیں بلکہ عارضی فائلوں اور لاگ کے لیے بھی جگہ رکھنی چاہیے۔ مثال کے طور پر، اگر آپ 500 GB ڈیٹا منتقل کرنے جا رہے ہیں تو ہدف پر کم از کم 550-600 GB کی دستیاب جگہ کا منصوبہ بنانا زیادہ صحت مند ہے۔

4. اہم خدمات اور تبدیل ہونے والی فائلوں کی منصوبہ بندی کریں

چلتے ہوئے ویب سائٹس میں فائلیں منتقلی کے دوران تبدیل ہو سکتی ہیں۔ خاص طور پر صارف کی اپ لوڈز، کیشے فولڈرز اور لاگ فائلیں مسلسل اپ ڈیٹ ہوتی ہیں۔ بڑے منتقلی میں پہلے بنیادی ڈیٹا منتقل کیا جاتا ہے، اس کے بعد دیکھ بھال کے موڈ میں لے جایا جاتا ہے اور ایک آخری rsync چلایا جاتا ہے۔ اس طرح، بندش کا وقت چند منٹوں تک کم کیا جا سکتا ہے۔ ورڈپریس کی ویب سائٹس کے لیے WordPress ہوسٹنگ کی منتقلی کی رہنمائی جیسی سپورٹ مواد کے ساتھ اپنی عمل کی منصوبہ بندی مکمل کر سکتے ہیں۔

بنیادی rsync کمانڈ: دو سرورز کے درمیان فائل کی منتقلی

سب سے زیادہ استعمال ہونے والی بنیادی ساخت یہ ہے: rsync -avz /ماخذ/ڈائریکٹری/ صارف@ہدف-ip:/ہدف/ڈائریکٹری/۔ یہاں -a آرکائیو موڈ ہے اور یہ اجازتیں، وقت کے نشان، علامتی روابط جیسے معلومات کو محفوظ رکھنے کی کوشش کرتا ہے۔ -v تفصیلی آؤٹ پٹ دیتا ہے۔ -z منتقلی کے دوران کمپریشن کرتا ہے۔ ڈائریکٹری کے آخر میں موجود سلیش ایک اہم تفصیل ہے۔ اگر آپ /ماخذ/ڈائریکٹری/ لکھتے ہیں تو ڈائریکٹری کا مواد ہدف پر کاپی کیا جائے گا؛ اگر آپ /ماخذ/ڈائریکٹری لکھتے ہیں تو ڈائریکٹری خود ہدف کے تحت بنائی جائے گی۔

ایک مثال کا منظر نامہ سوچیں: آپ پرانے سرور میں /var/www/site/public_html/ فولڈر میں موجود 180 GB ویب فائلوں کو نئے سرور میں /var/www/site/public_html/ ڈائریکٹری میں منتقل کرنا چاہتے ہیں۔ کمانڈ اس منطقی طریقے سے کام کرتی ہے: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/۔ یہ عمل ماخذ سرور سے ہدف سرور پر SSH کے ذریعے فائل کی منتقلی کرتا ہے۔

اگر آپ root کا استعمال نہیں کرنا چاہتے تو ہدف سرور میں متعلقہ ڈائریکٹری میں لکھنے کی اجازت رکھنے والے خصوصی صارف کی تخلیق کرنا زیادہ محفوظ ہے۔ مثال کے طور پر، آپ deploy نامی صارف کا استعمال کر سکتے ہیں اور ضروری فولڈر کی ملکیت کو اس کے مطابق ترتیب دے سکتے ہیں۔ پروڈکشن ماحول میں براہ راست root کے ساتھ کارروائی کرنا عملی ہو سکتا ہے لیکن سیکیورٹی کے لحاظ سے محدود اختیارات والے صارف کا انتخاب کرنا زیادہ مناسب ہے۔

مجوزہ محفوظ اور مستحکم rsync پیرامیٹرز

بڑی فائل کی منتقلی میں صرف بنیادی کمانڈ پر اکتفا کرنا ہمیشہ درست نہیں ہوتا۔ کنکشن کی خرابی، جزوی فائلیں، غلط حذف کے عمل یا سست نیٹ ورکس کے لیے اضافی پیرامیٹرز کا استعمال کرنا ضروری ہے۔ ذیل کی کمانڈ، بہت سے حقیقی منتقلی کے منظرناموں کے لیے ایک مضبوط نقطہ آغاز ہے:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /ماخذ/ڈائریکٹری/ صارف@ہدف-ip:/ہدف/ڈائریکٹری/

اس کمانڈ میں -a آرکائیو موڈ کو، -H ہارڈ لنک کی معلومات کو، -A ACL اجازتوں کو، -X توسیعی خصوصیات کی قیمتوں کو محفوظ رکھنے میں مدد کرتا ہے۔ --numeric-ids صارف اور گروپ کے ناموں کے بجائے ID قیمتوں کی بنیاد پر کام کرتا ہے؛ مختلف سرورز پر صارف کے نام تبدیل ہونے پر یہ فائدہ مند ہو سکتا ہے۔ --partial جزوی فائلوں کو حذف کیے بغیر چھوڑ دیتا ہے۔ --progress منتقلی کی حالت کو دکھاتا ہے۔ --append-verify خاص طور پر بڑی فائلوں میں جہاں سے جاری رکھتا ہے اس کے اضافے کو درست کرنے میں مدد کرتا ہے۔

ہر پیرامیٹر ہر نظام میں ضروری نہیں ہو سکتا۔ مثال کے طور پر، ایک سادہ ویب سائٹ کی منتقلی میں -aHAX کا استعمال کافی ہو سکتا ہے جبکہ خصوصی فائل کی اجازتوں کے ساتھ استعمال ہونے والی ایپلیکیشن میں ACL اور توسیعی خصوصیات کی معلومات کا محفوظ رکھنا اہم ہو جاتا ہے۔ اس لیے پہلے ٹیسٹ کی منتقلی کرنا اہم ہے۔

اگر آپ مختلف SSH پورٹ استعمال کر رہے ہیں تو کمانڈ کیسی ہونی چاہیے؟

سیکیورٹی کے لیے SSH پورٹ 22 کے بجائے مختلف پورٹ پر چل سکتا ہے۔ اس صورت میں rsync میں SSH پیرامیٹر کی وضاحت کی جاتی ہے۔ مثال: rsync -avz -e ssh -p 2222 /ماخذ/ڈائریکٹری/ صارف@ہدف-ip:/ہدف/ڈائریکٹری/۔ تاہم کمانڈ لائن میں -e پیرامیٹر کی قیمت کو ساتھ استعمال کیا جانا چاہیے۔ درست استعمال کا نظریہ یہ ہے: rsync -avz -e 'ssh -p 2222' /ماخذ/ڈائریکٹری/ صارف@ہدف-ip:/ہدف/ڈائریکٹری/۔

JSON اور کچھ پینل میں سنگل کوٹ کا استعمال مختلف رویہ اختیار کر سکتا ہے، اس لیے ٹرمینل میں براہ راست لکھتے وقت کوٹ کے صحیح ہونے کو یقینی بنائیں۔ اگر آپ SSH کلید کے ذریعے کنکشن قائم کر رہے ہیں تو -i پیرامیٹر بھی شامل کیا جا سکتا ہے: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /ماخذ/ڈائریکٹری/ صارف@ہدف-ip:/ہدف/ڈائریکٹری/۔ یہ طریقہ خودکار اور کرون کی بنیاد پر بیک اپ کے کاموں میں اکثر استعمال ہوتا ہے۔

منتقلی سے پہلے کا ٹیسٹ: --dry-run کا استعمال

بڑے ڈیٹا کی منتقلی سے پہلے کیے جانے والے سب سے پیشہ ورانہ اقدامات میں سے ایک --dry-run کا استعمال ہے۔ یہ پیرامیٹر واقعی فائلوں کو کاپی نہیں کرتا؛ صرف یہ دکھاتا ہے کہ کون سی فائلیں منتقل کی جائیں گی۔ اس طرح غلط ڈائریکٹری، غلط ہدف کا راستہ یا غیر متوقع حذف کے عمل کو پہلے ہی دیکھا جا سکتا ہے۔

مثال ٹیسٹ کمانڈ: rsync -avz --dry-run /var/www/site/ صارف@ہدف-ip:/var/www/site/۔ آپ آؤٹ پٹ میں منتقل ہونے والی فائلوں، بننے والی ڈائریکٹریوں اور عمل کا خلاصہ دیکھیں گے۔ اگر آپ --delete پیرامیٹر استعمال کرنے جا رہے ہیں تو dry-run مزید اہم ہو جاتا ہے۔ کیونکہ --delete، ماخذ میں نہیں ہونے والی فائلوں کو ہدف میں حذف کر سکتا ہے۔ درست استعمال میں یہ ہدف کو بالکل آئینہ بنا دیتا ہے؛ غلط ڈائریکٹری میں استعمال ہونے پر یہ سنگین ڈیٹا کے نقصان کا باعث بن سکتا ہے۔

پیشہ ورانہ عمل کا ترتیب عام طور پر یہ ہے: پہلے SSH ٹیسٹ کیا جاتا ہے، پھر ڈسک کی جگہ کی جانچ کی جاتی ہے، اس کے بعد rsync --dry-run چلایا جاتا ہے، چھوٹے ڈائریکٹری کے ساتھ حقیقی ٹیسٹ کیا جاتا ہے، اس کے بعد اہم منتقلی شروع کی جاتی ہے۔ یہ نقطہ نظر چند منٹ کا اضافی وقت درکار ہوتا ہے لیکن کئی گھنٹوں تک جاری رہنے والے غلط منتقلی سے بچاتا ہے۔

کارکردگی کے لیے کمپریشن، بینڈوڈتھ اور خفیہ کاری کی ترتیبات

rsync کی کارکردگی صرف فائل کے سائز پر منحصر نہیں ہے۔ سرورز کی CPU طاقت، ڈسک کی قسم، نیٹ ورک کی تاخیر، بینڈوڈتھ اور فائل کی تعداد بھی اہم ہیں۔ بہت سی چھوٹی فائلیں، ایک بڑی فائل سے زیادہ آہستہ منتقل کی جا سکتی ہیں؛ کیونکہ ہر فائل کے لیے میٹا ڈیٹا کے عمل کیے جاتے ہیں۔ NVMe ڈسک والی VPS ماحول میں فائلوں کی اسکیننگ اور لکھنے کی کارکردگی نمایاں طور پر بہتر ہو سکتی ہے۔ اس لیے اگر آپ بڑے پیمانے پر منتقلی کی منصوبہ بندی کر رہے ہیں تو NVMe VPS سرور کے اختیارات پر غور کرنا سمجھدار ہے۔

-z کمپریشن پیرامیٹر ٹیکسٹ فائلوں، لاگ اور کچھ قسم کے بیک اپ میں فائدہ دیتا ہے۔ تاہم، پہلے سے ہی کمپریسڈ zip، tar.gz، jpg، mp4 یا gzip فائلوں میں CPU کا استعمال کر کے زیادہ فائدہ حاصل نہیں کیا جا سکتا۔ اگر آپ 1 Gbps کنکشن کے ساتھ دو طاقتور سرورز کے درمیان بڑی میڈیا فائلیں منتقل کر رہے ہیں تو -z کا استعمال کیے بغیر بہتر کارکردگی حاصل کر سکتے ہیں۔ اس کے برعکس، کم بینڈوڈتھ اور ٹیکسٹ کے وزن والی فائلوں میں -z اہم بچت فراہم کر سکتا ہے۔

بینڈوڈتھ کو محدود کرنے کے لیے --bwlimit استعمال کیا جا سکتا ہے۔ مثال کے طور پر --bwlimit=50000 تقریباً 50 MB/s کی سطح پر حد رکھتا ہے۔ یہ، زندہ ویب سائٹ کے نیٹ ورک کے ٹریفک کو بھاری نہ کرنے کے لیے اہم ہے۔ پروڈکشن سرور پر مصروف اوقات میں مکمل رفتار کی منتقلی کرنے سے وزیٹر کے تجربے پر منفی اثر پڑ سکتا ہے۔ منتقلی کو رات کے اوقات میں منصوبہ بندی کرنا، بینڈوڈتھ کی حد مقرر کرنا اور عمل کے دوران لوڈ اوسط کی قیمتوں کی نگرانی کرنا اچھی مشق ہے۔

rsync، scp، SFTP اور FTP کا موازنہ

فائل کی منتقلی کے لیے متعدد طریقے ہیں؛ تاہم، ہر طریقے کی طاقت اور کمزوری مختلف ہوتی ہے۔ نیچے دی گئی جدول، بڑی فائل اور سرور کی منتقلی کے منظرناموں میں کون سا ٹول کب زیادہ موزوں ہے، کا خلاصہ پیش کرتی ہے۔

جیسا کہ جدول سے ظاہر ہے، rsync خاص طور پر بار بار ہم آہنگی اور بڑی ڈیٹا کی منتقلی میں ممتاز ہے۔ scp سادہ اور آسان ہے لیکن تبدیل ہونے والی فائلوں کو ذہن میں رکھنے میں rsync کے برابر طاقتور نہیں ہے۔ FTP اگر بغیر خفیہ کاری کے استعمال کی جائے تو جدید سیکیورٹی کے معیار کے لیے موزوں نہیں ہے۔ ہوسٹنگ پینلز میں FTP تک رسائی عملی ہو سکتی ہے؛ لیکن سرورز کے درمیان اہم منتقلی میں SSH پر مبنی طریقے کو ترجیح دی جانی چاہیے۔

زندہ ویب سائٹ کی منتقلی کے لیے مثال کا کام کا بہاؤ

ایک ویب سائٹ کو پرانے سرور سے نئے سرور پر منتقل کرتے وقت مقصد صرف فائلوں کو کاپی کرنا نہیں ہے۔ DNS، ڈیٹا بیس، SSL، PHP کا ورژن، فائل کی اجازتیں اور ای میل کی تشکیل بھی چیک کی جانی چاہیے۔ نیچے ایک بڑی فائل والی ویب سائٹ کے لیے کم سے کم بندش کے ساتھ مثال کا کام کا بہاؤ موجود ہے۔

• نئے سرور پر ویب سرور، PHP، ڈیٹا بیس اور ضروری ماڈیولز کی تیاری کریں۔
• ڈومین کے DNS TTL کی قیمت کو منتقلی سے پہلے 300 سیکنڈ جیسے کم قیمت پر لائیں۔ ڈومین کے انتظام کے لیے ڈومین تلاش اور ڈومین انتظام صفحے کا جائزہ لے سکتے ہیں۔
• پہلی rsync کی منتقلی کو سائٹ کے زندہ ہونے کے دوران شروع کریں۔ یہ مرحلہ بڑے ڈیٹا کا زیادہ تر حصہ منتقل کرتا ہے۔
• ڈیٹا بیس کا بیک اپ لیں اور نئے سرور میں منتقل کریں۔
• سائٹ کو عارضی طور پر دیکھ بھال کے موڈ میں لے جائیں۔
• دوسری rsync کمانڈ کو چلا کر تبدیل ہونے والی آخری فائلوں کو ہم آہنگ کریں۔
• ڈیٹا بیس کو دوبارہ تازہ کریں یا انکریمنٹل حکمت عملی کا استعمال کریں۔
• نئے سرور پر فائل کی اجازتیں، سائٹ کی ابتدائی حالت اور لاگ کو چیک کریں۔
• SSL سرٹیفکیٹ کو انسٹال کریں یا بحال کریں۔ اس کے لیے SSL سرٹیفکیٹ کی تنصیب مواد مددگار ہو سکتا ہے۔
• DNS ریکارڈز کو نئے IP ایڈریس کی طرف منتقل کریں۔

اس طریقہ میں سب سے طویل وقت لینے والا بنیادی فائل کی منتقلی سائٹ کے چلتے وقت کی جائے گی۔ بندش صرف آخری ہم آہنگی اور DNS کی منتقلی کے دوران ہوگی۔ بڑی میڈیا آرکائیو والی ورڈپریس سائٹس میں یہ طریقہ چند گھنٹوں کی بندش کو چند منٹوں تک کم کر سکتا ہے۔

ڈیٹا کی سالمیت کی جانچ

منتقلی مکمل ہونے کے بعد صرف کمانڈ کا مکمل ہونا کافی نہیں ہے۔ فائل کی تعداد، سائز اور اہم فائلوں کی جانچ کی جانی چاہیے۔ سادہ جانچ کے لیے ماخذ اور ہدف پر du -sh کمانڈ کے ذریعے ڈائریکٹری کے سائز کا موازنہ کیا جا سکتا ہے۔ تاہم فائل سسٹم کے بلاک کے فرق کی وجہ سے اقدار بالکل ایک جیسی نظر نہیں آ سکتی ہیں۔ مزید تفصیلی جانچ کے لیے rsync کو دوبارہ اسی پیرامیٹرز کے ساتھ چلایا جا سکتا ہے۔ اگر منتقل کرنے کے لیے نئی فائلیں نہیں ہیں تو آؤٹ پٹ کم از کم سطح پر ہوگا۔

Checksum کی تصدیق کے لیے rsync -avc --dry-run /ماخذ/ڈائریکٹری/ صارف@ہدف-ip:/ہدف/ڈائریکٹری/ استعمال کیا جا سکتا ہے۔ یہاں -c پیرامیٹر فائلوں کا وقت کے نشان اور سائز کے علاوہ checksum کے ساتھ موازنہ کرتا ہے۔ بہت بڑی فائلوں میں CPU اور ڈسک کا بوجھ پیدا کر سکتا ہے اس لیے محتاط استعمال کی ضرورت ہے۔ اہم آرکائیو، ڈیٹا بیس کے ڈمپ فائلیں یا صارف کی دستاویزات کے لیے یہ اضافی تصدیق یقین دہانی فراہم کرتی ہے۔

اگر آپ نے ویب سائٹ منتقل کی ہے تو ایپلیکیشن کی سطح پر بھی جانچ کریں۔ ہوم پیج، ایڈمن پینل، بصری اپ لوڈنگ، ادائیگی کے صفحے، رابطہ فارم اور غلطی کے لاگ کو جانچنا چاہیے۔ ای کامرس کی سائٹس میں صرف فائلوں کا منتقل ہونا کافی نہیں ہے؛ ادائیگی کے انضمام اور کرون کے کاموں کو بھی نئے سرور پر جانچنا چاہیے۔

عام غلطیاں اور ان کے حل

Permission denied کی غلطی

یہ غلطی عام طور پر SSH صارف کی اجازت، ہدف ڈائریکٹری میں لکھنے کی اجازت یا کلید کی تصدیق کی وجہ سے ہوتی ہے۔ پہلے اسی صارف کے ساتھ معمول کے SSH کنکشن کو قائم کرنے کی کوشش کریں۔ اگر کنکشن کامیاب ہو تو ہدف ڈائریکٹری میں فائل بنانے کا ٹیسٹ کریں۔ ضرورت پڑنے پر ہدف کے فولڈر کی ملکیت کو chown کے ذریعے متعلقہ صارف کو دیں یا sudo پر مبنی حکمت عملی کا منصوبہ بنائیں۔

No space left on device کی غلطی

جب ہدف ڈسک پر کافی جگہ باقی نہیں رہتی تو منتقلی رک جاتی ہے۔ df -h کے ساتھ ڈسک کے حصوں کی جانچ کریں۔ کبھی کبھار بنیادی ڈسک بھری نہیں ہوتی لیکن /tmp یا ہدف کی ماؤنٹ پوائنٹ بھری ہوتی ہے۔ بڑی منتقلی میں لاگ کی فائلیں، پرانی بیک اپ اور کیش فولڈرز کو صاف کیا جا سکتا ہے۔ مستقل حل کے لیے ڈسک کی توسیع یا زیادہ صلاحیت والی VPS منصوبے کی منتقلی کی ضرورت ہو سکتی ہے۔

Connection reset یا Broken pipe کی غلطی

طویل مدتی منتقلی میں نیٹ ورک کی خرابی ہو سکتی ہے۔ --partial اور --append-verify استعمال کرتے ہوئے، آپ کمانڈ کو دوبارہ چلا کر جہاں سے چھوڑا تھا وہاں سے جاری رکھ سکتے ہیں۔ اس کے علاوہ SSH keepalive کی ترتیبات بھی مددگار ثابت ہو سکتی ہیں۔ کلائنٹ کی طرف ServerAliveInterval 60 جیسی ترتیب کنکشن کے بے کار ٹوٹنے کو کم کر سکتی ہے۔

بہت سست منتقلی

سست رفتار فائل کی تعداد، ڈسک I/O کی حد، کمپریشن کے بوجھ یا نیٹ ورک کی گنجائش کی وجہ سے ہو سکتی ہے۔ اگر بہت سی چھوٹی فائلیں ہیں تو پہلے tar آرکائیو بنانا بعض اوقات زیادہ تیز ہو سکتا ہے؛ تاہم اس صورت میں rsync کی فائل کی بنیاد پر تبدیلی کا فائدہ کم ہو جاتا ہے۔ بڑی اور پہلے سے ہی کمپریسڈ فائلوں میں -z پیرامیٹر کو ہٹانے سے ٹیسٹ کریں۔ اس کے علاوہ iotop، htop اور iftop جیسے ٹولز کے ساتھ یہ معلوم کریں کہ رکاوٹ CPU، ڈسک یا نیٹ ورک کی طرف ہے۔

سیکیورٹی کے لیے بہترین طریقے

سرورز کے درمیان فائل کی منتقلی کے دوران سیکیورٹی کو نظر انداز نہیں کیا جانا چاہیے۔ خاص طور پر روٹ کی رسائی، SSH کی چابیاں اور بیک اپ فائلیں حساس سمجھی جانی چاہئیں۔ سب سے پہلے، پاس ورڈ کی لاگ ان کے بجائے SSH کی چابی کا استعمال کرنا تجویز کیا جاتا ہے۔ چابی کی فائلوں کی اجازتیں سخت رکھی جانی چاہیے، نجی چابیاں مشترک نہیں کرنی چاہئیں اور ممکن ہو تو passphrase کے ذریعے محفوظ رکھنی چاہئیں۔

منتقلی کے لیے عارضی صارف بنایا جائے اور صرف ضروری ڈائریکٹریز تک رسائی دی جائے، ایک اچھا طریقہ ہے۔ عمل مکمل ہونے کے بعد اس صارف کی اجازتیں ہٹا دی جا سکتی ہیں یا اکاؤنٹ کو غیر فعال کیا جا سکتا ہے۔ SSH کی رسائی کو مخصوص IP ایڈریسز تک محدود کرنا بھی حملے کی سطح کو کم کرتا ہے۔ فائر وال کے قوانین، Fail2ban اور جدید OpenSSH ورژن بنیادی چیک میں شامل ہونے چاہئیں۔

اگر آپ ڈیٹا بیس کے ڈمپ فائلیں، صارف کی دستاویزات یا ذاتی ڈیٹا پر مشتمل آرکائیو منتقل کر رہے ہیں تو منتقلی کے بعد ماخذ اور ہدف پر غیر ضروری عارضی فائلوں کو صاف کرنا چاہیے۔ اس کے علاوہ، ویب کی جڑ ڈائریکٹری کے نیچے .sql، .zip یا .tar جیسے بیک اپ فائلیں چھوڑنا سنگین سیکیورٹی خطرہ پیدا کرتا ہے۔ ان فائلوں کو ممکنہ طور پر ویب رسائی سے بند جگہ پر محفوظ کیا جانا چاہیے یا عمل کے ختم ہونے کے بعد حذف کر دینا چاہیے۔

خودکار بیک اپ کے لیے rsync کا استعمال

rsync صرف ایک بار کی منتقلی کے لیے نہیں بلکہ باقاعدہ بیک اپ کے لیے بھی استعمال کیا جا سکتا ہے۔ مثال کے طور پر، ہر رات مخصوص ڈائریکٹری کو بیک اپ سرور پر بھیجنے کے لیے cron کام کی تعریف کی جا سکتی ہے۔ اس منظر نامے میں SSH کی چابی کے ساتھ پاس ورڈ کے بغیر لیکن محفوظ کنکشن قائم کیا جاتا ہے، rsync صرف تبدیل ہونے والی فائلوں کو منتقل کرتا ہے اور بینڈوڈتھ کی حد لگائی جا سکتی ہے۔

مثال کی منطق: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@بیک اپ-ip:/backup/site/۔ یہ کمانڈ ہدف کی ڈائریکٹری کو ماخذ کے ساتھ ہم آہنگ کر سکتی ہے۔ تاہم --delete پیرامیٹر کی وجہ سے احتیاط سے استعمال کیا جانا چاہیے۔ غلطی سے ماخذ میں حذف ہونے والی فائل ہدف پر بھی حذف ہو جائے گی۔ اس لیے اہم بیک اپ کی حکمت عملی میں snapshot، روزانہ کے فولڈرز یا versioning کی بنیاد پر حل اختیار کیے جانے چاہئیں۔

ہوسٹنگ کی کارروائیوں میں 3-2-1 بیک اپ کا اصول ایک اچھا حوالہ ہے: ڈیٹا کی کم از کم 3 کاپیوں، 2 مختلف ماحول میں، 1 کاپی مختلف مقامات پر رکھی جانی چاہیے۔ rsync، اس حکمت عملی کے سرورز کے درمیان کاپی والے حصے کو عملی بناتا ہے۔ زیادہ جامع بنیادی ڈھانچے کے لیے بیک اپ کے حل اور کاروباری ہوسٹنگ کی خدمات مواد کے ساتھ اپنے منصوبے کو مضبوط کر سکتے ہیں۔

آخری چیک لسٹ

بڑی فائل کی منتقلی کے عمل کو شروع کرنے سے پہلے ذیل کی مختصر فہرست کو نافذ کرنا غلطی کے خطرے کو کم کرتا ہے۔ یہ فہرست خاص طور پر پروڈکشن ماحول میں معیاری پروسیجر بنانی چاہیے۔

• کیا ماخذ اور ہدف سرور پر rsync نصب ہے؟
• کیا SSH کنکشن کو صحیح صارف اور پورٹ کے ساتھ جانچا گیا ہے؟
• کیا ہدف سرور پر کافی ڈسک کی جگہ ہے؟
• کیا ابتدائی عمل --dry-run کے ساتھ چیک کیا گیا ہے؟
• کیا زندہ سائٹ کے لیے دیکھ بھال کا موڈ اور آخری ہم آہنگی کی منصوبہ بندی کی گئی ہے؟
• کیا --delete کا استعمال کرتے وقت ہدف کا راستہ یقینی طور پر تصدیق کیا گیا ہے؟
• کیا منتقلی کے بعد فائل کے سائز، اجازتوں اور ایپلیکیشن کی جانچ کی جائے گی؟
• کیا عارضی بیک اپ اور ڈمپ فائلوں کو محفوظ طریقے سے صاف کیا جائے گا؟

یہ چیک آسان لگتے ہیں لیکن حقیقی زندگی میں سب سے زیادہ عام مسائل عام طور پر غلط ہدف ڈائریکٹری، غیر حاضر اجازت، ناکافی ڈسک کی جگہ اور بے ترتیب DNS کی منتقلی کی وجہ سے ہوتے ہیں۔ منصوبہ بند rsync کا عمل، نہ صرف منتقلی کے وقت کو کم کرتا ہے بلکہ واپس لوٹنے کے امکان کو بھی بڑھاتا ہے۔

اکثر پوچھے جانے والے سوالات

اگر SSH کے ذریعے rsync کمانڈ کے ساتھ کنکشن ٹوٹ جائے تو کیا منتقلی دوبارہ شروع ہونی چاہیے؟

نہیں، اگر درست پیرامیٹرز استعمال کیے جائیں تو دوبارہ شروع نہیں ہوتی۔ --partial اور --append-verify کے اختیارات جزوی طور پر منتقل ہونے والی بڑی فائلوں کو محفوظ رکھنے اور کمانڈ دوبارہ چلائے جانے پر منتقلی کو جہاں چھوڑا تھا وہاں سے جاری رکھنے میں مدد کرتے ہیں۔ پھر بھی اہم منتقلی میں کمانڈ دوبارہ چلانے سے پہلے ہدف کی ڈسک کی جگہ اور جزوی فائل کی حالت کی جانچ کرنا بہتر ہے۔

کیا rsync کے ذریعے براہ راست ڈیٹا بیس منتقل کیا جا سکتا ہے؟

rsync فائلوں کی منتقلی کرتا ہے؛ براہ راست چلنے والی ڈیٹا بیس کی فائلوں کو کاپی کرنا صحت مند نہیں ہے۔ MySQL یا MariaDB کے لیے mysqldump یا جسمانی بیک اپ کے ٹولز استعمال کیے جانے چاہئیں، پیدا ہونے والی بیک اپ فائل کو rsync کے ذریعے ہدف سرور پر منتقل کیا جانا چاہیے۔ زندہ نظاموں میں ڈیٹا کی مستقل مزاجی کے لیے دیکھ بھال کے موڈ یا ریپلیکیشن کی حکمت عملی کا منصوبہ بنایا جانا چاہیے۔

کیا rsync استعمال کرنے کے لیے دونوں سرورز پر روٹ کی رسائی درکار ہے؟

روٹ کی رسائی ضروری نہیں ہے۔ ہدف ڈائریکٹری میں لکھنے کے اختیارات رکھنے والا ایک صارف کافی ہے۔ تاہم اگر فائل کی ملکیت، سسٹم کی ڈائریکٹریز، ACL یا خصوصی اجازتوں کی حفاظت کی ضرورت ہو تو زیادہ اعلیٰ اختیارات کی ضرورت ہو سکتی ہے۔ سیکیورٹی کے لحاظ سے، ممکنہ حد تک محدود اختیارات والے صارف کے ساتھ کارروائی کرنا زیادہ درست ہے۔

کیا --delete پیرامیٹر محفوظ ہے؟

--delete درست طور پر استعمال کیے جانے پر ہدف کی ڈائریکٹری کو ماخذ کے ساتھ ہم آہنگ کرنے کے لیے بہت فائدہ مند ہے؛ لیکن غلط ہدف کی ڈائریکٹری میں استعمال ہونے سے فائل کے نقصان کا باعث بن سکتا ہے۔ اس لیے --delete پر مشتمل کمانڈز کو پہلے --dry-run کے ساتھ جانچنا چاہیے، ماخذ اور ہدف کے راستوں کی توجہ سے تصدیق کرنی چاہیے۔

بڑی فائل کی منتقلی میں rsync بہتر ہے یا scp؟

ایک بار کی چھوٹی کاپی میں scp کافی ہو سکتا ہے؛ تاہم بڑی فائلوں، بہت سی فائلوں اور بار بار ہم آہنگی میں rsync عموماً بہتر ہے۔ کیونکہ یہ تبدیل ہونے والے ڈیٹا کو ذہن میں رکھ سکتا ہے، جزوی منتقلی کو جاری رکھ سکتا ہے، بینڈوڈتھ کو محدود کر سکتا ہے اور ٹیسٹ موڈ پیش کرتا ہے۔

خلاصہ اور اگلا قدم

SSH کے ذریعے rsync کمانڈ کے ساتھ دو سرورز کے درمیان بڑی فائلیں منتقل کرنا؛ ایک تیز، محفوظ اور قابل انتظام طریقہ ہے۔ درست پیرامیٹرز کے ساتھ، یہ کنکشن کی خرابیوں کے خلاف مزاحمت کرتا ہے، صرف تبدیل ہونے والی فائلوں کو منتقل کر کے وقت بچاتا ہے اور زندہ سائٹ کی منتقلی کے عمل میں بندش کو کم کرتا ہے۔ بہترین نتائج کے لیے پہلے SSH اور ڈسک کی جانچ کریں، --dry-run کے ساتھ ٹیسٹ کریں، اور پھر اہم منتقلی کو منصوبہ بند طریقے سے چلائیں۔

اگر آپ ایک نئے سرور کی منتقلی، بڑی گنجائش والی اسٹوریج یا مزید کارکردگی کی ہوسٹنگ بنیادی ڈھانچے کا منصوبہ بنا رہے ہیں تو آپ Hostragons کے حل کا جائزہ لے سکتے ہیں؛ اپنی ضروریات کے مطابق VPS، ہوسٹنگ، ڈومین اور SSL کے اختیارات کے ساتھ اپنی منتقلی کے عمل کو زیادہ محفوظ بنا سکتے ہیں۔ بلا رکاوٹ منتقلی کے لیے چھوٹے ٹیسٹ کے ساتھ شروع کریں، پیمائش کریں اور آخری ہم آہنگی کو منصوبہ بند طریقے سے کریں۔