rsync VPN کے ذریعے: کون سا پہلو حقیقت کا ماخذ ہے؟

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

کمانڈ لکھنے سے پہلے فیصلہ کریں کہ کون سی نقل جیتتی ہے

سمت کو ایک جملے میں لکھیں، ہر طرف میزبان کا نام اور راستہ شامل کرتے ہوئے، اور ڈیٹا کے مالک سے منظوری لیں۔ اس وضاحت میں ماخذ /srv/publish/ ہے اور منزل fileserver.example پر ایک اکاؤنٹ ہے جسے صرف /srv/mirror/ میں لکھنے کی اجازت ہے۔

نقل سے پہلے نقل و حمل کے حقائق کی تصدیق کریں: SSH میزبان کلید تصدیق شدہ ہے، منزل کا اکاؤنٹ نقل کے علاقے میں لکھ سکتا ہے اور کہیں نہیں، اور دونوں میزبانوں کے rsync ورژن ہم آہنگ ہیں۔ یہ پیش شرطیں ایک چھوٹی منصوبہ بندی کی غلطی کو اجازت کے واقعے میں بدلنے سے روکتی ہیں۔ وہ یہ بھی بتاتی ہیں کہ جب کچھ غلط ہو تو منزل کے لاگز میں کون سا اکاؤنٹ نظر آئے گا۔

نقل کا پیش منظر دیکھیں اور تفصیلی فہرست پڑھیں

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

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

پھر فیصلہ کریں کہ حذف ہجرت کرتے ہیں یا نہیں

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

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

دو یک طرفہ کام دو طرفہ ہم آہنگی نہیں بناتے

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

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

صرف پالیسی لکھنے کے بعد خودکار بنائیں

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

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

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