🥇 ڪيئن GitLab توهان کي وڏين NextCloud ريپوزٽريز جو بيڪ اپ وٺڻ ۾ مدد ڪري ٿي

اي حبر!

اڄ مان مختلف ترتيبن ۾ Nextcloud اسٽوريج سسٽم لاءِ وڏي ڊيٽا بيڪ اپ کي خودڪار ڪرڻ جو تجربو شيئر ڪرڻ چاهيان ٿو. مان Molniya AK ۾ CTO طور ڪم ڪريان ٿو، جتي اسان IT سسٽم لاءِ ترتيب جي انتظام کي سنڀاليندا آهيون. Nextcloud ڊيٽا اسٽوريج لاءِ استعمال ڪيو ويندو آهي، جنهن ۾ ورهايل structure ۽ redundancy شامل آهن.

انسٽاليشن جي مخصوص نوعيت مان پيدا ٿيندڙ مسئلا اهو آهن ته اتي تمام گهڻو ڊيٽا آهي. Nextcloud جي ورزننگ، ريڊنڊنسي، ذاتي عنصر، ۽ ٻيا عنصر تمام گهڻا نقل پيدا ڪن ٿا.

prehistory

جڏهن Nextcloud کي منظم ڪيو ويندو آهي، ته هڪ مؤثر بيڪ اپ کي منظم ڪرڻ جو مسئلو شديد ٿي ويندو آهي. ان کي انڪرپٽ ڪيو وڃي، ڇاڪاڻ ته ڊيٽا قيمتي آهي.

اسان بيڪ اپ اسٽوريج جا آپشن پيش ڪريون ٿا يا ته اسان جي احاطي ۾ يا گراهڪ جي پنهنجي مشينن تي، Nextcloud کان الڳ، جنهن لاءِ انتظاميه لاءِ هڪ لچڪدار، خودڪار طريقي جي ضرورت آهي.

ڪيترائي گراهڪ آهن، سڀني جا مختلف ترتيب آهن، ۽ هر هڪ پنهنجي پليٽ فارم تي پنهنجي مخصوص ضرورتن سان. پوري پليٽ فارم جي مالڪي ۽ ڪرون کان بيڪ اپ وٺڻ جو معياري طريقو مثالي ناهي.

اچو ته ان پٽ ڊيٽا کي ڏسي شروع ڪريون. اسان کي گهرجي:

اسڪيليبلٽي: سنگل يا گھڻا نوڊس. وڏين تنصيبات لاءِ، اسان اسٽوريج لاءِ مينيو استعمال ڪندا آهيون.
بيڪ اپ ڪرڻ ۾ مسئلن بابت ڄاڻ حاصل ڪريو.
بيڪ اپ کي ڪلائنٽ ۽/يا اسان جي جاءِ تي ذخيرو ڪرڻ ضروري آهي.
مسئلن کي جلدي ۽ آساني سان حل ڪريو.
ڪلائنٽ ۽ تنصيب هڪ ٻئي کان تمام گهڻو مختلف آهن، جنهن ڪري هڪجهڙائي حاصل ڪرڻ ڏکيو ٿي پوي ٿو.
بحالي جي رفتار ٻن حالتن ۾ گهٽ ۾ گهٽ هجڻ گهرجي: مڪمل بحالي (آفت)، هڪ فولڊر - غلطي سان ڊهي ويو.
ڊيڊپليڪيشن فيچر گهربل آهي.

بيڪ اپ مئنيجمينٽ جي مسئلي کي حل ڪرڻ لاءِ، اسان GitLab کي ضم ڪيو. وڌيڪ تفصيل مضمون ۾.

يقيناً، اسان اهڙي مسئلي کي حل ڪرڻ وارا پهريان نه آهيون، پر اسان جو يقين آهي ته اسان جو عملي، مشڪل سان حاصل ڪيل تجربو دلچسپ ٿي سگهي ٿو، ۽ اسان ان کي شيئر ڪرڻ لاءِ تيار آهيون.

جيئن ته اسان جي ڪمپني وٽ اوپن سورس پاليسي آهي، اسان هڪ اوپن سورس حل ڳولي رهيا هئاسين. اسان پنهنجي ترقيات کي پڻ شيئر ڪريون ٿا ۽ انهن کي دستياب ڪريون ٿا. مثال طور، اسان وٽ اهي GitHub تي آهن. Nextcloud لاءِ اسان جو پلگ ان، جيڪو اسان پنهنجن گراهڪن کي فراهم ڪندا آهيون، حادثاتي يا ارادي طور تي حذف ٿيڻ جي صورت ۾ ڊيٽا جي سيڪيورٽي کي وڌائيندو آهي.

بيڪ اپ اوزار

اسان هڪ بيڪ اپ ٽول چونڊڻ سان حل جي ڳولا شروع ڪئي.

معياري tar + gzip خراب ڪم ڪري ٿو - ڊيٽا نقل ٿيل آهي. هڪ واڌ ۾ اڪثر ڪري تمام گهٽ اصل تبديليون هونديون آهن، ۽ هڪ فائل اندر گهڻو ڪري ڊيٽا بار بار ڪيو ويندو آهي.
هڪ ٻيو مسئلو آهي: ورهايل ڊيٽا اسٽوريج جي بيڪار. اسان مينيو استعمال ڪندا آهيون، ۽ ان جو ڊيٽا بنيادي طور تي بيڪار آهي. متبادل طور تي، اسان کي مينيو ذريعي ئي بيڪ اپ ڪرڻو پوندو - ان کي لوڊ ڪندي ۽ سڀني فائل سسٽم بفرز کي استعمال ڪندي. ۽، بلڪل اهم طور تي، ڪجهه بڪٽس ۽ ميٽا ڊيٽا وسارڻ جو خطرو آهي. يا اسان ڊيڊپليڪيشن استعمال ڪري سگهون ٿا.

نقل سان گڏ بيڪ اپ ٽولز اوپن سورس ۾ موجود آهن (اهي Habr تي هئا) مضمون هن موضوع تي) ۽ اسان جا فائنلسٽ هئا بور и آرام وارواسين هيٺ ڏنل ٻن ايپس جي مقابلي کي ڍڪينداسين، پر هاڻي لاءِ، اچو ته ڳالهايون ته اسان سڄي اسڪيم کي ڪيئن منظم ڪيو.

بيڪ اپ ٺاهڻ جو انتظام ڪرڻ

بورگ ۽ ريسٽڪ سٺا آهن، پر ٻنهي مان ڪنهن به پراڊڪٽ ۾ مرڪزي انتظامي نظام ناهي. انتظام ۽ ڪنٽرول لاءِ، اسان هڪ اوزار چونڊيو جيڪو اسان وٽ اڳ ۾ ئي موجود آهي ۽ اسان بغير اسان جي ڪم جو تصور به نٿا ڪري سگهون، جنهن ۾ آٽوميشن شامل آهي - مشهور CI/CD ٽول GitLab.

خيال هي آهي: گٽ ليب-رنر هر نوڊ تي نصب ٿيل آهي جيڪو نيڪسٽ ڪلائوڊ ڊيٽا محفوظ ڪري ٿو. رنر هڪ شيڊول ٿيل اسڪرپٽ هلائي ٿو جيڪو بيڪ اپ جي عمل جي نگراني ڪري ٿو، جيڪو پوءِ بورگ يا ريسٽڪ لانچ ڪري ٿو.

اسان کي ڇا مليو؟ ترقي تي موٽ، آسان تبديلي ڪنٽرول، ۽ غلطين جي صورت ۾ تفصيل.

هتي هتي GitHub تي اسان مختلف ڪمن لاءِ نموني اسڪرپٽ پوسٽ ڪيا، ۽ اسان انهن کي نه رڳو Nextcloud پر ٻين ڪيترين ئي خدمتن جي بيڪ اپ لاءِ استعمال ڪيو. جيڪڏهن توهان ان کي دستي طور تي ترتيب ڏيڻ نٿا چاهيو ته هڪ شيڊولر پڻ آهي (جيڪو اسان نٿا ڪريون)، ۽ .gitlab-ci.yml.

GitLab API هن وقت توهان کي CI/CD ٽائم آئوٽ تبديل ڪرڻ جي اجازت نٿو ڏئي، ۽ اهو ننڍو آهي. ان کي وڌايو وڃي، مثال طور، تائين 1d.

خوشقسمتيءَ سان، GitLab نه رڳو ڪمٽ تي، پر شيڊول تي پڻ نقل هلائي سگهي ٿو، جيڪو بلڪل اسان کي گهربل آهي.

هاڻي ريپر اسڪرپٽ بابت.

اسان هن اسڪرپٽ لاءِ هيٺيون شرطون مقرر ڪيون ٿا:

ان کي رنر طرفان ۽ دستي طور تي ڪنسول مان ساڳئي ڪارڪردگي سان لانچ ڪيو وڃي.
غلطي سنڀاليندڙن جي ضرورت آهي:
واپسي ڪوڊ.
لاگ ۾ هڪ اسٽرنگ ڳوليو. مثال طور، اسان لاءِ، هڪ غلطي هڪ پيغام ٿي سگهي ٿي جنهن کي پروگرام موتمار نه ٿو سمجهي.
پروسيسنگ جو وقت ختم ٿي ويو. عملدرآمد جو وقت مناسب هجڻ گهرجي.
اسان کي هڪ تمام تفصيلي لاگ جي ضرورت آهي. پر صرف ڪنهن غلطي جي صورت ۾.
شروعات کان اڳ ٽيسٽن جو هڪ سلسلو پڻ ڪيو ويندو آهي.
هتي ڪجھ ننڍيون سهولت خاصيتون آهن جيڪي اسان کي اسان جي سپورٽ جي عمل دوران مددگار لڳيون:
شروعاتي ۽ آخري وقت مقامي مشين جي سسٽم لاگ ۾ رڪارڊ ڪيا ويندا آهن. هي سسٽم جي غلطين کي بيڪ اپ سرگرمي سان ڳنڍڻ ۾ مدد ڪري ٿو.
جيڪڏهن ڪو غلطي لاگ آهي، ته ان جو هڪ حصو stdout ڏانهن آئوٽ پُٽ آهي، جڏهن ته سڄو لاگ هڪ الڳ فائل ۾ لکيو ويندو آهي. اهو CI ۾ غلطي کي جلدي ڏسڻ ۽ جيڪڏهن اها معمولي آهي ته ان جو جائزو وٺڻ آسان بڻائي ٿو.
ڊيبگ موڊ.

مڪمل لاگ گٽ ليب ۾ هڪ آرٽيفيڪٽ طور محفوظ ڪيو ويندو آهي؛ جيڪڏهن ڪا به غلطي نه هوندي آهي، ته لاگ ڊهي ويندو آهي. اسان اسڪرپٽ کي بيش ۾ لکي رهيا آهيون.

اسان اوپن سورس جي حوالي سان ڪنهن به تجويز يا تبصري جو استقبال ڪريون ٿا.

ڪيئن هن ڪم ڪندو

هڪ رنر جنهن ۾ بيش ايگزيڪيوٽر هوندو آهي، ان کي بيڪ اپ ڪيل نوڊ تي لانچ ڪيو ويندو آهي. هڪ CI/CD نوڪري شيڊولر استعمال ڪندي هڪ خاص ريپو ۾ لانچ ڪئي ويندي آهي. رنر هڪ اسڪرپٽ هلائيندو آهي، اهڙن ڪمن لاءِ هڪ يونيورسل ريپر، جيڪو بيڪ اپ ريپوزٽري، ماؤنٽ پوائنٽس، ۽ ڪنهن به ٻي گهربل شيءِ جي صحيحيت جي جانچ ڪندو آهي، پوءِ بيڪ اپ ڪندو آهي ۽ پراڻي بيڪ اپ کي صاف ڪندو آهي. مڪمل ٿيل بيڪ اپ S3 ڏانهن موڪليو ويندو آهي.

اسين هن طريقي سان ڪم ڪريون ٿا: اسين هڪ ٻاهرين فراهم ڪندڙ، AWS، يا روسي برابر استعمال ڪندا آهيون (اهو تيز آهي ۽ ڊيٽا روس کان ٻاهر نه ٿو نڪري). متبادل طور تي، اسين انهن مقصدن لاءِ ڪلائنٽ جي احاطي تي هڪ الڳ مينيو ڪلسٽر قائم ڪندا آهيون. اسين عام طور تي سيڪيورٽي سببن جي ڪري اهو ڪندا آهيون، جڏهن ڪلائنٽ بلڪل نٿو چاهي ته ڊيٽا سندن احاطي مان ٻاهر نڪري.

اسان SSH بيڪ اپ فيچر استعمال ڪرڻ جي خلاف فيصلو ڪيو. اهو سيڪيورٽي کي بهتر نٿو بڻائي، ۽ S3 فراهم ڪندڙ جون نيٽ ورڪ صلاحيتون اسان جي واحد SSH مشين کان تمام گهڻيون بهتر آهن.

توهان جي مقامي مشين کي هيڪرز کان بچائڻ لاءِ جيڪي S3 تي ڊيٽا ختم ڪري سگهن ٿا، ورزننگ کي فعال ڪرڻ ضروري آهي.
بيڪ اپ ڪندڙ هميشه بيڪ اپ کي انڪرپٽ ڪندو آهي.

بورگ ۾ ڪو به انڪرپشن موڊ ناهي. none، پر اسان ان کي فعال ڪرڻ جي سختي سان سفارش ڪريون ٿا. هن موڊ ۾، نه رڳو ڪو به انڪرپشن ناهي، پر جيڪو لکيو پيو وڃي ان جو چيڪسم به ڳڻيو نه ويندو آهي، مطلب ته سالميت صرف انڊيڪس استعمال ڪندي اڻ سڌي طرح تصديق ڪري سگهجي ٿي.

بيڪ اپ جي انڊيڪس ۽ مواد جي سالميت کي جانچڻ لاءِ هڪ الڳ شيڊولر استعمال ڪيو ويندو آهي. هي چيڪ سست ۽ وقت وٺندڙ آهي، تنهن ڪري اسان ان کي مهيني ۾ هڪ ڀيرو الڳ الڳ هلائيندا آهيون. ان ۾ ڪيترائي ڏينهن لڳي سگهن ٿا.

روسي ۾ Readme

مين فنڪشن

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 تنصيب لاءِ استعمال ٿي سگهي ٿو، جتي توهان ڊيٽابيس جو بيڪ اپ پڻ وٺي سگهو ٿا. نه رڳو هر شيءِ هڪ جاءِ تي آسان آهي، پر ڊيٽابيس جو مواد پڻ فائل جي مواد جي ويجهو آهي، ڇاڪاڻ ته وقت جو فرق گهٽ ۾ گهٽ آهي.

ريسٽڪ بمقابلہ بورگ

بورگ ۽ ريسٽڪ جي وچ ۾ مقابلو پڻ آهي. هتي حبر تي، ۽ اسان جو مقصد صرف ٻيو ٺاهڻ نه هو، پر اسان جو پنهنجو. اسان کي دلچسپي هئي ته اهو اسان جي ڊيٽا جي بنياد تي ڪيئن نظر ايندو، اسان جي وضاحتن کي ڏنو ويو. اسان اها معلومات فراهم ڪري رهيا آهيون.

اسان جا چونڊ معيار، اڳ ۾ ئي ذڪر ڪيل معيارن کان علاوه (ڊي ڊپليڪيشن، تيز بحالي، وغيره):

اڻپوري ڪم جي برداشت. ڪِل -9 لاءِ چيڪ ڪريو.
ڊسڪ تي سائيز.
وسيلن جون گهرجون (سي پي يو، ياداشت).
ذخيرو ٿيل بلاب جو سائز.
S3 سان ڪم ڪرڻ.
سالميت جي جانچ.

جاچ لاءِ، اسان هڪ ڪلائنٽ ورتو جنهن ۾ حقيقي ڊيٽا ۽ ڪل سائيز 1,6 ٽي بي هئي.
حالتون.

بورگ سڌو سنئون S3 سان ڪم نٿو ڪري سگهي، ۽ اسان ان کي فيوز ڊسڪ جي طور تي نصب ڪيو، ذريعي بيوقوفريسٽڪ ان کي S3 ڏانهن موڪليو.

گوفيز تمام تيز ۽ سٺو ڪم ڪري ٿو، ۽ ان سان گڏ اچي ٿو ڊسڪ ڪيش ماڊيول، جيڪو شين کي اڃا به وڌيڪ تيز ڪري ٿو. اهو اڃا تائين بيٽا ۾ آهي، ۽ سچ پڇو ته، اسان کي ٽيسٽ دوران ڊيٽا جي نقصان سان ڪجهه حادثا ٿيا آهن (ٻين ماڻهن جي). پر فائدو اهو آهي ته بيڪ اپ عمل کي پاڻ ۾ گهڻو پڙهڻ جي ضرورت ناهي، پر گهڻو ڪري لکڻ جي ضرورت آهي، تنهنڪري اسان صرف سالميت جي چڪاس دوران ڪيش استعمال ڪندا آهيون.

نيٽ ورڪ جي اثر کي گهٽائڻ لاءِ، اسان هڪ مقامي فراهم ڪندڙ، Yandex Cloud استعمال ڪيو.

مقابلي جي جاچ جا نتيجا.

ڪِل-9 بعد ۾ ٻيهر شروع ڪرڻ سان ٻئي ڪامياب ٿيا.
ڊسڪ تي سائيز. بورگ ڪمپريشن جي قابل آهي، تنهن ڪري نتيجا اميد مطابق آهن.

بيڪ اپ
ڪرائون سائيز واري

بور
562 جي بي

آرام وارو
628 جي بي

سي پي يو پاران
بورگ پاڻ ٿوري طاقت استعمال ڪري ٿو، جيتوڻيڪ ڊفالٽ ڪمپريشن سان، پر ان جو جائزو گوفيز جي عمل سان گڏ ڪيو وڃي. گڏجي، اهي برابر آهن، ساڳئي ٽيسٽ VM تي تقريباً 1,2 ڪور استعمال ڪن ٿا.
ياداشت. ريسٽڪ تقريبن 0,5 GB آهي، بورگ تقريبن 200 MB آهي. پر اهو سڀ ڪجهه سسٽم جي فائل ڪيش جي مقابلي ۾ غير اهم آهي. تنهن ڪري وڌيڪ ياداشت مختص ڪرڻ جي صلاح ڏني وئي آهي.
بلاب جي سائيز ۾ فرق حيرت انگيز هو.

بيڪ اپ
ڪرائون سائيز واري

بور
لڳ ڀڳ 500 ايم بي

آرام وارو
لڳ ڀڳ 5 ايم بي

ريسٽڪ ايس 3 سان تمام سٺو ڪم ڪري ٿو. بورگ گوفيز سان تمام سٺو ڪم ڪري ٿو، پر مون ڏٺو آهي ته ڪيش کي مڪمل طور تي فلش ڪرڻ لاءِ بيڪ اپ کان پوءِ ان ماؤنٽ ڪرڻ جي صلاح ڏني وئي آهي. ايس 3 جي هڪ خاصيت اها آهي ته نامڪمل چنڪس ڪڏهن به بڪيٽ ۾ نه موڪليا ويندا آهن، مطلب ته نامڪمل طور تي اپلوڊ ٿيل ڊيٽا اهم ڪرپشن جو سبب بڻجي سگهي ٿو.
ٻنهي صورتن ۾ سالميت جي چڪاس سٺي ڪم ڪري ٿي، پر رفتار ۾ خاص فرق آهي.
آرامده - 3,5 ڪلاڪ.
بورگ، 100GB SSD فائل ڪيش سان - 5 ڪلاڪجيڪڏهن ڊيٽا مقامي ڊسڪ تي واقع آهي ته تقريبن ساڳئي رفتار جو نتيجو ٿيندو.
بورگ ڪيشنگ کان سواءِ سڌو S3 مان پڙهي ٿو. 33 ڪلاڪ. تمام ڊگهو.

بنيادي ڳالهه اها آهي ته بورگ دٻائي سگهي ٿو ۽ ان ۾ وڏا بلب آهن، جنهن جي ڪري S3 ۾ اسٽوريج ۽ GET/PUT آپريشن سستا ٿي ويندا آهن. بهرحال، اهو وڌيڪ پيچيده ۽ سست تصديق جي قيمت تي اچي ٿو. بحالي جي رفتار جي حوالي سان، اسان ڪو به فرق محسوس نه ڪيو. ريسٽڪ کي بعد ۾ بيڪ اپ ڪرڻ ۾ ٿورو وڌيڪ وقت لڳندو آهي (پهرين کان پوءِ)، پر خاص طور تي نه.

چونڊ ۾ برادري جو قد گهٽ ۾ گهٽ اهم عنصر نه هو.

۽ اسان بورگ چونڊيو.

ڪمپريشن بابت ڪجھ لفظ

بورگ وٽ هڪ شاندار نئون ڪمپريشن الگورتھم، zstd آهي. ان جي ڪمپريشن معيار gzip کان وڌيڪ خراب ناهي، پر خاص طور تي تيز آهي. اهو رفتار ۾ پڻ ڊفالٽ lz4 سان مقابلو ڪري سگهجي ٿو.

مثال طور، هڪ MySQL ڊيٽابيس ڊمپ ساڳئي رفتار تي lz4 کان ٻه ڀيرا ڪمپريس ڪري ٿو. جڏهن ته، حقيقي دنيا جو ڊيٽا ڏيکاري ٿو ته Nextcloud نوڊ تي ڪمپريشن تناسب ۾ تمام گهٽ فرق آهي.

بورگ وٽ هڪ خاص ڪمپريشن موڊ آهي: جيڪڏهن ڪنهن فائل ۾ اينٽراپي وڌيڪ آهي، ته ڪو به ڪمپريشن لاڳو نه ڪيو ويندو آهي، جيڪو رفتار وڌائي ٿو. اهو تخليق دوران هڪ آپشن ذريعي فعال ڪيو ويندو آهي.
-C auto,zstd
zstd الگورتھم لاءِ
تنهنڪري هن آپشن سان، ڊفالٽ ڪمپريشن جي مقابلي ۾، اسان حاصل ڪيو
ترتيب وار 560GB ۽ 562GB. ياد ڏياريندڙ طور، مٿي ڏنل مثال مان غير دٻيل نتيجو 628GB آهي. 2GB جو فرق ٿورو حيران ڪندڙ هو، پر اسان بعد واري سان وڃڻ جو فيصلو ڪيو. 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/

اسان اينٽي وائرس سافٽ ويئر (پوسٽ فيڪٽم) سان فائلن کي اسڪين ڪرڻ لاءِ ساڳيو طريقو استعمال ڪندا آهيون. آخرڪار، استعمال ڪندڙ هر قسم جون شيون Nextcloud تي اپ لوڊ ڪندا آهن، ۽ هر ڪنهن وٽ اينٽي وائرس سافٽ ويئر نه هوندو آهي. اپلوڊ جي وقت فائلن کي اسڪين ڪرڻ ۾ تمام گهڻو وقت لڳندو آهي ۽ ڪاروبار ۾ رڪاوٽ پيدا ٿيندي آهي.

اسڪيليبلٽي مختلف نوڊس تي مختلف ٽيگ سان رنرز هلائڻ سان حاصل ڪئي ويندي آهي.
اسان جي نگراني هڪ ونڊو ۾ GitLab API ذريعي بيڪ اپ اسٽيٽس گڏ ڪري ٿي، مسئلن کي آساني سان سڃاڻپ ۽ مقامي بڻائي ٿي.

ٿڪل

نتيجي طور، اسان کي پڪ سان خبر آهي ته اسان بيڪ اپ ڪري رهيا آهيون، اسان جا بيڪ اپ صحيح آهن، ۽ انهن سان پيدا ٿيندڙ ڪنهن به مسئلي کي ڊيوٽي تي موجود منتظم طرفان جلدي ۽ آساني سان حل ڪيو ويندو آهي. tar.gz يا Bacula جي مقابلي ۾ بيڪ اپ تمام گهٽ جاءِ وٺندا آهن.

جو ذريعو: www.habr.com