تیار پر بیک اپ: چھٹی کے اعزاز میں خرافات کا پردہ چاک کرنا

بیک اپ ان جدید ٹکنالوجیوں میں سے ایک نہیں ہے جس کے بارے میں ہر آئرن سے شور مچایا جاتا ہے۔ یہ کسی بھی سنجیدہ کمپنی میں ہونا ضروری ہے، بس۔ ہم اپنے بینک میں کئی ہزار سرورز کا بیک اپ لیتے ہیں - یہ ایک پیچیدہ، دلچسپ کام ہے، جس میں سے کچھ باریکیوں کے ساتھ ساتھ بیک اپ کے بارے میں عام غلط فہمیاں، صرف بتانا چاہتے ہیں۔

میں اس موضوع پر تقریباً 20 سال سے کام کر رہا ہوں، جن میں سے پچھلے 2 سال Promsvyazbank میں ہیں۔ پریکٹس کے بالکل شروع میں، میں نے تقریباً دستی طور پر بیک اپ کیا، اسکرپٹ کے ساتھ جو فائلوں کو آسانی سے کاپی کرتے تھے۔ پھر ونڈوز میں آسان ٹولز نمودار ہوئے: فائلوں کی تیاری کے لیے روبوکوپی یوٹیلیٹی اور کاپی کرنے کے لیے NT بیک اپ۔ اور تب ہی خصوصی سافٹ ویئر کا وقت آیا، بنیادی طور پر Veritas Backup Exec، جسے اب Symantec Backup Exec کہا جاتا ہے۔ لہذا میں بیک اپ سے کافی عرصے سے واقف ہوں۔

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

بیک اپ کا سب سے عام استعمال مختلف ٹیسٹ سسٹمز، ڈیولپرز کے لیے کلون کی تعیناتی کے لیے ڈیٹا بیس کی محفوظ شدہ کاپی کی بحالی ہے۔

بیک اپ کے ارد گرد چند عام خرافات ہیں جنہیں بہت پہلے دور کر دیا جانا چاہیے۔ یہاں ان میں سے سب سے مشہور ہیں۔

متک 1. بیک اپ طویل عرصے سے سیکیورٹی یا اسٹوریج سسٹم کے اندر صرف ایک چھوٹا سا کام رہا ہے۔

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

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

افسانہ 2۔ جب RAID ہوتا ہے تو بیک اپ کی ضرورت نہیں رہتی۔

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

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

متک 3. بیک اپ ایک ایسی چیز ہے جو مہینے میں ایک بار کی جاتی ہے۔

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

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

متک 4۔ کاپیوں کا حجم مسلسل بڑھ رہا ہے اور کسی بھی مختص جگہ کو مکمل طور پر لے جاتا ہے۔

بیک اپ میں برقرار رکھنے کی ایک محدود مدت ہوتی ہے۔ مثال کے طور پر، سال کے دوران تمام 365 یومیہ بیک اپ کو ذخیرہ کرنا کوئی معنی نہیں رکھتا۔ ایک اصول کے طور پر، روزانہ کی کاپیاں 2 ہفتوں کے لیے رکھنا قابل قبول ہے، جس کے بعد انہیں تازہ سے بدل دیا جاتا ہے، اور جو ورژن پہلے مہینے میں بنایا گیا تھا وہ طویل مدتی اسٹوریج میں رہتا ہے۔ یہ، بدلے میں، ایک خاص وقت کے لیے بھی ذخیرہ کیا جاتا ہے - ہر ایک کاپی کی زندگی بھر ہوتی ہے۔

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

متک 5. بیک اپ شروع ہوا - سب کچھ لٹک گیا۔

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

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

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

بڑی تنظیموں میں بیک اپ سسٹم کے لیے الگ نیٹ ورک بنایا جاتا ہے تاکہ بیک اپ پروڈکشن کو متاثر نہ کرے۔ اس کے علاوہ، ٹریفک نیٹ ورک کے ذریعے نہیں بلکہ SAN کے ذریعے منتقل ہو سکتی ہے۔

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

افسانہ 6۔ ایک بیک اپ سسٹم شروع کیا - یہ آپ کے لیے غلطی برداشت ہے۔

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

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

افسانہ 7۔ میں نے ایک بار بیک اپ ترتیب دیا، چیک کیا کہ یہ کام کرتا ہے۔ یہ صرف نوشتہ جات کو دیکھنے کے لئے رہتا ہے۔

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

اور سسٹم ایڈمنسٹریٹر کے کام کے بارے میں تھوڑا سا

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

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

چھٹی کے اعزاز میں، میں تمام منتظمین کو مضبوط اعصاب، نقل و حرکت کی وضاحت اور بیک اپ کو ذخیرہ کرنے کے لیے لامتناہی جگہ کی خواہش کرنا چاہوں گا!

ماخذ: www.habr.com