بہت سے بیک اپ سسٹمز ہیں، لیکن اگر پیش کیے گئے سرورز مختلف علاقوں اور کلائنٹس میں بکھرے ہوئے ہوں اور آپ کو آپریٹنگ سسٹم کے ساتھ کام کرنے کی ضرورت ہو تو کیا کریں؟
گڈ آفٹر نون، حبر!
میرا نام نتالیہ ہے۔ میں NPO کرسٹا میں ایپلیکیشن ایڈمنسٹریٹرز گروپ کا ٹیم لیڈر ہوں۔ ہم اپنی کمپنی کے پروجیکٹ گروپ کے لیے آپریشنز ہیں۔ ہمارے پاس ایک منفرد صورت حال ہے: ہم اپنے سافٹ ویئر کو اپنی کمپنی کے سرورز اور کلائنٹس کی سائٹس پر واقع سرورز دونوں پر انسٹال اور برقرار رکھتے ہیں۔ اس صورت میں، پورے سرور کو بیک اپ کرنے کی ضرورت نہیں ہے۔ صرف "ضروری ڈیٹا" اہم ہے: DBMS اور انفرادی فائل سسٹم ڈائریکٹریز۔ بلاشبہ، کلائنٹس کے پاس اپنے بیک اپ کے ضوابط ہیں (یا نہیں ہیں) اور اکثر وہاں بیک اپ کو ذخیرہ کرنے کے لیے کسی قسم کی بیرونی اسٹوریج فراہم کرتے ہیں۔ اس صورت میں، بیک اپ بنانے کے بعد، ہم بیرونی اسٹوریج پر بھیجنے کو یقینی بناتے ہیں۔
کچھ عرصے کے لیے، بیک اپ کے مقاصد کے لیے، ہم نے ایک bash اسکرپٹ کے ساتھ کام کیا، لیکن جیسے جیسے کنفیگریشن کے اختیارات بڑھتے گئے، اس اسکرپٹ کی پیچیدگی متناسب طور پر بڑھتی گئی، اور ایک موقع پر ہمیں "اسے زمین پر تباہ کرنے کی ضرورت پیش آئی، اور پھر ..."
ریڈی میڈ حل مختلف وجوہات کی بناء پر موزوں نہیں تھے: بیک اپ کو غیر مرکزی بنانے کی ضرورت کی وجہ سے، بیک اپ کو مقامی طور پر کلائنٹ پر ذخیرہ کرنے کی ضرورت، سیٹ اپ کی پیچیدگی، درآمدی متبادل، رسائی کی پابندیاں۔
ہمیں ایسا لگتا تھا کہ اپنا کچھ لکھنا آسان ہے۔ ایک ہی وقت میں، میں کچھ حاصل کرنا چاہتا تھا جو اگلے N سالوں کے لئے ہماری صورت حال کے لئے کافی ہو، لیکن ممکنہ طور پر دائرہ کار کو بڑھانے کے امکان کے ساتھ.
کام کی شرائط حسب ذیل تھیں۔
- بنیادی بیک اپ مثال خود مختار ہے اور مقامی طور پر چلتا ہے۔
- بیک اپ اور لاگز کا ذخیرہ ہمیشہ کلائنٹ کے نیٹ ورک میں ہوتا ہے۔
- ایک مثال ماڈیولز پر مشتمل ہوتی ہے - ایک قسم کا "کنسٹرکٹر"
- موجودہ لینکس کی تقسیم کے ساتھ مطابقت درکار ہے، بشمول فرسودہ، ممکنہ کراس پلیٹ فارم مطلوبہ ہے
- مثال کے ساتھ کام کرنے کے لیے، ssh کے ذریعے رسائی کافی ہے؛ اضافی بندرگاہیں کھولنا ضروری نہیں ہے
- سیٹ اپ اور آپریشن کی زیادہ سے زیادہ آسانی
- یہ ممکن ہے (لیکن ضروری نہیں) ایک الگ مثال ہے جو آپ کو مختلف سرورز سے بیک اپ کی حیثیت کو مرکزی طور پر دیکھنے کی اجازت دیتی ہے۔
آپ دیکھ سکتے ہیں کہ ہم یہاں کیا لے کر آئے ہیں:
سافٹ ویئر python3 میں لکھا گیا ہے۔ Debian، Ubuntu، CentOS، AstraLinux 1.6 پر کام کرتا ہے۔
دستاویزات کو ذخیرہ کی دستاویزات کی ڈائرکٹری میں پوسٹ کیا گیا ہے۔
بنیادی تصورات جو نظام چلاتا ہے:
ایکشن - ایک ایسی کارروائی جو ایک ایٹمی آپریشن کو نافذ کرتی ہے (ڈیٹا بیس بیک اپ، ڈائریکٹری بیک اپ، ڈائریکٹری A سے ڈائریکٹری B میں منتقلی، وغیرہ)۔ موجودہ ایکشنز کور/ایکشن ڈائرکٹری میں موجود ہیں۔
ٹاسک - کام، ایک منطقی "بیک اپ ٹاسک" کو بیان کرنے والے اعمال کا ایک مجموعہ
شیڈول - شیڈول، کاموں کا ایک سیٹ جس میں کام کے عمل کے وقت کا اختیاری اشارہ ہوتا ہے۔
بیک اپ کنفیگریشن yaml فائل میں محفوظ ہے۔ عام ترتیب کی ساخت:
- عام ترتیبات
- ایکشن سیکشن: اس سرور پر استعمال ہونے والے اعمال کی تفصیل
- شیڈول سیکشن: تمام کاموں کی تفصیل (کارروائیوں کے سیٹ) اور کرون کے ذریعے ان کے لانچ کا شیڈول، اگر اس طرح کے لانچ کی ضرورت ہو
درخواست فی الحال کیا کر سکتی ہے:
- ہمارے لیے اہم آپریشنز معاون ہیں: پوسٹگری ایس کیو ایل بیک اپ بذریعہ pg_dump، فائل سسٹم ڈائرکٹری بیک اپ بذریعہ ٹار؛ بیرونی اسٹوریج کے ساتھ آپریشن؛ ڈائریکٹریز کے درمیان rsync؛ بیک اپ گردش (پرانی کاپیاں حذف کرنا)
- ایک بیرونی اسکرپٹ کو کال کرنا
- ایک علیحدہ کام کی دستی عملدرآمد
/opt/KristaBackup/KristaBackup.py run make_full_dump - آپ کرونٹاب میں ایک کام یا پورا شیڈول شامل کر سکتے ہیں (یا ہٹا سکتے ہیں)
/opt/KristaBackup/KristaBackup.py enable all - بیک اپ کے نتائج کی بنیاد پر ٹرگر فائل بنانا۔ یہ فنکشن بیک اپ کی نگرانی کے لیے Zabbix کے ساتھ مل کر مفید ہے۔
- ویبپی یا ویب موڈ میں پس منظر میں کام کر سکتے ہیں۔
/opt/KristaBackup/KristaBackup.py web start [--api]
طریقوں کے درمیان فرق: webapi میں خود ویب انٹرفیس نہیں ہے، لیکن ایپلی کیشن کسی اور مثال کی درخواستوں کا جواب دیتی ہے۔ ویب موڈ کے لیے، آپ کو فلاسک اور کئی اضافی پیکجز کو انسٹال کرنے کی ضرورت ہے، اور یہ ہر جگہ قابل قبول نہیں ہے، مثال کے طور پر تصدیق شدہ AstraLinux SE میں۔
ویب انٹرفیس کے ذریعے، آپ منسلک سرورز کے بیک اپ کی حیثیت اور لاگز دیکھ سکتے ہیں: "ویب مثال" API کے ذریعے "بیک اپ مثالوں" سے ڈیٹا کی درخواست کرتی ہے۔ ویب تک رسائی کے لیے اجازت درکار ہوتی ہے، ویباپی تک رسائی نہیں ہوتی۔
غلط بیک اپ کے لاگز کو رنگ میں نشان زد کیا گیا ہے: وارننگ – پیلا، غلطی – سرخ۔
اگر ایڈمنسٹریٹر کو پیرامیٹرز پر چیٹ شیٹ کی ضرورت نہیں ہے اور سرور آپریٹنگ سسٹم یکساں ہیں، تو آپ فائل کو مرتب کر کے تیار پیکج کو تقسیم کر سکتے ہیں۔
ہم اس افادیت کو بنیادی طور پر Ansible کے ذریعے تقسیم کرتے ہیں، اسے پہلے کچھ کم سے کم اہم سرورز کے لیے رول آؤٹ کرتے ہیں، اور باقی تمام پر جانچ کے بعد۔
نتیجے کے طور پر، ہمیں ایک کمپیکٹ، اسٹینڈ اکیلے کاپی کی افادیت ملی جو خودکار ہو سکتی ہے اور ناتجربہ کار منتظمین بھی استعمال کر سکتے ہیں۔ یہ ہمارے لیے آسان ہے - شاید یہ آپ کے لیے بھی کارآمد ہو؟
ماخذ: www.habr.com