🥇 گٹ لیب آپ کو نیکسٹ کلاؤڈ سٹوریجز کا بیک اپ بنانے میں کس طرح مدد کرتا ہے۔ پرو ہوسٹر

ارے حبر!

آج میں نیکسٹ کلاؤڈ اسٹوریج سے بڑے ڈیٹا کے بیک اپ کو مختلف کنفیگریشنز میں خودکار بنانے کے اپنے تجربے کے بارے میں بات کرنا چاہتا ہوں۔ میں Molniya AK میں ایک سروس سٹیشن کے طور پر کام کرتا ہوں، جہاں ہم IT سسٹمز کی کنفیگریشن مینجمنٹ کرتے ہیں؛ Nextcloud کو ڈیٹا اسٹوریج کے لیے استعمال کیا جاتا ہے۔ بشمول، تقسیم شدہ ڈھانچے کے ساتھ، فالتو پن کے ساتھ۔

تنصیبات کی خصوصیات سے پیدا ہونے والے مسائل یہ ہیں کہ ڈیٹا کی بہتات ہے۔ نیکسٹ کلاؤڈ کے ذریعہ فراہم کردہ ورژننگ، فالتو پن، موضوعی وجوہات، اور مزید بہت سے نقلیں تخلیق کرتی ہیں۔

پس منظر

نیکسٹ کلاؤڈ کا انتظام کرتے وقت، ایک مؤثر بیک اپ کو منظم کرنے کا مسئلہ پیدا ہوتا ہے، جو کہ انکرپٹ ہونا ضروری ہے، کیونکہ ڈیٹا قیمتی ہے۔

ہم اپنی جگہ پر یا گاہک کے پاس نیکسٹ کلاؤڈ سے الگ مشینوں پر بیک اپ اسٹور کرنے کے اختیارات پیش کرتے ہیں، جس کے لیے انتظامیہ کے لیے ایک لچکدار خودکار نقطہ نظر کی ضرورت ہوتی ہے۔

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

سب سے پہلے، آئیے ان پٹ ڈیٹا کو دیکھتے ہیں۔ ہمیں ضرورت ہے:

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

بیک اپ کے انتظام کے مسئلے کو حل کرنے کے لیے، ہم نے GitLab انسٹال کیا۔ مزید تفصیلات بذریعہ ٹیکل۔

بلاشبہ، ہم اس طرح کے مسئلے کو حل کرنے والے پہلے نہیں ہیں، لیکن ہمیں لگتا ہے کہ ہمارا عملی، محنت سے کمایا ہوا تجربہ دلچسپ ہو سکتا ہے اور ہم اسے بانٹنے کے لیے تیار ہیں۔

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

بیک اپ ٹولز

ہم نے بیک اپ بنانے کے ٹول کا انتخاب کرکے حل کے طریقوں کی تلاش شروع کی۔

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

ڈپلیکیشن کے ساتھ بیک اپ ٹولز اوپن سورس میں دستیاب ہیں (Habré پر موجود تھے۔ مضامین اس تھیم کے بارے میں) اور ہمارے فائنلسٹ تھے۔ بورگ и ریسٹیک. دونوں ایپلیکیشنز کا ہمارا موازنہ ذیل میں ہے، لیکن ابھی کے لیے ہم آپ کو بتائیں گے کہ ہم نے پوری اسکیم کو کیسے منظم کیا۔

بیک اپ کا انتظام کرنا

بورگ اور ریسٹک اچھے ہیں، لیکن کسی بھی پروڈکٹ میں مرکزی کنٹرول میکانزم نہیں ہے۔ مینجمنٹ اور کنٹرول کے مقصد کے لیے، ہم نے ایک ٹول کا انتخاب کیا جسے ہم پہلے ہی نافذ کر چکے ہیں، جس کے بغیر ہم اپنے کام کا تصور بھی نہیں کر سکتے، بشمول آٹومیشن - یہ معروف CI/CD - GitLab ہے۔

خیال مندرجہ ذیل ہے: گٹ لیب رنر نیکسٹ کلاؤڈ ڈیٹا کو اسٹور کرنے والے ہر نوڈ پر انسٹال ہوتا ہے۔ رنر ایک شیڈول پر اسکرپٹ چلاتا ہے جو بیک اپ کے عمل کی نگرانی کرتا ہے، اور یہ بورگ یا ریسٹک کا آغاز کرتا ہے۔

ہمیں کیا ملا؟ عملدرآمد سے رائے، تبدیلیوں پر آسان کنٹرول، غلطی کی صورت میں تفصیلات۔

یہاں یہاں GitHub پر ہم نے مختلف کاموں کے لیے اسکرپٹ کی مثالیں پوسٹ کیں، اور ہم نے اسے نہ صرف نیکسٹ کلاؤڈ بلکہ بہت سی دوسری سروسز کے بیک اپ سے منسلک کیا۔ اگر آپ اسے دستی طور پر ترتیب نہیں دینا چاہتے ہیں تو وہاں ایک شیڈولر بھی ہے (اور ہم نہیں چاہتے ہیں) اور .gitlab-ci.yml

Gitlab API میں ابھی تک CI/CD ٹائم آؤٹ کو تبدیل کرنے کا کوئی طریقہ نہیں ہے، لیکن یہ چھوٹا ہے۔ اسے بڑھانے کی ضرورت ہے۔ 1d.

GitLab، خوش قسمتی سے، نہ صرف ایک عہد کے مطابق، بلکہ صرف ایک شیڈول کے مطابق، یہ بالکل وہی ہے جس کی ہمیں ضرورت ہے۔

اب ریپر اسکرپٹ کے بارے میں۔

ہم نے اس اسکرپٹ کے لیے درج ذیل شرائط رکھی ہیں۔

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

مکمل لاگ کو GitLab میں ایک نمونے کے طور پر محفوظ کیا جاتا ہے؛ اگر کوئی خرابی نہیں ہے، تو لاگ کو حذف کر دیا جاتا ہے۔ ہم اسکرپٹ کو باش میں لکھتے ہیں۔

ہمیں اوپن سورس کے حوالے سے کسی بھی تجاویز اور تبصرے پر غور کرنے میں خوشی ہوگی - خوش آمدید۔

یہ کیسے کام کرتا ہے

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

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

ہم نے ssh کے ذریعے بیک اپ بھیجنے کی خصوصیت کا استعمال نہیں کیا۔ اس سے سیکیورٹی میں اضافہ نہیں ہوتا، اور S3 فراہم کنندہ کی نیٹ ورک کی صلاحیتیں ہماری ایک ssh مشین سے کہیں زیادہ ہیں۔

اپنی مقامی مشین کو ہیکر سے بچانے کے لیے، چونکہ وہ S3 پر ڈیٹا مٹا سکتا ہے، آپ کو ورژننگ کو فعال کرنا ہوگا۔
بیک اپ ہمیشہ بیک اپ کو خفیہ کرتا ہے۔

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

ایک الگ شیڈولر اشاریہ جات اور مواد کی سالمیت کے لیے بیک اپ چیک کرتا ہے۔ چیک سست اور طویل ہے، اس لیے ہم اسے مہینے میں ایک بار الگ سے چلاتے ہیں۔ اس میں کئی دن لگ سکتے ہیں۔

روسی میں ریڈمی

اہم افعال

prepare تربیت
testcheck تیاری کی جانچ
maincommand بنیادی ٹیم
forcepostscript ایک فنکشن جو آخر میں یا غلطی سے انجام پاتا ہے۔ ہم اسے پارٹیشن کو ان ماؤنٹ کرنے کے لیے استعمال کرتے ہیں۔

سروس کے افعال

cleanup ہم غلطیاں ریکارڈ کرتے ہیں یا لاگ فائل کو مٹا دیتے ہیں۔
checklog غلطی کے ساتھ لائن کی موجودگی کے لیے لاگ کو پارس کریں۔
ret باہر نکلیں ہینڈلر.
checktimeout ٹائم آؤٹ کے لئے چیک کریں.

ماحولیات

VERBOSE=1 ہم فوری طور پر اسکرین پر غلطیاں ظاہر کرتے ہیں (stdout)۔
SAVELOGSONSUCCES=1 کامیابی پر لاگ کو محفوظ کریں.
INIT_REPO_IF_NOT_EXIST=1 ایک ذخیرہ بنائیں اگر یہ موجود نہیں ہے۔ بطور ڈیفالٹ غیر فعال۔
TIMEOUT اہم آپریشن کے لئے زیادہ سے زیادہ وقت. آپ اسے آخر میں 'm'، 'h' یا 'd' کے طور پر سیٹ کر سکتے ہیں۔

پرانی کاپیوں کے لیے اسٹوریج موڈ۔ ڈیفالٹ:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

اسکرپٹ کے اندر متغیرات

ERROR_STRING - غلطی کے لیے چیک ان لاگ کے لیے سٹرنگ۔
EXTRACT_ERROR_STRING - اگر غلطی ہو تو سٹرنگ شو کے لیے اظہار۔
KILL_TIMEOUT_SIGNAL - وقت ختم ہونے پر مارنے کا اشارہ۔
TAIL - اسکرین پر غلطیوں کے ساتھ کتنے تار ہیں۔
COLORMSG - پیغام کا رنگ (پہلے سے طے شدہ پیلا)۔

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

ریسٹک بمقابلہ بورگ

بورگ اور ریسٹک کے درمیان موازنہ بھی ہیں۔ یہاں Habré پر، اور ہمارے پاس صرف ایک اور بنانے کا کام نہیں تھا، لیکن ہمارا اپنا۔ یہ ہمارے لیے اہم تھا کہ یہ ہماری تفصیلات کے ساتھ ہمارے ڈیٹا پر کیسا نظر آئے گا۔ ہم انہیں لاتے ہیں۔

ہمارے انتخاب کے معیار، ان کے علاوہ جن کا پہلے سے ذکر کیا گیا ہے (ڈپلیکیشن، تیزی سے بحالی، وغیرہ):

نامکمل کام کی مزاحمت۔ قتل کے لیے چیک کریں -9۔
ڈسک پر سائز۔
وسائل کی ضرورت (سی پی یو، میموری)۔
ذخیرہ شدہ بلاب کا سائز۔
S3 کے ساتھ کام کرنا۔
سالمیت کی جانچ۔

جانچ کے لیے، ہم نے حقیقی ڈیٹا اور کل سائز 1,6 TB کے ساتھ ایک کلائنٹ لیا۔
شرائط۔

بورگ S3 کے ساتھ براہ راست کام کرنے کا طریقہ نہیں جانتا، اور ہم نے ڈسک کو فیوز کے طور پر نصب کیا، بیوقوف. ریسٹک نے اسے خود S3 پر بھیجا ہے۔

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

نیٹ ورک کے اثر و رسوخ کو کم کرنے کے لیے، ہم نے ایک مقامی فراہم کنندہ - Yandex Cloud کا استعمال کیا۔

موازنہ جانچ کے نتائج۔

مزید دوبارہ شروع کرنے کے ساتھ Kill -9 دونوں کامیاب رہے۔
ڈسک پر سائز۔ بورگ کمپریس کرسکتا ہے، لہذا نتائج توقع کے مطابق ہیں۔

بیک اپ کرنے والا
سائز

بورگ
562Gb

ریسٹیک
628Gb

سی پی یو کے ذریعہ
بورگ بذات خود پہلے سے طے شدہ کمپریشن کے ساتھ بہت کم استعمال کرتا ہے، لیکن اس کا اندازہ بوفس عمل کے ساتھ مل کر کیا جانا چاہیے۔ مجموعی طور پر، وہ موازنہ ہیں اور ایک ہی ٹیسٹ ورچوئل مشین پر تقریباً 1,2 کور استعمال کرتے ہیں۔
یاداشت. ریسٹک تقریباً 0,5GB ہے، بورگ تقریباً 200MB ہے۔ لیکن سسٹم فائل کیشے کے مقابلے میں یہ سب معمولی ہے۔ اس لیے زیادہ میموری مختص کرنے کا مشورہ دیا جاتا ہے۔
بلاب کے سائز میں فرق حیران کن تھا۔

بیک اپ کرنے والا
سائز

بورگ
تقریبا 500MB

ریسٹیک
تقریبا 5MB

ریسٹک کے S3 کا تجربہ بہترین ہے۔ گوفیز کے ذریعے بورگ کے ساتھ کام کرنے سے کوئی سوال نہیں پیدا ہوتا، لیکن یہ نوٹ کیا گیا ہے کہ بیک اپ مکمل ہونے کے بعد کیش کو مکمل طور پر دوبارہ ترتیب دینے کے لیے umount کرنے کا مشورہ دیا جاتا ہے۔ S3 کی خاصیت یہ ہے کہ انڈر پمپ شدہ ٹکڑوں کو کبھی بھی بالٹی میں نہیں بھیجا جائے گا، جس کا مطلب ہے کہ نامکمل طور پر بھرا ہوا ڈیٹا بڑے نقصان کا باعث بنتا ہے۔
سالمیت کی جانچ دونوں صورتوں میں اچھی طرح کام کرتی ہے، لیکن رفتار نمایاں طور پر مختلف ہوتی ہے۔
آرام دہ 3,5 گھنٹے.
بورگ، 100GB SSD فائل کیشے کے ساتھ - 5 گھنٹےاگر ڈیٹا مقامی ڈسک پر ہے تو تقریباً ایک ہی رفتار کا نتیجہ۔
بورگ بغیر کیشے کے S3 سے براہ راست پڑھتا ہے۔ 33 گھنٹے. ایک خوفناک لمبا عرصہ۔

سب سے اہم بات یہ ہے کہ بورگ کمپریس کرسکتا ہے اور اس میں بڑے بلاب ہوتے ہیں - جو S3 میں اسٹوریج اور GET/PUT آپریشن کو سستا بناتا ہے۔ لیکن یہ زیادہ پیچیدہ اور سست تصدیق کی قیمت پر آتا ہے۔ جہاں تک بحالی کی رفتار کا تعلق ہے، ہم نے کوئی فرق محسوس نہیں کیا۔ ریسٹک بعد کے بیک اپ (پہلے کے بعد) تھوڑی دیر لیتا ہے، لیکن نمایاں طور پر نہیں۔

آخری لیکن کم از کم انتخاب میں کمیونٹی کا سائز تھا۔

اور ہم نے بورگ کا انتخاب کیا۔

کمپریشن کے بارے میں چند الفاظ

بورگ کے پاس اپنے ہتھیاروں میں ایک بہترین نیا کمپریشن الگورتھم ہے - zstd. کمپریشن کا معیار gzip سے بدتر نہیں ہے، لیکن بہت تیز ہے۔ اور رفتار میں ڈیفالٹ lz4 سے موازنہ۔

مثال کے طور پر، ایک MySQL ڈیٹا بیس ڈمپ کو اسی رفتار سے lz4 سے دو گنا بہتر کمپریس کیا جاتا ہے۔ تاہم، حقیقی ڈیٹا کے تجربے سے پتہ چلتا ہے کہ نیکسٹ کلاؤڈ نوڈ کے کمپریشن تناسب میں بہت کم فرق ہے۔

بورگ کے پاس بونس کمپریشن موڈ ہے - اگر فائل میں زیادہ اینٹروپی ہے، تو کمپریشن بالکل بھی لاگو نہیں ہوتا ہے، جس سے رفتار بڑھ جاتی ہے۔ تخلیق کرتے وقت اختیار کے ذریعے فعال کیا جاتا ہے۔
-C auto,zstd
zstd الگورتھم کے لیے
تو اس آپشن کے ساتھ، پہلے سے طے شدہ کمپریشن کے مقابلے میں، ہمیں مل گیا۔
بالترتیب 560Gb اور 562Gb۔ مندرجہ بالا مثال سے ڈیٹا، میں آپ کو یاد دلاتا ہوں، بغیر کمپریشن کے نتیجہ 628Gb ہے۔ 2 جی بی کے فرق کے نتیجے نے ہمیں کچھ حیران کر دیا، لیکن ہم نے سوچا کہ آخر کار ہم اسے منتخب کریں گے۔ auto,zstd.

بیک اپ کی توثیق کا طریقہ

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

اسکیل ایبلٹی مختلف ٹیگز کے ساتھ مختلف نوڈس پر رنر چلانے سے حاصل کی جاتی ہے۔
ہماری نگرانی ایک ونڈو میں GitLab API کے ذریعے بیک اپ سٹیٹس کو جمع کرتی ہے؛ اگر ضروری ہو تو، مسائل آسانی سے محسوس کیے جاتے ہیں اور بالکل آسانی سے لوکلائز کیے جاتے ہیں۔

حاصل يہ ہوا

نتیجے کے طور پر، ہم یقینی طور پر جانتے ہیں کہ ہم بیک اپ بناتے ہیں، کہ ہمارے بیک اپ درست ہیں، ان کے ساتھ پیدا ہونے والے مسائل میں بہت کم وقت لگتا ہے اور ڈیوٹی ایڈمنسٹریٹر کی سطح پر حل ہو جاتے ہیں۔ tar.gz یا Bacula کے مقابلے میں بیک اپ واقعی بہت کم جگہ لیتے ہیں۔

ماخذ: www.habr.com

GitLab کس طرح آپ کو نیکسٹ کلاؤڈ اسٹوریجز کا بیک اپ لینے میں مدد کرتا ہے۔