ڪيئن GitLab توهان جي مدد ڪري ٿي بيڪ اپ وڏي NextCloud اسٽوريج

اي حبر!

اڄ مان اسان جي تجربي بابت ڳالهائڻ چاهيان ٿو وڏي ڊيٽا جي بيڪ اپ کي خودڪار ڪرڻ ۾ Nextcloud اسٽوريج مان مختلف ترتيبن ۾. مان Molniya AK ۾ هڪ سروس اسٽيشن طور ڪم ڪريان ٿو، جتي اسان IT سسٽم جي ڪنفيگريشن مينيجمينٽ ڪندا آهيون؛ Nextcloud ڊيٽا اسٽوريج لاءِ استعمال ٿيندو آهي. جنهن ۾، ورهايل ڍانچي سان، بيڪاريءَ سان.

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

prehistory

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

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

اتي ڪيترائي ڪلائنٽ آھن، اھي سڀيئي مختلف ترتيبن سان، ۽ سڀ پنھنجين سائيٽن تي ۽ پنھنجين خصوصيتن سان. هي هڪ معياري ٽيڪنڪ آهي جڏهن سڄي سائيٽ توهان جي آهي، ۽ بيڪ اپ تاج مان ٺهيل آهن؛ اهو صحيح ناهي.

پهرين، اچو ته ان پٽ ڊيٽا کي ڏسو. اسانکي ضرورت آهي:

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

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

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

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

بيڪ اپ اوزار

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

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

نقل سان گڏ بيڪ اپ اوزار اوپن سورس ۾ موجود آهن (هابري تي موجود هئا مضمون هن موضوع جي باري ۾) ۽ اسان جا فائنل هئا بور и آرام وارو. اسان جي ٻن ايپليڪيشنن جو مقابلو ھيٺ ڏنل آھي، پر ھاڻي اسان توھان کي ٻڌائينداسين ته اسان پوري اسڪيم کي ڪيئن منظم ڪيو.

بيڪ اپ جو انتظام

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

اهو خيال هن ريت آهي: gitlab-runner هر نوڊ تي نصب ٿيل آهي Nextcloud ڊيٽا محفوظ ڪرڻ. رنر ھڪڙي شيڊول تي ھڪڙي اسڪرپٽ ھلائي ٿو جيڪو بيڪ اپ جي عمل کي مانيٽر ڪري ٿو، ۽ اھو Borg يا Restic لانچ ڪري ٿو.

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

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

اڃا تائين Gitlab API ۾ CI/CD ٽائم آئوٽ کي تبديل ڪرڻ جو ڪو طريقو ناهي، پر اهو ننڍڙو آهي. ان کي وڌائڻ جي ضرورت آهي، چوڻ 1d.

GitLab، خوشقسمتيء سان، لانچ ڪري سگھي ٿو نه رڳو ھڪڙي عزم جي مطابق، پر صرف ھڪڙي شيڊول جي مطابق، اھو اھو آھي جيڪو اسان کي گھربل آھي.

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

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

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

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

اسان اوپن سورس جي حوالي سان ڪنهن به تجويز ۽ رايا تي غور ڪرڻ ۾ خوش ٿينداسين - ڀليڪار.

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

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

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

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

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

بورگ وٽ هڪ اڻ ڳڻي موڊ آهي 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 سان سڌو ڪم ڪيئن ڪجي، ۽ اسان ڊسڪ کي فيوز جي طور تي نصب ڪيو. بيوقوف. Restic ان کي S3 پاڻ ڏانهن موڪليو.

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

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

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

• وڌيڪ ٻيهر شروع ڪرڻ سان مار -9 ٻئي ڪامياب هئا.
• ڊسڪ تي ماپ. بورگ کي دٻائي سگھي ٿو، تنهن ڪري نتيجا توقع وانگر آهن.

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

بور
562 جي بي

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

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

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

بور
اٽڪل 500MB

آرام وارو
اٽڪل 5MB

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

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

آخري نه پر گهٽ ۾ گهٽ پسند ۾ ڪميونٽي جي سائيز هئي.

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

compression جي باري ۾ چند لفظ

بورگ وٽ پنهنجي هٿيارن ۾ هڪ بهترين نئون کمپريشن الگورٿم آهي - 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/

ساڳئي اسڪيم کي استعمال ڪندي، اسان فائلن کي اينٽي وائرس سان چيڪ ڪريو (حقيقت کان پوء). آخرڪار، صارفين نيسٽ ڪلائوڊ تي مختلف شيون اپلوڊ ڪندا آهن ۽ هر ڪنهن وٽ اينٽي وائرس ناهي. وجھڻ وقت معائنو ڪرڻ تمام گھڻو وقت وٺندو آھي ۽ ڪاروبار ۾ مداخلت ڪندو آھي.

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

ٿڪل

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

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