Pritunl: کنٹرول حالت بمقابلہ تیار شدہ پروفائل

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

دو اشیاء بیک اپ معلوم ہوتی ہیں اور صرف ایک خدمت بحال کرتی ہے

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

میزبان کی کنفیگریشن کی نقل بھی اتنی ہی جزوی ہے۔ /etc/pritunl.conf میزبان سطح کی ترتیبات رکھتا ہے، بشمول ڈیٹا بیس تک پہنچنے کا طریقہ، اور خود VPN اشیاء نہیں رکھتا۔

ڈیٹا بیس کیا رکھتا ہے اور میزبان کیا رکھتا ہے

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

میزبان قدرے چھوٹا مگر ناقابلِ منتقلی مجموعہ فراہم کرتا ہے۔ ان میں سے ایک /var/lib/pritunl/pritunl.uuid ہے، اسی مخصوص نوڈ کی شناخت۔

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

مستقل مزاج ڈمپ لیں، فولڈر کی نقل نہیں

خدمت کے لکھتے وقت MongoDB ڈیٹا فولڈر کی نقل ایسی فائلیں بناتی ہے جو قابلِ استعمال ڈیٹا بیس نہ بنا سکیں۔ اس کے بجائے ڈیٹا بیس کا معاون ڈمپ راستہ استعمال کریں، جو اسی ٹوپولوجی کے خلاف چلایا جائے جو آپ کے پاس واقعی ہے:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

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

ضرورت سے پہلے بحالی کی مشق کریں

وہ بیک اپ جسے کسی نے بحال نہ کیا ہو ایک مفروضہ ہے۔ خدمت کو الگ تھلگ نیٹ ورک میں بنائیں، ڈمپ بحال کریں اور میزبان کی فائلیں واپس رکھیں:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

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