VPN پر rsync: ٹوٹی ہوئی منتقلی کو دوبارہ استعمال کرنے والی نئی کوشش
گرتی ہوئی سرنگ کنکشن ختم کرتی ہے، ڈیٹا نہیں۔ --partial-dir کے ساتھ ٹکڑا رکھیں، وہی نقل دوبارہ چلائیں اور شائع کرنے سے پہلے فائل کی تصدیق کریں۔
آپ کا اپ لوڈ بارہ گیگابائٹ کی آرکائیو کے چار گیگابائٹ پر رک جاتا ہے، اور ڈاؤن لوڈ مینیجرز سے سیکھی عادت کہتی ہے کہ دوبارہ شروع دبائیں۔ rsync TCP اسٹریم دوبارہ شروع نہیں کرے گا، کیونکہ وہ اسٹریم سرنگ کی آخری دوبارہ ترسیل کے ساتھ چلی گئی۔ یہ جو کر سکتا ہے وہ یہ ہے کہ پہلے موصول ہو چکے بائٹس رکھے اور انہیں اگلی کوشش کی بنیاد بنائے، جو مختلف قواعد کے مجموعے والا دوسرا طریقہ ہے۔ آپ جو جھنڈے چنیں گے وہ طے کرتے ہیں کہ یہ دوبارہ استعمال ہوگا یا نہیں۔
دوبارہ کوشش حالت دوبارہ بناتی ہے، اسٹریم دوبارہ شروع نہیں کرتی
جب SSH سیشن گرتا ہے، دور کے سرے پر صرف وہی رہتا ہے جو ڈسک پر لکھا جا سکا، اور کچھ نہیں۔ دوبارہ جڑنے کے لیے سیشن ٹوکن نہیں اور دوبارہ چلانے کے لیے ترتیب نمبر نہیں۔ اگلی بار نیا کنکشن کھلتا ہے، ماخذ دوبارہ پڑھا جاتا ہے اور وصول کنندہ سے پوچھا جاتا ہے کہ اس کے پاس پہلے سے کیا ہے۔
وہی آخری سوال بتاتا ہے کہ جزوی فائل رکھنا کیوں مناسب ہے۔ وصول کنندہ کی نقل rsync کو موازنے کے لیے کچھ دیتی ہے، اور الگورتھم صرف وہی فرق بھیجتا ہے جو وہ پہچان سکتا ہے۔ یہ اب بھی میٹاڈیٹا کی نئی منتقلی اور ماخذ پر نئی گزر ہے، اس لیے بچایا گیا وقت اس بات کے تناسب میں ہے کہ فائل کا کتنا حصہ میل کھاتا ہے، نہ کہ پچھلا کنکشن کتنی دور گیا تھا۔ اگر وصول کنندہ نے کچھ نہ رکھا ہو، تو اگلی کوشش پوری نقل ہے، پہلے نے کتنے گیگابائٹ سرکائے ہوں۔
طے کریں کہ دوبارہ استعمال ہونے والا ٹکڑا کہاں رہتا ہے
طے شدہ رویہ جزوی فائل کو ہدف راستے پر لکھتا ہے، جس سے آدھی لکھی آرکائیو آخری نام کے تحت نظر آتی ہے۔ --partial-dir اسے آپ کی چنیدہ ڈائریکٹری میں منتقل کرتا ہے، اور کتابچہ اس ڈائریکٹری کو بعد کی منتقلی کے ذریعے ڈیٹا کے طور پر استعمال کے لیے رکھی گئی بتاتا ہے۔ نسبتی نام ہدف ڈائریکٹری کے تحت حل ہوتا ہے، جو آپ کو تب چاہیے جب دونوں سروں کی ترتیب مختلف ہو سکتی ہو۔
rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
large-archive.bin [email protected]:/srv/incoming/
ہدف پر بھی ترتیب اہم ہے: جزوی ڈائریکٹری کو ٹکڑے کے لیے کافی جگہ چاہیے، اور والیوم کو مکمل فائل کے لیے بھی کافی جگہ چاہیے۔ منتقلی کے درمیان ہدف والیوم بھر جانے سے ایسی ناکامی ہوتی ہے جو نیٹ ورک مسئلہ لگتی ہے مگر نہیں ہے، اور یہ رکھا گیا ٹکڑا کٹا ہوا چھوڑ سکتی ہے۔ رن شروع ہونے سے پہلے وصول کرنے والے ہوسٹ پر خالی جگہ دیکھیں، ناکامی کے بعد نہیں۔ اسی SSH راستے پر df -h کے ساتھ چند سیکنڈ منصوبے کی سب سے سستی ممکن جانچ ہے۔
اجازتیں چھوٹی مگر حقیقی فکر ہیں۔ غیر متعلقہ اکاؤنٹس کے لکھ سکنے والی جزوی ڈائریکٹری کسی اور کو ایسا مواد بدلنے دیتی ہے جسے آپ کی اگلی بار پہلے سے موصول سمجھے گی۔ اسے منتقلی اکاؤنٹ کی ملکیت میں رکھیں، اور جہاں سے دوسری خدمات شائع کرتی ہیں وہاں نہ رکھیں۔
وہی نقل چلائیں، زیادہ چالاک نہیں
دوبارہ استعمال صرف تب لاگو ہوتا ہے جب ماخذ اور ہدف اب بھی وہی چیز بیان کریں۔ وہی راستہ، وہی نام، وہی فائل۔ ماخذ کا نام بدلنا یا کسی دوسری ہدف ڈائریکٹری کی طرف اشارہ کرنا کسی کام کی نہ ہونے والی چیز کے ساتھ نئی موازنہ شروع کرتا ہے۔
ڈیلٹا رویے کی توقع کرتے ہوئے --whole-file شامل نہ کریں۔ وہ اختیار rsync سے کہتا ہے کہ پوری فائل بغیر رولنگ چیک سم موازنے کے نقل کرے، جو تیز مقامی لنک پر مناسب اور ناکام طویل فاصلے کے اپ لوڈ کے بعد بالکل غلط ہے۔ --inplace بھی کہانی بدلتا ہے: براہ راست ہدف فائل میں لکھتا ہے، اس لیے مداخلت ایسی فائل چھوڑتی ہے جو پرانا اور نیا مواد ملاتی ہے، واپس جانے کے لیے الگ ٹکڑا نہیں رہتا۔
پیش رفت سطر منتقلی کی مجموعی پیش رفت بتاتی ہے۔ یہ تکمیل کا اشارہ نہیں ہے۔ ایسا عدد جو سو فیصد تک پہنچے جبکہ کنکشن اب بھی کھلا ہو، اس کا مطلب ہے کہ ڈیٹا دھکیل دیا گیا ہے، یہ نہیں کہ وصول کنندہ نے کچھ نام بدلا، ہم آہنگ کیا یا قبول کیا۔
چیز کو میل کھانے کے بعد ہی قبول کریں
پہلے اخراج کی حالت کی تصدیق کریں، پھر غلطیوں کی عدم موجودگی پر بھروسے کے بجائے نتیجے کا موازنہ کریں۔ سائز کی جانچ زیادہ تر کٹی ہوئی منتقلیاں پکڑتی ہے؛ چیک سم موازنہ باقی پکڑتا ہے، اور اپ لوڈ دوبارہ چلانے کے مقابلے میں دونوں سستے ہیں۔
اگر آرکائیو کو نیچے کا عمل شائع کرتا ہے، تو اس عمل کو قبول شدہ فائل کا انتظار کرائیں۔ آخری نام کے تحت نگرانی والی ڈائریکٹری میں گرنے والا رکھا گیا ٹکڑا اگلی اسکین اٹھا لیتی ہے، اور صارف کی غلطی کبھی نہ ختم ہونے والی منتقلی کے بارے میں نہیں، خراب اِن پٹ کے بارے میں ہوگی۔
جب تک وصول کنندہ تصدیق نہ کرے ماخذ کو نہ چھیڑیں۔ کوششوں کے درمیان آرکائیو دوبارہ بنانا موازنے کی بنیاد بدلتا ہے، اور اگلی بار یا تو تقریباً سب کچھ منتقل کرتی ہے یا ایسی فائل بناتی ہے جو نہ پرانے نہ نئے ماخذ سے میل کھاتی ہے۔
جب حد جھنڈا نہیں، لنک ہوتا ہے
ہیڈر اور پروٹوکول کا اضافی بوجھ منتقلی کی ایک لاگت ہے، اور بڑی فائل میں کتنا وقت لگے گا یہ شاذ و نادر ہی وہی طے کرتا ہے۔ دوبارہ شروع ہونے کا رویہ زیادہ اہم ہے: جو طریقہ دستی قدموں کے بغیر خلل سے گزر جاتا ہے، وہ دوبارہ شروع کرنے والے تیز طریقے سے پہلے قابل استعمال فائل دیتا ہے۔ دونوں سروں کا ذخیرہ اور توثیق کا راستہ اسی موازنے میں آتے ہیں۔
اجازت شدہ متبادل راستوں کا اسی فائل اور اسی ہدف کے ساتھ موازنہ کریں، اور لکھیں کہ خلل کے بعد ہر ایک کہاں سے دوبارہ شروع ہوتا ہے۔ وہ ایک ہی کالم VPN پر بارہ گیگابائٹ کے اپ لوڈ کے بارے میں مختصر جانچ میں ناپی گئی کسی بھی بلند ترین رفتار سے زیادہ بتاتا ہے۔