ProHoster >> Blog >> Administrimi >> Si GitLab ndihmon në krijimin e backup-eve për depozita të mëdha në NextCloud

Si GitLab ndihmon në krijimin e backup-eve për depozita të mëdha në NextCloud

Përshëndetje, Habr!

Sot është fjala për përvojën tonë në automatizimin e kopjimit të të dhënave të mëdha në magazinat Nextcloud në konfiguracione të ndryshme. Unë punoj si CTO në "Mollia AK", ku merremi me menaxhimin e konfigurations të sistemeve IT, duke përdorur Nextcloud për ruajtjen e të dhënave. Kjo përfshin edhe një strukturë të shpërndarë me rezervim.

Problemet që burojnë nga veçoritë e instalimeve janë se ka shumë të dhëna. Versionimi që ofron Nextcloud, ruajtja, arsyet subjektive dhe çështje të tjera krijojnë shumë kopje të tepërta.

Pas historia

Gjatë administrimit të Nextcloud, ngushtohet problemi i organizimit të një backup-i efikas, i cili duhet të jetë patjetër i koduar, pasi të dhënat janë të çmuara.

Ne ofrojmë mundësi ruajtjeje të backup-it tek ne ose tek klienti në makinat e tij të veçanta nga Nextcloud, që kërkon një qasje automatizimi fleksibël në administrim.

Ka shumë klientë, të gjithë me konfiguracione të ndryshme, dhe secili në vendet e tij me veçoritë e tij. Këtu, metodologjia standarde kur e gjithë plataforma është e jotja dhe backup-et bëhen nga kroni, nuk përshtatet mirë.

Fillimisht, le të shohim të dhënat e hyrjes. Na nevojitet:

  • Shtimi i kapacitetit pĂ«r njĂ« nodĂ« ose mĂ« shumĂ«. PĂ«r instalime tĂ« mĂ«dha, ne pĂ«rdorim minio si depo.
  • TĂ« njoftoheni pĂ«r problemet me realizimin e backup-it.
  • Duhet tĂ« ruani backup nĂ« klientĂ« dhe/apo nĂ« ne.
  • TĂ« zgjidhni shpejt dhe lehtĂ«sisht problemet.
  • KlientĂ«t dhe instalimet dallojnĂ« shumĂ« nga njĂ«ra-tjetra — nuk arrijmĂ« dot njĂ« uniformitet.
  • ShpejtĂ«sia e rikuperimit duhet tĂ« jetĂ« minimale nĂ« dy skenarĂ«: rikuperim i plotĂ« (katastrofĂ«), njĂ« dosje — e fshirĂ« aksidentalisht.
  • Funksioni i dedupikimit Ă«shtĂ« i detyrueshĂ«m.

Si GitLab ndihmon në krijimin e backup-eve për depozita të mëdha në NextCloud

Për të menaxhuar backup-et, kemi integruar GitLab. Më shumë detaje më vonë.

Sigurisht, ne nuk jemi të parët që zgjidhim një problem të tillë, por besojmë se përvoja jonë praktike e fituar me mundim mund të jetë interesante dhe jemi të gatshëm ta ndajmë atë.

Duke qenë se në kompaninë tonë praktikohet politika e opensource, kërkuam një zgjidhje pikërisht me kod të hapur. Në të njëjtën mënyrë, ne ndajmë zhvillimet tona dhe i publikojmë. Për shembull, në GitHub ka pluginin tonë për Nextcloud, i cili e forcon ruajtjen e të dhënave në rast të fshirjes aksidentale ose qëllimisht.

Mjetet e backup-it

Kërkimi i metodave të zgjidhjes e filluam me zgjedhjen e një mjeti për krijimin e kopjeve rezervë.

Tar i zakonshĂ«m + gzip funksionon keq — tĂ« dhĂ«nat rinovohen. Inkrementi shpesh pĂ«rmban shumĂ« pak ndryshime nĂ« fakt, dhe pjesa mĂ« e madhe e tĂ« dhĂ«nave brenda njĂ« skedari pĂ«rsĂ«ritet.
Ka edhe njĂ« problem tjetĂ«r — tepricitet e ruajtjes sĂ« shpĂ«rndarĂ« tĂ« tĂ« dhĂ«nave. Ne pĂ«rdorim minio dhe tĂ« dhĂ«nat e tij janĂ« nĂ« thelb tepricĂ«. Ose duhej tĂ« bĂ«nim kopje rezervĂ« pĂ«rmes minio vetĂ« – duke e ngarkuar atĂ« dhe duke pĂ«rdorur tĂ« gjitha ndĂ«rmjetĂ«sit midis sistemit tĂ« skedarĂ«ve, dhe çka Ă«shtĂ« po aq e rĂ«ndĂ«sishme, ka rrezik tĂ« harrohet njĂ« pjesĂ« e baketeve dhe informacionit meta. Ose tĂ« pĂ«rdorim deduplication.

Mjetet për kopje rezervë me deduplication janë në open source (në Habr ishin artikullit në këtë temë) dhe finalistët tanë u bënë Borg dhe Restic. Më poshtë do të flasim për krahasimin e dy aplikacioneve, nd meanwhile do të tregojmë se si e organizuam gjithë skemën.

Menaxhimi i krijimit të kopjeve rezervë

Borg dhe Restic janĂ« tĂ« mira, por asnjĂ« nga produktet nuk ka njĂ« mekanizĂ«m tĂ« centralizuar menaxhimi. PĂ«r qĂ«llimin e menaxhimit dhe kontrollit, ne zgjodhĂ«m njĂ« mjet tĂ« cilin e kemi tashmĂ« tĂ« implementuar, pa tĂ« cilin nuk e imagjinonim punĂ«n tonĂ«, pĂ«rfshirĂ« automatizimin — Ă«shtĂ« CI/CD i njohur – GitLab.

Ideja është si më poshtë: në çdo nod që ruan të dhënat e Nextcloud vendoset gitlab-runner. Runner-i ekzekuton me një orar një skript që monitoron procesin e backup-it, dhe ai aktivizon Borg ose Restic.

ÇfarĂ« morĂ«m? Kthim informacioni nga ekzekutimi, kontroll i lehtĂ« mbi ndryshimet, detaje nĂ« rast gabimi.

Këtu është këtu në GitHub ne kemi publikuar shembuj të skripteve për detyra të ndryshme, dhe ne përfundimisht e lidhëm atë me backup-in jo vetëm të Nextcloud, por edhe të shumë shërbimeve të tjera. Po ashtu, aty është edhe planifikuesi, nëse nuk e doni ta konfigurooni me dorë (dhe ne nuk e duam) dhe .gitlab-ci.yml

Në API-në e GitLab-it, fatmirësisht, nuk ka mundësi për të ndryshuar kohën e pritjes CI/CD, dhe ajo është e vogël. Duhet ta rrisim, le të themi deri në 1d.

GitLab, fatmirësisht, mund të aktivizohet jo vetëm me commit, por edhe në një orar, kjo është pikërisht ajo që na nevojitet.

Tani për skriptin e mbështjellës.

Ne vendosëm këto kushte për këtë skript:

  • Duhet tĂ« ekzekutohet si nga runner-i, ashtu edhe manualisht nga konsola me funksionalitet tĂ« njĂ«jtĂ«.
  • PĂ«rveç kĂ«saj, duhet tĂ« ketĂ« trajtues gabimesh:
  • kodin e kthimit.
  • kĂ«rkimi i njĂ« linje nĂ« log. PĂ«r shembull, pĂ«r ne, njĂ« mesazh qĂ« programi nuk e konsideron fatal mund tĂ« jetĂ« njĂ« gabim.
  • Trajtimi i timeout. Koha e ekzekutimit duhet tĂ« jetĂ« e arsyeshme.
  • Na nevojitet njĂ« log shumĂ« mĂ« i detajuar. Por vetĂ«m nĂ« rast tĂ« njĂ« gabimi.
  • Po ashtu, kryhen njĂ« sĂ«rĂ« testesh para fillimit.
  • NjĂ« disa shtesa tĂ« vogla pĂ«r lehtĂ«sinĂ«, tĂ« cilat i kemi gjetur tĂ« dobishme gjatĂ« mbĂ«shtetjes:
  • Fillimi dhe pĂ«rfundimi regjistrohen nĂ« skedarin e sistemit tĂ« makinĂ«s lokale. Kjo ndihmon pĂ«r tĂ« lidhur gabimet e sistemit me operimin e backup-it.
  • NjĂ« pjesĂ« e log-Ă«ve tĂ« gabimeve, kur ato ekzistojnĂ«, jepet nĂ« stdout, e gjithĂ« log-u shkruhet nĂ« njĂ« skedar tĂ« veçantĂ«. E lehtĂ« pĂ«r tĂ« parĂ« menjĂ«herĂ« nĂ« CI dhe pĂ«r tĂ« vlerĂ«suar gabimin nĂ«se Ă«shtĂ« triviale.
  • Modet pĂ«r debagim.

Log-u i plotë ruhet si një artefakt në GitLab, nëse nuk ka gabime, atëherë log-u fshihet. Skripti shkruhet në bash.

Çdo propozim dhe vĂ«rejtje mbi open-source do tĂ« jemi tĂ« lumtur t'i shqyrtojmĂ« - mirĂ«seerdhĂ«t.

Si funksionon

Një runner me ekzekutorin bash niset në nodën e backup-it. Në planifikuesin në një rep të veçantë niset një punë CI/CD. Runner-i e nis skriptin si një mbulesë universale për këto detyra, në të zhvillohen kontrolli i vlefshmërisë së rep-it të backup-it, pikave të montimit dhe gjithçkaje që duam, pastaj realizohet backup-i dhe pastrimi i të vjetrave. Backup-i i gatshëm dërgohet në S3.

Ne punojmë sipas kësaj skeme - është një ofrues i jashtëm AWS ose një analoge ruse (është më e shpejtë dhe të dhënat nuk largohen nga RF). Ose i vendosim klientit një klaster të veçantë minio në hapësirën e tij për këto qëllime. Në përgjithësi, e bëjmë këtë për arsye sigurie, kur klienti nuk dëshiron aspak që të dhënat të dalin nga konturi i tij.

Ne nuk e përdorim veçorinë e dërgimit të backup-it përmes ssh. Kjo nuk shton siguri, dhe kapacitetet rrjetore të ofruesit S3 janë shumë më të larta se sa një makinë tonë ssh.

Për të mbrojtur nga hakerët në makinë lokale - pasi ai mund të fshijë të dhënat në S3, është domosdoshmërisht të aktivizoni versionimin.
Backup-i gjithmonë e enkripton backup-in.

Borg ka një mod të paedukuar none, por ne kategorikisht nuk e rekomandojmë aktivizimin e tij. Në këtë mod nuk do të ketë vetëm enkriptim, por as nuk llogaritet checksum-i i asaj që shkruhet, kështu që është e mundur të kontrolloni integritetin vetëm në mënyrë indirekte, nëpërmjet indekseve.

Kontrolli i backup-eve për integritetin e indekseve dhe përmbajtjes bëhet përmes një programatori të veçantë. Kontrolli ndodh ngadalë dhe gjatë, prandaj ne e aktivizojmë atë veçmas një herë në muaj. Mund të zgjasë disa ditë.

Lexo në shqip

Funksionet kryesore

  • prepare pĂ«rgatitja
  • testcheck kontrolli i gatishmĂ«risĂ«
  • komandĂ« e parĂ« komanda kryesore
  • forcepostscript funksioni qĂ« ekzekutohet nĂ« fund ose nĂ« rast gabimi. PĂ«rdoret pĂ«r tĂ« çmontuar ndarjen.

Funksionet e shërbimit

  • cleanup regjistrojmĂ« gabimet ose fshijmĂ« skedarin e log.
  • kontrollilog analizojmĂ« logun pĂ«r tĂ« gjetur stringun me gabim.
  • ret menaxher i daljes.
  • kontrollit tĂ« kohĂ«s kontrolli pĂ«r kohĂ«zgjatjen.

Mjedisi

  • VERBOSE=1 shfaqim gabimet nĂ« ekran menjĂ«herĂ« (stdout).
  • SAVELOGSONSUCCES=1 ruajmĂ« logun kur jemi tĂ« suksesshĂ«m.
  • INIT_REPO_IF_NOT_EXIST=1 KrijojmĂ« repository nĂ«se nuk ka pasur. NĂ« parazgjedhje Ă«shtĂ« e fikur.
  • KOHA koha maksimale pĂ«r operacionin kryesor. Mund ta pĂ«rcaktoni si ‘m’, ‘h’ ose ‘d’ nĂ« fund.

Rezi i ruajtjes së kopjeve të vjetra. Në parazgjedhje:

  • MBYLL_DITORE=7
  • MBYLL_JAVORE=4
  • MBYLL_MUAJORE=6

Variablat brenda skriptit

  • ERROR_STRING — string pĂ«r kontrollin nĂ« log pĂ«r gabim.
  • EXTRACT_ERROR_STRING — shprehje pĂ«r tĂ« shfaqur stringun nĂ« rast gabimi.
  • KILL_TIMEOUT_SIGNAL — sinjali pĂ«r tĂ« vrarĂ« nĂ«se ka kaluar koha.
  • TAIL — sa shumĂ« stringje me gabime nĂ« ekran.
  • COLORMSG — ngjyra e mesazhit (default e verdhĂ«).

Skedari i quajtur wordpress, ka funksionin se bën backup të bazës mysql. Kështu mund të përdoret për instalime të përkohshme të Nexcloud, ku gjithashtu mund të bëhet backup i bazës. Lehtësia nuk është vetëm në faktin se gjithçka është në një vend, por edhe përmbajtja e bazës është e afërt me përmbajtjen e skedarëve, pasi ndryshimi në kohë është minimal.

Restic vs Borg

Krahasimet midis Borg dhe Restic janë gjithashtu këtu në Habr, dhe ne nuk e patëm qëllim të bënim thjesht një tjetër, por tonin tonë. Ishte e rëndësishme për ne se si do të dukej në të dhënat tona, me specifikat tona. Ne i paraqesim ato.

Kriteret tona përzgjedhës, përveç atyre të përmendura më parë (deduplication, rikuperim i shpejtë, etj.):

  • QĂ«ndrueshmĂ«ria ndaj punĂ«s sĂ« papĂ«rfunduar. Kontrolli nĂ« kill -9.
  • MadhĂ«sia nĂ« disk.
  • KĂ«rkesat pĂ«r resurse (CPU, memorie).
  • MadhĂ«sia e blob-eve tĂ« ruajtura.
  • Puna me S3.
  • Kontrolli i integritetit.

Për testim, morëm një klient me të dhëna reale dhe një madhësi totale prej 1.6TB.
Kushtet.

Borg nuk di të punojë drejtpërdrejt me S3, dhe ne e montuam si një disk fuse, përmes goofys. Restic e dërgonte drejtpërdrejt në S3.

Goofys punon shumë shpejt dhe mirë, dhe ka një modul të caches disk, që e acceleron edhe më shumë funksionimin. Ai është në fazën beta dhe, për ta pranuar, kemi pasur rënie me humbje të dhënash në testet (të tjera). Por e mira është se vetë procedura e backup-it nuk kërkon lexim të madh, kryesisht shkrim, ndaj ne përdorim vetëm cache gjatë verifikimit të integritetit.

Për të reduktuar ndikimin e rrjetit, kemi përdorur një ofrues lokal - Yandex Cloud.

Rezultatet e testeve të krahasimit.

  • Kill -9 me rinisjen e mĂ«tejshme, tĂ« dyja kaluan me sukses.
  • MadhĂ«sia nĂ« disk. Borg mund tĂ« kompresojĂ«, prandaj rezultatet janĂ« tĂ« pritshme.

Backuper
Madhësia

Borg
562Gb

Restic
628Gb

  • PĂ«r CPU
    Borg vetë konsumon pak, me kompresimin default, por duhet të vlerësohet së bashku me procesin goofys. Në tërësi janë krahasues dhe ushqejnë rreth 1,2 bërthamë në të njëjtën maqinë virtuale për testim.
  • Memoria. Restic pĂ«rafĂ«rsisht 0,5Gb, Borg rreth 200Mb. Por kjo Ă«shtĂ« e parĂ«ndĂ«sishme krahasuar me cache-in e skedarĂ«ve tĂ« sistemit. Pra, Ă«shtĂ« e dĂ«shirueshme tĂ« ndahen mĂ« shumĂ« memorje.
  • Differenca nĂ« madhĂ«sinĂ« e blob-ve u tregua e jashtĂ«zakonshme.

Backuper
Madhësia

Borg
rreth 500Mb

Restic
rreth 5Mb

  • Puna me S3 nga Restic Ă«shtĂ« e shkĂ«lqyer. Puna e Borg-it pĂ«rmes goofys nuk ka probleme, por Ă«shtĂ« vĂ«nĂ« re se Ă«shtĂ« e dĂ«shirueshme qĂ« pas pĂ«rfundimit tĂ« kopjimit tĂ« bĂ«het umount pĂ«r tĂ« resetuar plotĂ«sisht cache-nĂ«. Karakteristika e punĂ«s me S3 Ă«shtĂ« se copat e pamjaftueshme nuk do tĂ« dĂ«rgohen kurrĂ« nĂ« bucket, qĂ« do tĂ« thotĂ« se tĂ« dhĂ«nat e padĂ«rguara plotĂ«sisht çojnĂ« nĂ« dĂ«mtime tĂ« mĂ«dha.
  • Kontrolli i integritetit funksionon mirĂ« nĂ« tĂ« dyja rastet, por shpejtĂ«sia ndryshon ndjeshĂ«m.
    Restic – 3.5 orĂ«.
    Borg, me cache skedash 100GB SSD – 5 orĂ«.Rreth njĂ« rezultat tĂ« ngjashĂ«m pĂ«r shpejtĂ«si nĂ«se tĂ« dhĂ«nat ndodhen nĂ« diskun lokal.
    Borg lexon direkt nga S3 pa cache 33 orë. E tmerrshme e gjatë.

NĂ« pĂ«rfundim, Borg di tĂ« comprimojĂ« dhe ka blob-e mĂ« tĂ« mĂ«dha — qĂ« e bĂ«n ruajtjen dhe operacionet GET/PUT nĂ« S3 mĂ« tĂ« lira. Por pĂ«r kĂ«tĂ« duhen paguar kontrolli mĂ« i komplikuar dhe mĂ« i ngadalshĂ«m. Sa i pĂ«rket shpejtĂ«sisĂ« sĂ« rikuperimit — nuk kemi vĂ«nĂ« re ndonjĂ« ndryshim. Kopjimet e mĂ«passhme (pas tĂ« parĂ«s) restic i bĂ«n disi mĂ« gjatĂ«, por jo ndjeshĂ«m.

Pesha e komunitetit nuk ishte në vend të fundit në zgjedhje.

Dhe ne zgjodhëm borg.

Disa fjalë në lidhje me kompresimin

Borg ka një algoritëm të mrekullueshëm kompresimi të ri - zstd. Në cilësinë e kompresimit nuk është më i keq se gzip, por është ndjeshëm më i shpejtë. Dhe është krahasues në shpejtësi me lz4-në e paracaktuar.

Për shembull, një dump i bazës MySQL comprimon rreth dy herë më mirë se lz4 me të njëjtën shpejtësi. Megjithatë, përvoja me të dhëna reale tregon se ka një ndryshim shumë të vogël në degëzimin e nodit Nextcloud.

Në Borg ka një modifikim bonus të kompresimit - nëse skedari ka entropi të lartë, kompresimi nuk aplikohet fare, gjë që rrit shpejtësinë e funksionimit. Aktivizohet me opsionin gjatë krijimit.
-C auto,zstd
për algoritmin zstd.
Tani, me këtë opsion, në krahasim me kompresimin e paracaktuar, ne morëm
560Gb dhe 562Gb përkatësisht. Të dhënat nga shembulli më sipër, kujtoj, pa kompresim rezultati ishte 628Gb. Rezultati me diferencën prej 2Gb na befasoi pak, por vendosëm që të zgjidhim gjithsesi auto,zstd..

Metodika e verifikimit të backup-it.

Përmes planifikuesit, një virtualizim nis direkt te ofruesi ose te klienti, gjë që ul ndjeshëm ngarkesën rrjetore. Të paktën është më e lirë se sa ta ngresh vetë dhe të ushqesh trafik.

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/

Me të njëjtën skemë ne kontrollojmë skedarët me antivirus (post faktum). Përdoruesit ngarkojnë të ndryshme në Nextcloud dhe jo të gjithë kanë antivirus. Të kryesh verifikimin në momentin e ngarkesës merr shumë kohë dhe pengon biznesin.

Mundësia për shkallëzim arrihet duke nisur runner-a në node të ndryshme me etiketa të ndryshme.
Në monitorimin tonë mblidhen statuset e backup-eve përmes API-së së GitLab në një dritare, dhe në rast nevoja problemet njihen lehtësisht dhe po ashtu lokalizohen.

PĂ«rfundimi

Si përfundim, ne e dimë saktësisht që bëjmë backup-e, që backup-et tona janë valide, problemet që lidhen me to kërkojnë pak kohë dhe zgjidhen në nivelin e administratorit të shërbimit. Backup-et realisht marrin pak hapësirë në krahasim me tar.gz ose Bacula.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster