SSH ذريعي rsync حڪم، ٻن لينڪس سرورن جي وچ ۾ وڏا، بيڪ اپ آرڪائيو، ميڊيا فولڊر يا ايپليڪيشن ڊيٽا کي تيز، محفوظ ۽ رڪاوٽ کان بچائيندڙ طريقي سان منتقل ڪرڻ لاءِ بهترين اوزار آهي. خاص طور تي جڏهن ويب سائيٽ جي فائلز سوين GB تائين پهچي وڃن، ته عام ڪاپي ڪرڻ جي طريقن جي ڀيٽ ۾ rsync صرف تبديلي آيل بلاڪ منتقل ڪري ٿو، جنهن سان وقت ۽ رفتار جو وڏو فائدو ملي ٿو. بنيادي اصول آهي: سورس سرور جي فائلز، SSH ٽنل ذريعي ٽارگيٽ سرور تي انڪريپٽڊ سنڪرو ٿيو، ۽ جيڪڏهن ڪنيڪشن ٽٽيو ته ڪم وري ساڳي جڳه کان جاري رهي سگهي ٿو.
سرور شفٽنگ، هوسٽنگ اپگريڊ، ڊيٽا سينٽر تبديلي يا باقاعدي بيڪ اپ لاءِ رفتار سان گڏ ڊيٽا جي پوري هجڻ به اهم آهي. وڏو آرڪائيو ايڪ ٽڪرو طور ڊائونلوڊ ڪري وري اپلوڊ ڪرڻ وقت وڃايو ۽ ڪنيڪشن ۾ مسئلا اچي وڃن. rsync فائل ٽائيم اسٽيمپ، اجازت، مالڪاڻا ۽ فولڊر جو ڍانچو محفوظ ڪري سگهي ٿو. ان ڪري لينڪس سسٽم ايڊمن، DevOps ٽيمون ۽ ويب هوسٽنگ ماهر روزانه rsync کي پسند ڪن ٿا.
هن سنڌي رهنمائي ۾، ٻن لينڪس سرورن جي وچ ۾ SSH ذريعي rsync سان وڏا فائلز منتقل ڪرڻ جو عمل قدم بہ قدم حقيقي حڪمن سان بيان ڪنداسين. ڪارڪردگي لاءِ اضافي پيرا ميٽرز، سيڪيورٽي چيڪ، غلطي جي حالتن، ٽيسٽ ٽرانسفر ۽ پروڊڪشن کان اڳ اهم نقطا به ڏسنداسين. جيڪڏهن توهان نئون VPS يا هوسٽنگ وٺڻ جو ارادو رکو ٿا، ته هن رهنمائي تي عمل کان اڳ سورس ۽ ٽارگيٽ سرور تي ڪافي ڊسڪ اسپيس، SSH رسائي ۽ صحيح يوزر اجازت هجڻ جو پڪ ڪريو. انفراسٽرڪچر چونڊ لاءِ Hostragons VPS سرور حل ۽ لينڪس ميزباني پيڪيجز جو جائزو وٺي سگهو ٿا.
rsync ڇا آهي ۽ وڏين فائلن جي منتقلي لاءِ ڇو بهترين آهي؟
rsync، فائلز ۽ فولڊرز کي لوڪل سسٽم يا دور سرور تي سنکرونائز ڪرڻ لاءِ طاقتور ڪمانڊ لائن اوزار آهي. سڀ کان اهم خاصيت آهي delta transfer الگورٿم، جيڪو هر ڀيري مڪمل فائل کي منتقل ڪرڻ بجاءِ صرف تبديلي آيل حصا ٽارگيٽ طرف موڪليندو آهي. مثال طور، 80GB جي بيڪ اپ ۾ صرف 2GB تبديلي آهي ته rsync صرف ان بلاڪ کي منتقل ڪندو، نه ته سڄي فائل.
SSH، ٽرانسفر کي انڪريپٽ ڪري ٿو. ان جو مطلب آهي rsync ذريعي ڊيٽا نيٽورڪ تي صاف متن ۾ نه ويندي – خاص طور تي ڪسٽمر ڊيٽا، اي ڪامرس آرڊر، ميڊيا آرڪائيو، ڊيٽابيس بيڪ اپ ۽ خاص ايپ فائلز لاءِ سيڪيورٽي ضروري آهي. هوسٽنگ دنيا ۾ صرف SSL سان سيڪيورٽي نه هوندي؛ سرور جي وچ ۾ ٽرانسفر جو چينل محفوظ هئڻ گهرجي. ويب سائيٽ ٽريفڪ لاءِ SSL سرٽيفڪيٽ جتي استعمال ٿيندو، سرور جي وچ ۾ فائل ٽرانسفر لاءِ SSH جو انڪريپشن ضروري آهي.
rsync، FTP يا هٿ سان ڊائونلوڊ اپلوڊ جي ڀيٽ ۾ وڌيڪ لچڪدار آهي. اجازت محفوظ ڪري سگهي ٿو، symbolic لنڪ منتقل ڪري سگهي ٿو، حذف ٿيل فائلز ٽارگيٽ تي به ختم ڪري سگهي ٿو، bandwidth محدود ڪري سگهي ٿو ۽ ٽرانسفر کان اڳ ٽيسٽ به ڪري سگهي ٿو. وڏين فائلن جي منتقلي جهڙن خطري واري عمل ۾ اهڙي ڪنٽرول سان وڏو فائدو ٿيندو آهي.
SSH ذريعي rsync حڪم ڪڏهن استعمال ڪجي؟
SSH ذريعي rsync حڪم خاص طور تي وڏين، گهڻين يا بار بار تبديل ٿيندڙ فائلن جي منتقلي لاءِ بهترين آهي. سادي تصويري فولڊر لاءِ SFTP ڪافي آهي، پر هزارين فائلون، مختلف اجازت، وڏو آرڪائيو هجي ته rsync وڌيڪ اعتماد جوڳي آهي.
- جيڪڏهن پراڻن سرور کان نئين VPS تي ويب سائيٽ منتقل ڪرڻي آهي.
- WordPress جي uploads فولڊر جهڙا ميڊيا فولڊر، جنهن ۾ هزارين فائلون آهن.
- روزانه، هفتيوار يا ماهانه بيڪ اپ مختلف سرور تي ڪاپي ڪرڻ.
- ڊيٽا سينٽر يا هوسٽنگ فراهم ڪندڙ تبديل ڪرڻ.
- ايپليڪيشن فائلز کي پروڊڪشن ۽ بيڪ اپ سرور تي سنکرونائز ڪرڻ.
- گهڻي وقت تائين هلندڙ ٽرانسفر، جتي ڪنيڪشن ٽٽڻ جو امڪان آهي.
مثال طور، 250GB ميڊيا فولڊر کي ڊيسڪ ٽاپ تي ڊائونلوڊ ڪرڻ ۽ پوءِ نئين سرور تي اپلوڊ ڪرڻ ٻن الڳ ٽرانسفر جو مطلب آهي. هي نه صرف وقت وڌائيندو، بلڪه گهر يا آفيس انٽرنيٽ کي بلاڪ ڪري ڇڏيندو. rsync سان سڌي سورس سرور کان ٽارگيٽ سرور تي منتقل ڪري، وچ واري قدم کان بچي سگهو ٿا.
شروع ڪرڻ کان اڳ ضروري چيڪ
rsync سان ڪامياب منتقلي لاءِ صرف حڪم ڄاڻڻ ڪافي ناهي؛ سورس ۽ ٽارگيٽ سرور جي حالتن جو جائزو وٺو ته جيئن ڊيٽا نقصان يا اڌ منتقلي جو خطرو گهٽجي. هيٺيان چيڪ پروڊڪشن ماحول ۾ ضروري آهن:
1. SSH رسائي جي تصديق
سورس سرور کان ٽارگيٽ سرور تي SSH ڪنيڪشن هجڻ لازمي آهي. عام ڪنيڪشن: ssh user@target-server-ip. جيڪڏهن SSH الڳ پورٽ تي هجي ته: ssh -p 2222 user@target-server-ip. جيڪڏهن هي ناڪام ٿئي ته rsync به نه هلي سگهندو. Firewall، Fail2ban، SSH پورٽ، يوزر اجازت ۽ پاسورڊ يا key جي تصديق لازمي چيڪ ڪريو.
2. rsync پيڪيج انسٽال ٿيل هجڻ
گهڻين لينڪس ڊسٽرو ۾ rsync اڳ ئي موجود هوندو؛ پوءِ به چيڪ ڪرڻ لازمي آهي. Debian/Ubuntu تي rsync --version سان تصديق ڪريو. جيڪڏهن انسٽال نه آهي ته apt install rsync سان انسٽال ڪيو. CentOS, AlmaLinux يا Rocky Linux تي dnf install rsync يا yum install rsync. Hostragons تي لينڪس VPS تي عام طور تي چند سيڪنڊن ۾ انسٽال ٿي ويندو.
3. ڊسڪ اسپيس جو حساب
ٽارگيٽ سرور تي ڪافي خالي جڳهه نه هجي ته منتقلي اڌ ۾ رهجي سگهي ٿي. سورس فولڊر جي سائيز ڏسڻ لاءِ du -sh /source/folder. ٽارگيٽ تي df -h سان ڊسڪ اسٽيٽس ڏسو. عملي طور فائل سائيز کان وڌيڪ جڳهه، temporary فائلز ۽ log لاءِ به رکجو. جيڪڏھن 500GB ڊيٽا منتقل ڪرڻو آهي ته ٽارگيٽ تي گهٽ ۾ گهٽ 550-600GB جڳهه رکجو.
4. اهم سروسز ۽ تبديل ٿيندڙ فائلز جي منصوبي
جيڪڏهن ويب سائيٽ live آهي ته فائلز منتقلي دوران بدلجن ٿيون - خاص طور تي user uploads, cache فولڊرز ۽ log فائلون. وڏين منتقلي ۾ پهرين اهم ڊيٽا منتقل ڪريو، پوءِ سائيٽ کي maintenance موڊ ۾ آڻي ٻيو rsync هلايو. ان سان downtime گھٽجي ويندو. WordPress سائيٽ لاءِ ورڊپريس هوسٽنگ منتقلي گائيڊ سان منصوبي مڪمل ڪريو.
بنيادي rsync حڪم: ٻن سرورن جي وچ ۾ فائل منتقل ڪرڻ
عام بنيادي حڪم: rsync -avz /source/folder/ user@target-ip:/target/folder/. هتي -a آرڪائيو موڊ آهي (اجازت، ٽائيم اسٽيمپ، symbolic لنڪ محفوظ)، -v تفصيلي نتيجو ڏيکاريندو، -z ٽرانسفر دوران compression ڪندو. فولڊر جي آخر ۾ / ضروري آهي: /source/folder/ سان اندروني مواد منتقل ٿيندو؛ /source/folder سان فولڊر پاڻ ٽارگيٽ تي ٺاهبو.
مثال: پراڻي سرور تي /var/www/site/public_html/ ۾ 180GB ويب فائلز نئين سرور تي /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 لاءِ تجويز ڪيل پيرا ميٽرز
وڏي فائلن جي منتقلي لاءِ صرف بنيادي حڪم ڪافي نه آهي. ڪنيڪشن ٽٽڻ، partial فائل، غلط حذف يا slow نيٽورڪ لاءِ اضافي پيرا ميٽرز ضروري آهن. هيٺيان حڪم گهڻين منتقلي حالتن لاءِ مضبوط شروعات آهي:
rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /source/folder/ user@target-ip:/target/folder/
-a آرڪائيو، -H hard links، -A ACL اجازت، -X extended attributes محفوظ ڪري ٿو. --numeric-ids يوزر/گروپ ID سان ڪم ڪري ٿو، جڏهن مختلف سرورن تي يوزر نالا مختلف هجن. --partial اڌ فائل نه ٿو هٽائي، --progress ٽرانسفر اسٽيٽس ڏيکاري، --append-verify وڏي فائلن ۾ اضافي حصو verify ڪري ٿو.
هر پيرا ميٽر هر سسٽم لاءِ لازمي ناهي. مثال طور عام ويب سائيٽ لاءِ -aHAX ڪافي آهي، خاص اجازت وارا ايپليڪيشن لاءِ ACL ۽ extended attributes محفوظ ڪرڻ ضروري آهي. ان ڪري پهرين test transfer ڪريو.
جيڪڏهن SSH پورٽ مختلف آهي، حڪم ڪيئن هجي؟
سيڪيورٽي لاءِ SSH پورٽ 22 بجاءِ ٻئي پورٽ تي هجي ته rsync ۾ SSH پيرا ميٽر ڏيڻو پوندو. مثال: rsync -avz -e ssh -p 2222 /source/folder/ user@target-ip:/target/folder/. صحيح حڪم: rsync -avz -e 'ssh -p 2222' /source/folder/ user@target-ip:/target/folder/.
ڪڏهن JSON يا ڪن پينل ۾ quotation marks مختلف هوندا، تنهنڪري ٽرمينل تي سڌو لکو ته tikan درست هجي. SSH key سان ڪنيڪشن لاءِ -i به لڳائي سگهو ٿا: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/folder/ user@target-ip:/target/folder/. هي طريقو automation ۽ cron بيڪ اپ لاءِ عام آهي.
منتقلي کان اڳ ٽيسٽ: --dry-run جو استعمال
وڏي ڊيٽا منتقل ڪرڻ کان اڳ --dry-run جو استعمال سڀ کان پروفيشنل قدم آهي. هي پيرا ميٽر اصل ۾ فائلز منتقل نه ڪندو، صرف ڏيکاريندو ته ڪهڙيون فائلون منتقل ٿينديون. ان سان غلط فولڊر، غلط ٽارگيٽ يا غير متوقع حذف کان بچي سگهو ٿا.
مثال حڪم: rsync -avz --dry-run /var/www/site/ user@target-ip:/var/www/site/. نتيجو ۾ منتقل ٿيندڙ فائلز، فولڊرز ۽ summary ڏسندا. جيڪڏهن --delete پيرا ميٽر استعمال ڪرڻو آهي ته dry-run وڌيڪ ضروري آهي، ڇو ته --delete سورس ۾ نه هونديون فائلز ٽارگيٽ تي ختم ڪري سگهي ٿو. غلط فولڊر ۾ استعمال سان ڊيٽا نقصان ٿيندو.
پروفيشنل عمل عام طور تي: SSH ٽيسٽ، ڊسڪ اسپيس چيڪ، پوءِ rsync --dry-run، ننڍڙي فولڊر سان test، پوءِ اصل منتقلي. هي طريقو چند منٽ وڌيڪ وقت وٺندو، پر غلط ٽرانسفر جا ڪلاڪ بچائي سگهندو.
ڪارڪردگي لاءِ compression، bandwidth ۽ انڪريپشن سيٽنگون
rsync جي ڪارڪردگي صرف فائل سائيز تي نه، سرورن جي CPU، ڊسڪ، نيٽورڪ latency، bandwidth ۽ فائلن جي تعداد تي به دارومدار رکي ٿي. گهڻين ننڍين فائلن جي منتقلي وڏي فائل کان سست ٿي سگهي ٿي، ڇو ته هر فائل لاءِ metadata process ٿئي ٿو. NVMe ڊسڪ تي VPS ۾ فائل scan ۽ write تيز هوندو. ان ڪري گهڻين منتقلي لاءِ NVMe VPS سرور تي غور ڪريو.
-z compression پيرا ميٽر text، log يا ڪجه بيڪ اپ لاءِ فائديمند آهي، پر اڳ ئي compressed (zip, tar.gz, jpg, mp4) فائل لاءِ اضافي CPU تي خرچ ڪري، فائدو نه ڏيندو. 1Gbps سرورن جي وچ ۾ وڏيون ميڊيا فائلون منتقل ڪرڻ لاءِ -z کانسواءِ بهتر نتيجا ملندا. گهٽ bandwidth يا text-heavy ڊيٽا لاءِ -z سان وڏو بچاءُ ٿيندو.
bandwidth کي محدود ڪرڻ لاءِ --bwlimit استعمال ڪريو. مثال: --bwlimit=50000 تقريباً 50MB/s جي حد لڳائي ٿو. هي live ويب سائيٽ جي نيٽورڪ کي congest نه ٿيڻ لاءِ اهم آهي. منتقلي رات جو ڪرڻ، bandwidth حد لڳائڻ ۽ load average کي ڏسڻ بهتر آهي.
rsync، scp، SFTP ۽ FTP جو تقابلي جائزو

فائل منتقلي لاءِ ڪيترائي طريقا آهن؛ هر طريقي جا فائدا ۽ نقصان مختلف آهن. هيٺين جدول ۾ وڏين فائلن ۽ سرور شفٽنگ لاءِ ڪهڙو طريقو مناسب آهي، وضاحت آهي:
| طريقو | سيڪيورٽي | اڌ ۾ رهڻ کان پوءِ جاري | وڏي فائل ڪارڪردگي | بهترين استعمال |
|---|---|---|---|---|
| rsync + SSH | تمام بهتر | مضبوط | تمام بهتر | سرور شفٽنگ، بيڪ اپ، سنکرونائيزيشن |
| scp | بهتر | محدود | درميان | گهڻين فائلن جي تيز ڪاپي |
| SFTP | بهتر | ڪلينٽ تي دارومدار | درميان | هٿ سان فائل انتظام |
| FTP | ڪمزور | ڪلينٽ تي دارومدار | غير يقيني | سيڪيورٽي ضروري نه هجي ته پراڻا سسٽم |
جدول مان واضح آهي ته rsync، خاص طور تي بار بار سنکرونائيزيشن ۽ وڏي ڊيٽا لاءِ بهترين آهي. scp سادو ۽ آسان آهي، پر تبديل ٿيندڙ فائلن کي smart انداز ۾ نه ٿو سمجهي. FTP بغير انڪريپشن جديد سيڪيورٽي لاءِ مناسب ناهي. هوسٽنگ پينل ۾ FTP عملي آهي، پر سرور شفٽنگ ۾ SSH طريقا بهترين.
Live ويب سائيٽ منتقلي لاءِ مثال workflow
ويب سائيٽ کي پراڻي سرور کان نئين سرور تي منتقل ڪرڻ لاءِ صرف فائلز ڪاپي ڪرڻ ڪافي نه؛ DNS، ڊيٽابيس، SSL، PHP ورجن، اجازت، ايميل به چيڪ ڪرڻ لازمي. هيٺيان workflow وڏي ڊيٽا واري ويب سائيٽ لاءِ گهٽ downtime سان آهي:
- نئين سرور تي web server، PHP، ڊيٽابيس ۽ ضروري ماڊلز تيار ڪريو.
- ڊومين جو DNS TTL منتقلي کان اڳ 300 سيڪنڊ تي آڻيو. ڊومين انتظام لاءِ ڊومين جي جانچ ۽ ڊومين جي انتظام جو جائزو وٺو.
- پهريون rsync منتقلي سائيٽ live هجي تڏهن شروع ڪريو - وڏي ڊيٽا جو اڪثر حصو منتقل ٿيندو.
- ڊيٽابيس جو بيڪ اپ وٺو ۽ نئين سرور تي منتقل ڪريو.
- سائيٽ کي maintenance موڊ ۾ آڻيو.
- ٻيو rsync هلايو ته تبديل ٿيل فائلز synchronize ٿين.
- ڊيٽابيس جو تازي بيڪ اپ وٺو يا incremental strategy استعمال ڪريو.
- نئين سرور تي فائل اجازت، سائيٽ لانچ ۽ log چيڪ ڪريو.
- SSL سرٽيفڪيٽ انسٽال يا تجديد ڪريو. SSL سرٽيفڪيٽ جي انسٽاليشن مددگار آهي.
- DNS رڪارڊ نئين IP تي منتقل ڪريو.
هن طريقي ۾ وڏي فائلن جي منتقلي live سائيٽ تي ٿيندي. downtime صرف آخري سنکرونائيزيشن ۽ DNS switch تي ٿيندو. وڏي ميڊيا واري WordPress سائيٽ لاءِ هي طريقو ڪلاڪن جي downtime کي منٽن تائين گهٽائي سگھي ٿو.
ڊيٽا جي پوري هجڻ جي چيڪ
منتقلي مڪمل ٿيڻ تي صرف حڪم جو ختم ٿيڻ ڪافي نه؛ فائل تعداد، سائيز ۽ اهم فائلز چيڪ ڪريو. سادي چيڪ لاءِ سورس ۽ ٽارگيٽ تي du -sh سان فولڊر سائيز compare ڪريو. فائل سسٽم بلاڪ فرق سبب exact نه هجي، وڌيڪ چيڪ لاءِ rsync وري ساڳي پيرا ميٽرز سان هلايو؛ جيڪڏهن منتقل ڪرڻ لاءِ ڪجه نه بچيو ته نتيجو گهٽ اچي.
Checksum لاءِ rsync -avc --dry-run /source/folder/ user@target-ip:/target/folder/. -c پيرا ميٽر فائلز کي ٽائيم اسٽيمپ، سائيز سان گڏ checksum سان compare ڪري ٿو. وڏي ڊيٽا تي CPU ۽ ڊسڪ لوڊ وڌي سگهي ٿو. اهم آرڪائيو، ڊيٽابيس dump يا ڪسٽمر ڊيٽا لاءِ هي سيڪيورٽي چيڪ ضروري آهي.
ويب سائيٽ منتقل ڪئي ته ايپليڪيشن ليول تي به چيڪ ڪريو: homepage، admin پينل، image upload، payment page، contact form، error logs. اي ڪامرس ۾ صرف فائلز منتقل ڪرڻ ڪافي نه؛ payment integration ۽ cron jobs به نئين سرور تي test ڪريو.
عام غلطيون ۽ انهن جا حل
Permission denied غلطي
عام طور تي SSH يوزر اجازت، ٽارگيٽ فولڊر تي لکڻ جي اجازت يا key جي تصديق ۾ مسئلو. پهرين ساڳي يوزر سان normal SSH ڪنيڪشن آزمائي ڏسو. ڪنيڪشن صحيح ته ٽارگيٽ فولڊر ۾ فائل ٺاهڻ جي ڪوشش ڪريو. ضرورت پوڻ تي chown سان فولڊر جي مالڪيت تبديل ڪريو يا sudo سان ڪم ڪريو.
No space left on device غلطي
ٽارگيٽ ڊسڪ تي جڳهه نه هجڻ تي منتقلي بيهجي ويندي. df -h سان ڊسڪ پارٽيشڻ چيڪ ڪريو. ڪڏهن اصل ڊسڪ خالي پر /tmp يا mount point ڀريل هوندو. وڏي منتقلي ۾ log، پراڻا بيڪ اپ ۽ cache صاف ڪريو. مستقل حل لاءِ ڊسڪ وڌايو يا وڏي VPS وٺو.
Connection reset يا Broken pipe غلطي
گهڻي وقت هلندڙ ٽرانسفر ۾ نيٽورڪ مسئلا ٿي سگهن ٿا. --partial ۽ --append-verify سان حڪم وري هلايو ته ساڳي جڳه کان جاري رهندو. SSH keepalive سيٽنگ helpful آهي؛ ServerAliveInterval 60 سان ڪنيڪشن idle تي نه ٽٽندو.
منتقلي تمام سست
سست رفتاري فائل تعداد، ڊسڪ I/O، compression يا نيٽورڪ حد سبب ٿي سگهي ٿي. گهڻين ننڍين فائلن لاءِ tar آرڪائيو ٺاهڻ ڪڏهن تيز هوندو، پر rsync جي فائل تبديلين جو فائدو گهٽجي ويندو. اڳ ۾ ئي compressed فائلن لاءِ -z هٽائي test ڪريو. iotop, htop, iftop سان bottleneck جو پتو لڳايو.
سيڪيورٽي لاءِ بهترين عمل
سرورن جي وچ ۾ فائل منتقلي دوران سيڪيورٽي وساري نه وڃجي. خاص طور تي root رسائي، SSH keys ۽ بيڪ اپ فائلز حساس آهن. پهرين پاسورڊ بجاءِ SSH key استعمال ڪريو، key فائلز جي اجازت سخت رکجو، private key شيئر نه ڪريو ۽ ممڪن هجي ته passphrase سان محفوظ ڪريو.
منتقلي لاءِ temporary يوزر ٺاهيو، صرف ضروري فولڊر تائين رسائي ڏيو. ڪم ختم ٿيڻ تي يوزر جي اجازت هٽايو يا account بند ڪريو. SSH رسائي خاص IP سان محدود ڪريو. Firewall، Fail2ban، جديد OpenSSH لازمي چيڪ.
ڊيٽابيس dump، ڪسٽمر ڊيٽا يا personal ڊيٽا منتقل ٿيو ته سورس ۽ ٽارگيٽ تي غير ضروري temporary فائلز صاف ڪريو. ويب root فولڊر هيٺ .sql، .zip يا .tar بيڪ اپ رکڻ سيڪيورٽي رسڪ آهي. هي فائلز web access کان ٻاهر رکجو يا ڪم ختم ٿيڻ تي delete ڪريو.
خودڪار بيڪ اپ لاءِ rsync جو استعمال
rsync صرف هڪ دفعو شفٽنگ لاءِ نه، باقاعده بيڪ اپ لاءِ به استعمال ڪري سگهجي ٿو. مثال طور هر رات خاص فولڊر کي بيڪ اپ سرور تي موڪلڻ لاءِ cron job ٺاهي سگهو ٿا. SSH key سان password کانسواءِ محفوظ ڪنيڪشن، rsync صرف تبديل ٿيل فائل منتقل ڪندو، bandwidth حد مقرر ڪري سگهجي ٿو.
مثال حڪم: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. هي سورس ۽ ٽارگيٽ فولڊر کي برابر ڪري سگهي ٿو. --delete پيرا ميٽر سان احتياط لازمي، ڇو ته سورس مان حذف ٿيل فائل ٽارگيٽ تي به ختم ٿيندي. اهم بيڪ اپ لاءِ snapshot، daily فولڊر يا versioning حل بهتر آهي.
هوسٽنگ ۾ 3-2-1 بيڪ اپ قاعدو بهترين آهي: گهٽ ۾ گهٽ 3 ڪاپيون، 2 مختلف جڳهن تي، 1 ڪاپي ٻئي لوڪيشن تي. rsync، سرور جي وچ ۾ ڪاپي ڪرڻ جو عملي طريقو آهي. وڌيڪ انفراسٽرڪچر لاءِ بيڪ اپ جا حل ۽ اداري ميزباني جون خدمتون سان منصوبي مضبوط ڪريو.
وڏي فائل منتقلي کان اڳ چيڪ لسٽ
وڏي فائل شفٽنگ شروع ڪرڻ کان اڳ هي مختصر لسٽ تي عمل ڪريو ته جيئن غلطيون ۽ خطرا گهٽجي. خاص طور تي پروڊڪشن ماحول ۾ هي لسٽ روتين هئڻ گهرجي:
- سورس ۽ ٽارگيٽ سرور تي rsync انسٽال ٿيل آهي؟
- SSH ڪنيڪشن صحيح يوزر ۽ پورٽ سان test ڪيو ويو؟
- ٽارگيٽ سرور تي ڪافي خالي جڳهه آهي؟
- پهريون عمل --dry-run سان test ڪيو ويو؟
- live سائيٽ لاءِ maintenance ۽ آخري سنکرونائيزيشن منصوبي ۾ آهي؟
- --delete استعمال ٿيندو ته ٽارگيٽ فولڊر صحيح verify ڪيو ويو؟
- منتقلي کان پوءِ فائل سائيز، اجازت ۽ ايپليڪيشن test ٿيندي؟
- temporary بيڪ اپ ۽ dump فائلون محفوظ نموني صاف ٿيندي؟
هي چيڪ سادي آهي، پر عام مسئلا غلط فولڊر، اجازت جي کوٽ، ڊسڪ اسپيس گهٽ هجڻ يا DNS جي منصوبي کان پيدا ٿيندا. منظم rsync عمل، منتقلي جو وقت گھٽائي، واپس موٽڻ جو امڪان وڌائيندو.
وڌيڪ پڇيل سوالات
SSH ذريعي rsync سان ڪنيڪشن ٽٽيو ته منتقلي ٻيهر شروع ٿيندي؟
نه، صحيح پيرا ميٽرز سان ٻيهر شروع نه ٿيندي. --partial ۽ --append-verify سان اڌ فائل محفوظ رھندي ۽ حڪم وري هلائڻ تي ساڳي جڳهه کان جاري رهندو. اڃان به اهم منتقلي ۾ ٽارگيٽ ڊسڪ اسپيس ۽ partial فائلز جي حالت چيڪ ڪريو.
rsync سان ڊيٽابيس سڌو منتقل ٿيندو؟
rsync فائلز منتقل ڪري ٿو؛ هلندڙ ڊيٽابيس کي سڌو ڪاپي ڪرڻ مناسب ناهي. MySQL/MariaDB لاءِ mysqldump يا ٻين بيڪ اپ اوزارن سان dump فائل ٺاهيو، پوءِ rsync سان منتقل ڪريو. live سسٽم لاءِ maintenance موڊ يا replication strategy لازمي آهي.
rsync لاءِ ٻن سرورن تي root رسائي لازمي آهي؟
root ضروري ناهي. ٽارگيٽ فولڊر تي لکڻ جي اجازت وارو يوزر ڪافي آهي. پر فائل مالڪيت، سسٽم فولڊر، ACL يا خاص اجازت محفوظ ڪرڻ لاءِ وڌيڪ اجازت گهرجي. سيڪيورٽي لاءِ محدود يوزر سان ڪم بهتر آهي.
--delete پيرا ميٽر محفوظ آهي؟
--delete صحيح استعمال سان ٽارگيٽ فولڊر کي سورس سان برابر رکڻ لاءِ فائديمند آهي، پر غلط فولڊر ۾ استعمال سان فائل نقصان ٿيندو. ان ڪري --delete سان حڪم هميشه --dry-run سان test ڪريو، سورس ۽ ٽارگيٽ فولڊر verify ڪريو.
وڏي فائلن جي منتقلي لاءِ rsync يا scp بهتر آهي؟
هڪ دفعو ننڍڙي ڪاپي لاءِ scp ڪافي آهي؛ وڏي فائلن، گهڻين فائلن يا بار بار سنکرونائيزيشن لاءِ rsync بهتر آهي. rsync تبديل ٿيل ڊيٽا کي سڃاڻي ٿو، اڌ ۾ رهڻ تي جاري رهي ٿو، bandwidth محدود ڪري ٿو ۽ test mode ڏي ٿو.
خلاصو ۽ اڳيون قدم
SSH ذريعي rsync حڪم سان ٻن سرورن جي وچ ۾ وڏيون فائلون منتقل ڪرڻ تيز، محفوظ ۽ انتظام جوڳي طريقو آهي. صحيح پيرا ميٽرز سان ڪنيڪشن ٽٽڻ تي به بي رڪاوٽ، صرف تبديل ٿيل فائل منتقل ڪري وقت بچائي، live سائيٽ شفٽنگ ۾ downtime گھٽائي ٿو. بهتر نتيجي لاءِ پهرين SSH ۽ ڊسڪ چيڪ ڪريو، --dry-run سان test ڪريو، پوءِ اصل منتقلي منصوبي سان شروع ڪريو.
جيڪڏهن نئين سرور تي شفٽنگ، وڏي اسٽوريج يا وڌيڪ ڪارڪردگي واري هوسٽنگ جو ارادو آهي ته Hostragons جا حل ڏسو؛ VPS، هوسٽنگ، domain ۽ SSL ذريعي شفٽنگ کي محفوظ بڻايو. بي مشڪل منتقل ڪرڻ لاءِ ننڍڙي test سان شروع ڪريو، نتيجن کي ماپيو ۽ آخري سنکرونائيزيشن منصوبي سان مڪمل ڪريو.