څنګه GitLab تاسو سره د لوی NextCloud ذخیره کولو بیک اپ کې مرسته کوي

اې حبره!

نن ورځ زه غواړم په مختلف تشکیلاتو کې د Nextcloud ذخیره کولو څخه د لوی ډیټا بیک اپ اتومات کولو کې زموږ د تجربې په اړه وغږیږم. زه په مولنیا AK کې د خدماتو سټیشن په توګه کار کوم ، چیرې چې موږ د معلوماتي ټیکنالوژۍ سیسټمونو تنظیم کولو مدیریت کوو؛ Nextcloud د معلوماتو ذخیره کولو لپاره کارول کیږي. په شمول، د ویشل شوي جوړښت سره، د بې ځایه کیدو سره.

د تاسیساتو ځانګړتیاو څخه رامینځته شوي ستونزې دا دي چې ډیری ډیټا شتون لري. د Nextcloud لخوا چمتو شوي نسخه، بې ځایه، موضوعي دلایل، او نور ډیری نقلونه رامینځته کوي.

له تاریخ څخه دمخه

کله چې د Nextcloud اداره کول ، د مؤثره بیک اپ تنظیم کولو ستونزه رامینځته کیږي ، کوم چې باید کوډ شي ، ځکه چې ډاټا ارزښت لري.

موږ په خپل ځای کې یا د پیرودونکي په جلا ماشینونو کې د Nextcloud څخه د بیک اپ ذخیره کولو اختیارونه وړاندیز کوو ، کوم چې ادارې ته انعطاف وړ اتومات چلند ته اړتیا لري.

ډیری پیرودونکي شتون لري، ټول یې د مختلف ترتیباتو سره، او ټول په خپلو سایټونو کې او د خپلو ځانګړتیاو سره. دا یو معیاري تخنیک دی کله چې ټول سایټ ستاسو پورې اړه لري، او بیک اپ د تاجونو څخه جوړ شوي؛ دا ښه نه وي.

لومړی، راځئ چې د ان پټ ډاټا وګورو. موږ اړتیا لرو:

• د یو نوډ یا څو په شرایطو کې توزیع کول. د لویو تاسیساتو لپاره موږ مینیو د ذخیره کولو په توګه کاروو.
• د بیک اپ ترسره کولو سره د ستونزو په اړه ومومئ.
• تاسو اړتیا لرئ د خپلو پیرودونکو او / یا زموږ سره بیک اپ وساتئ.
• د ستونزو سره په چټکه او اسانۍ سره معامله وکړئ.
• پیرودونکي او تاسیسات له یو بل څخه ډیر توپیر لري - یووالی نشي ترلاسه کیدی.
• د بیا رغونې سرعت باید په دوه سناریو کې لږترلږه وي: بشپړ بیا رغونه (ناورین)، یو فولډر په غلطۍ سره له مینځه وړل شوی.
• د نقل کولو فعالیت ته اړتیا ده.

د بیک اپ اداره کولو ستونزې حل کولو لپاره ، موږ GitLab نصب کړ. نور جزئیات د ټکولو په واسطه.

البته، موږ لومړی نه یو چې دا ډول ستونزه حل کړو، مګر موږ ته داسې ښکاري چې زموږ عملي، سخته تجربه په زړه پورې وي او موږ یې شریکولو ته چمتو یو.

څرنګه چې زموږ شرکت د خلاصې سرچینې پالیسي لري، موږ د خلاصې سرچینې حل په لټه کې یو. په بدل کې، موږ خپل پرمختګونه شریکوو او پوسټ کوو. د مثال په توګه، په GitHub کې شتون لري د Nextcloud لپاره زموږ پلگ ان، کوم چې موږ پیرودونکو ته چمتو کوو ، د ناڅاپي یا قصدي حذف کیدو په صورت کې د معلوماتو امنیت ته وده ورکوي.

د بیک اپ وسیلې

موږ د بیک اپ جوړولو وسیلې په غوره کولو سره د حل میتودونو لپاره زموږ لټون پیل کړ.

منظم tar + gzip ښه کار نه کوي - ډاټا نقل شوي. یو زیاتوالی اکثرا ډیر لږ حقیقي بدلونونه لري، او ډیری ډاټا په یوه فایل کې تکرار کیږي.
بله ستونزه شتون لري - د توزیع شوي ډیټا ذخیره کولو بې ځایه کیدل. موږ مینیو کاروو او د دې ډاټا اساسا بې ځایه دي. یا تاسو باید پخپله د مینیو له لارې بیک اپ جوړ کړئ - دا پورته کړئ او د فایل سیسټم تر مینځ ټول سپیسرونه وکاروئ ، او لږ مهم ندي ، د ځینې بالټونو او میټا معلوماتو په اړه د هیریدو خطر شتون لري. یا د نقل کولو څخه کار واخلئ.

د نقل سره د بیک اپ وسیلې په خلاصې سرچینې کې شتون لري (په Habré کې شتون درلود مقالې د دې موضوع په اړه) او زموږ فائنلسټان وو بورګ и ریزیک. زموږ د دوه غوښتنلیکونو پرتله کول لاندې دي، مګر د اوس لپاره موږ به تاسو ته ووایو چې موږ څنګه ټول سکیم تنظیم کړ.

د بیک اپ اداره کول

Borg او Restic ښه دي، مګر هیڅ محصول د کنټرول مرکزي میکانیزم نلري. د مدیریت او کنټرول هدف لپاره، موږ یوه وسیله غوره کړه چې موږ دمخه پلي کړې، پرته له دې چې موږ نشو کولی خپل کار تصور کړو، په شمول د اتوماتیک - دا مشهور CI/CD - GitLab دی.

نظر په لاندې ډول دی: gitlab-runner په هر نوډ کې د Nextcloud ډیټا ذخیره کولو کې نصب شوی. رنر په مهالویش کې سکریپټ چلوي چې د بیک اپ پروسې څارنه کوي، او دا بورګ یا ریسټیک پیلوي.

موږ څه ترلاسه کړل؟ د اجرا کولو څخه فیډبیک، د بدلونونو په اړه مناسب کنټرول، د غلطۍ په صورت کې توضیحات.

دلته دلته په GitHub کې موږ د مختلف دندو لپاره د سکریپټ مثالونه پوسټ کړل ، او موږ یې نه یوازې د Nextcloud ، بلکه ډیری نورو خدماتو بیک اپ سره ضمیمه کړل. دلته مهالویش هم شتون لري که تاسو نه غواړئ دا په لاسي ډول تنظیم کړئ (او موږ یې نه غواړو) او gitlab-ci.yml

تر اوسه په ګیټلاب API کې د CI/CD مهال ویش بدلولو لپاره کومه لاره نشته، مګر دا کوچنی دی. دا باید زیاته شي، ووایه 1d.

GitLab، خوشبختانه، نه یوازې د ژمنې سره سم پیل کولی شي، مګر یوازې د مهال ویش سره سم، دا هغه څه دي چې موږ ورته اړتیا لرو.

اوس د ریپر سکریپټ په اړه.

موږ د دې سکریپټ لپاره لاندې شرایط ټاکو:

• دا باید د ورته فعالیت سره د کنسول څخه د رنر او لاس په واسطه دواړه په لاره واچول شي.
• باید د خطا سمبالونکي وي:
• بیرته کوډ.
• په لاګ کې د تار لټون وکړئ. د مثال په توګه، زموږ لپاره یوه تېروتنه ممکن یو پیغام وي چې برنامه وژونکي نه ګڼي.
• د پروسس وخت پای. د لیډ وخت باید مناسب وي.
• موږ خورا تفصيلي لاګ ته اړتیا لرو. مګر یوازې د یوې تېروتنې په صورت کې.
• د پیل کولو دمخه یو شمیر ازموینې هم ترسره کیږي.
• د اسانتیا لپاره کوچني بونس چې موږ د ملاتړ پروسې په جریان کې ګټور وموندل:
• پیل او پای د محلي ماشین په سیسلګ کې ثبت شوي. دا د سیسټم غلطیو او بیک اپ عملیاتو سره نښلولو کې مرسته کوي.
• د تېروتنې لاګ یوه برخه، که کوم وي، stdout ته محصول وي، ټوله لاګ په جلا فایل کې لیکل کیږي. دا اسانه ده چې سمدلاسه CI ته وګورو او تېروتنه و ارزوي که دا کوچنۍ وي.
• د ډیبګ کولو طریقې.

بشپړ لاګ په GitLab کې د هنري اثار په توګه خوندي شوی؛ که کومه تېروتنه شتون ونلري ، نو لاګ حذف شوی. موږ سکریپټ په باش کې لیکو.

موږ به خوښ یو چې د خلاصې سرچینې په اړه کوم وړاندیزونه او نظرونه په پام کې ونیسو - ښه راغلاست.

دا څنګه کار کوي؟

د باش اجرا کونکي سره یو رنر په بیک اپ نوډ کې پیل شوی. د مهالویش له مخې، دنده 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.
• په ډیسک کې اندازه.
• د سرچینو لپاره اړتیا (CPU، حافظه).
• د ذخیره شوي بلبونو اندازه.
• د S3 سره کار کول.
• د بشپړتیا چک کول.

د ازموینې لپاره ، موږ یو پیرودونکي د ریښتیني ډیټا او د 1,6 TB ټول اندازې سره واخیست.
شرایط.

بورګ نه پوهیږي چې څنګه د S3 سره مستقیم کار وکړي، او موږ ډیسک د فیوز په توګه نصب کړ، له لارې احمقان. ریسټیک دا پخپله S3 ته لیږلی.

Goofys خورا ګړندي او ښه کار کوي ، او شتون لري د ډیسک کیچ ماډل، کوم چې کار نور هم ګړندی کوي. دا د بیټا مرحله کې ده، او په ریښتیا سره، موږ د ازموینو (نورو) په جریان کې د معلوماتو له لاسه ورکولو سره ټکر شو. مګر اسانتیا دا ده چې د بیک اپ پروسیجر پخپله ډیر لوستلو ته اړتیا نلري ، مګر ډیری یې لیکلو ته اړتیا لري ، نو موږ یوازې د بشپړتیا چکونو پرمهال کیچ کاروو.

د شبکې د نفوذ کمولو لپاره، موږ یو محلي چمتو کونکي کارولي - Yandex Cloud.

د پرتله کولو ازموینې پایلې.

• Kill -9 د بل بیا پیل کولو سره دواړه بریالي وو.
• په ډیسک کې اندازه. بورګ کولی شي فشار راولي، نو پایلې لکه څنګه چې تمه کیږي.

بیک اپ
اندازه

بورګ
562Gb

ریزیک
628Gb

• د CPU لخوا
  بورګ پخپله لږ مصرف کوي، د ډیفالټ کمپریشن سره، مګر دا باید د ګوفس پروسې سره یوځای ارزول شي. په مجموع کې، دوی د پرتله کولو وړ دي او په ورته ازموینې مجازی ماشین کې شاوخوا 1,2 کور کاروي.
• حافظه. ریسټیک تقریبا 0,5GB دی، بورګ تقریبا 200MB دی. مګر دا د سیسټم فایل کیچ په پرتله خورا مهم دی. نو دا مشوره ورکول کیږي چې ډیر حافظه تخصیص کړئ.
• د بلب په اندازې کې توپیر خورا څرګند و.

بیک اپ
اندازه

بورګ
شاوخوا 500MB

ریزیک
شاوخوا 5MB

• د ریسټیک S3 سره تجربه خورا ښه ده. د ګوفس له لارې د بورګ سره کار کول کومه پوښتنه نه راپورته کوي ، مګر دا یادونه شوې چې د بیک اپ بشپړیدو وروسته د اماؤنټ کولو مشوره ورکول کیږي ترڅو کیچ په بشپړ ډول بیا تنظیم کړي. د S3 ځانګړتیا دا ده چې د لاندې پمپ شوي ټوټې به هیڅکله بالټ ته ونه لیږل شي، پدې معنی چې په بشپړ ډول ډک شوي ډاټا لوی زیان لامل کیږي.
• د بشپړتیا چک په دواړو حالتونو کې ښه کار کوي، مګر سرعت د پام وړ توپیر لري.
  آرامۍ د 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/

د ورته سکیم په کارولو سره ، موږ فایلونه د انټي ویروس سره چیک کوو (د حقیقت وروسته). په هرصورت ، کارونکي نیکټ کلاډ ته مختلف شیان اپلوډ کوي او هرڅوک انټي ویروس نلري. د اچولو په وخت کې د تفتیشونو ترسره کول ډیر وخت نیسي او په سوداګرۍ کې مداخله کوي.

د توزیع وړتیا په مختلف نوډونو کې د مختلف ټاګونو سره د منډو چلولو سره ترلاسه کیږي.
زموږ څارنه په یوه کړکۍ کې د GitLab API له لارې د بیک اپ حالتونه راټولوي؛ که اړتیا وي، ستونزې په اسانۍ سره لیدل کیږي او په اسانۍ سره ځایی شوي.

پایلې

د پایلې په توګه، موږ د ډاډ لپاره پوهیږو چې موږ بیک اپ جوړوو، چې زموږ بیک اپ معتبر دي، هغه ستونزې چې د دوی سره رامینځته کیږي لږ وخت نیسي او د وظیفې مدیر په کچه حل کیږي. بیک اپ د tar.gz یا Bacula په پرتله واقعیا لږ ځای نیسي.

سرچینه: www.habr.com