🥇Si ju ndihmon GitLab të bëni kopje rezervë të hapësirave të mëdha të ruajtjes NextCloud

Hej Habr!

Sot dua të flas për përvojën tonë në automatizimin e kopjimit të të dhënave të mëdha nga depozitat Nextcloud në konfigurime të ndryshme. Unë punoj si stacion shërbimi në Molniya AK, ku bëjmë menaxhimin e konfigurimit të sistemeve të IT; Nextcloud përdoret për ruajtjen e të dhënave. Përfshirë, me strukturë të shpërndarë, me tepricë.

Problemet që dalin nga veçoritë e instalimeve janë se ka shumë të dhëna. Versionimi i ofruar nga Nextcloud, teprica, arsyet subjektive dhe më shumë krijon shumë dublikatë.

parahistorinë

Kur administroni Nextcloud, lind problemi i organizimit të një kopje rezervë efektive, e cila duhet të kodohet, pasi të dhënat janë të vlefshme.

Ne ofrojmë opsione për ruajtjen e kopjeve rezervë në vendin tonë ose te klienti në makina të veçanta nga Nextcloud, gjë që kërkon një qasje fleksibël të automatizuar në administrim.

Ka shumë klientë, të gjithë me konfigurime të ndryshme, dhe të gjithë në faqet e tyre dhe me karakteristikat e tyre. Kjo është një teknikë standarde kur i gjithë faqja ju përket juve, dhe kopjet rezervë bëhen nga kurora; nuk përshtatet mirë.

Së pari, le të shohim të dhënat hyrëse. Na duhen:

Shkallueshmëria për sa i përket një ose disa nyjeve. Për instalime të mëdha ne përdorim minio si ruajtje.
Mësoni për problemet me kryerjen e kopjeve rezervë.
Ju duhet të mbani një kopje rezervë me klientët tuaj dhe/ose me ne.
Përballuni me problemet shpejt dhe me lehtësi.
Klientët dhe instalimet janë shumë të ndryshme nga njëri-tjetri - uniformiteti nuk mund të arrihet.
Shpejtësia e rikuperimit duhet të jetë minimale në dy skenarë: rikuperim i plotë (katastrofë), një dosje e fshirë gabimisht.
Kërkohet funksioni i dedublimit.

Për të zgjidhur problemin e menaxhimit të kopjeve rezervë, ne instaluam GitLab. Më shumë detaje nga trajtimi.

Sigurisht, nuk jemi të parët që zgjidhim një problem të tillë, por na duket se përvoja jonë praktike, e fituar me vështirësi mund të jetë interesante dhe ne jemi gati ta ndajmë atë.

Meqenëse kompania jonë ka një politikë me burim të hapur, ne po kërkonim një zgjidhje me burim të hapur. Nga ana tjetër, ne ndajmë zhvillimet tona dhe i postojmë ato. Për shembull, në GitHub ekziston shtojca jonë për Nextcloud, të cilat ne u ofrojmë klientëve, duke rritur sigurinë e të dhënave në rast të fshirjes aksidentale ose të qëllimshme.

Mjetet rezervë

Ne filluam kërkimin tonë për metodat e zgjidhjes duke zgjedhur një mjet për krijimin e kopjeve rezervë.

Tar + gzip i rregullt nuk funksionon mirë - të dhënat janë të dyfishuara. Një rritje shpesh përmban shumë pak ndryshime aktuale dhe shumë nga të dhënat brenda një skedari të vetëm përsëriten.
Ekziston një problem tjetër - teprica e ruajtjes së të dhënave të shpërndara. Ne përdorim minio dhe të dhënat e tij janë në thelb të tepërta. Ose ju është dashur të bëni një kopje rezervë përmes vetë minio - ngarkoni atë dhe përdorni të gjithë ndarësit midis sistemit të skedarëve, dhe, jo më pak e rëndësishme, ekziston rreziku që të harroni disa nga kova dhe meta-informacione. Ose përdorni deduplication.

Mjetet rezervë me dyfishim janë të disponueshme në burim të hapur (në Habré kishte Artikull në lidhje me këtë temë) dhe finalistët tanë ishin Borg и Vendas. Krahasimi ynë i dy aplikacioneve është më poshtë, por tani për tani do t'ju tregojmë se si e organizuam të gjithë skemën.

Menaxhimi i kopjeve rezervë

Borg dhe Restic janë të mira, por asnjë produkt nuk ka një mekanizëm të centralizuar të kontrollit. Për qëllime të menaxhimit dhe kontrollit, ne zgjodhëm një mjet që tashmë e kemi implementuar, pa të cilin nuk mund ta imagjinojmë punën tonë, përfshirë automatizimin - ky është CI/CD i njohur - GitLab.

Ideja është si më poshtë: gitlab-runner është instaluar në çdo nyje që ruan të dhënat e Nextcloud. Vrapuesi ekzekuton një skript në një plan që monitoron procesin e rezervimit dhe lëshon Borg ose Restic.

Çfarë morëm? Reagime nga ekzekutimi, kontroll i përshtatshëm mbi ndryshimet, detaje në rast gabimi.

Këtu këtu në GitHub ne postuam shembuj të skriptit për detyra të ndryshme dhe përfunduam duke e bashkangjitur atë në kopjen rezervë jo vetëm të Nextcloud, por edhe të shumë shërbimeve të tjera. Ekziston edhe një programues atje nëse nuk dëshironi ta konfiguroni manualisht (dhe ne nuk duam) dhe .gitlab-ci.yml

Nuk ka ende asnjë mënyrë për të ndryshuar afatin CI/CD në Gitlab API, por është i vogël. Duhet të rritet, thuaj 1d.

GitLab, për fat të mirë, mund të nisë jo vetëm sipas një angazhimi, por vetëm sipas një plani, kjo është pikërisht ajo që na nevojitet.

Tani në lidhje me skenarin e mbështjellësit.

Ne vendosëm kushtet e mëposhtme për këtë skript:

Duhet të lëshohet si nga vrapuesi ashtu edhe me dorë nga tastiera me të njëjtin funksionalitet.
Duhet të ketë mbajtës të gabimeve:
kodin e kthimit.
kërkoni për një varg në regjistër. Për shembull, për ne një gabim mund të jetë një mesazh që programi nuk e konsideron fatale.
Kohëzgjatja e përpunimit. Kohëzgjatja duhet të jetë e arsyeshme.
Ne kemi nevojë për një regjistër shumë të detajuar. Por vetëm në rast të një gabimi.
Para fillimit kryhen gjithashtu një sërë testesh.
Shpërblime të vogla për lehtësi që na dolën të dobishme gjatë procesit të mbështetjes:
Fillimi dhe mbarimi regjistrohen në sislogun e makinës lokale. Kjo ndihmon për të lidhur gabimet e sistemit dhe funksionimin e rezervimit.
Një pjesë e regjistrit të gabimeve, nëse ka, del në stdout, i gjithë regjistri shkruhet në një skedar të veçantë. Është e përshtatshme që menjëherë të shikoni CI dhe të vlerësoni gabimin nëse është i parëndësishëm.
Mënyrat e korrigjimit.

Regjistri i plotë ruhet si një objekt në GitLab; nëse nuk ka gabim, regjistri fshihet. Ne e shkruajmë skenarin në bash.

Ne do të jemi të lumtur të shqyrtojmë çdo sugjerim dhe koment në lidhje me burimin e hapur - mirëpritur.

Si punon kjo

Një vrapues me një ekzekutues Bash lëshohet në nyjen rezervë. Sipas planifikuesit, puna CI/CD niset në një rrepë të veçantë. Runner lëshon një skript universal mbështjellës për detyra të tilla, kontrollon vlefshmërinë e depove rezervë, pikat e montimit dhe gjithçka që duam, më pas krijon kopje rezervë dhe pastron të vjetrën. Vetë rezervimi i përfunduar dërgohet në S3.

Ne punojmë sipas kësaj skeme - është një ofrues i jashtëm AWS ose një ekuivalent rus (është më i shpejtë dhe të dhënat nuk largohen nga Federata Ruse). Ose ne instalojmë një grup të veçantë minio për klientin në faqen e tij për këto qëllime. Ne zakonisht e bëjmë këtë për arsye sigurie, kur klienti nuk dëshiron që të dhënat të largohen fare nga qarku i tyre.

Ne nuk kemi përdorur veçorinë e dërgimit të kopjeve rezervë përmes ssh. Kjo nuk shton sigurinë dhe aftësitë e rrjetit të ofruesit S3 janë shumë më të larta se makina jonë e vetme ssh.

Për të mbrojtur kompjuterin tuaj lokal nga një haker, pasi ai mund të fshijë të dhënat në S3, duhet të aktivizoni versionin.
Rezervimi gjithmonë kodon kopjen rezervë.

Borg ka një modalitet të pakriptuar none, por ne nuk rekomandojmë fuqimisht ta aktivizoni. Në këtë mënyrë, jo vetëm që nuk do të ketë enkriptim, por kontrolli i asaj që shkruhet nuk llogaritet, që do të thotë se integriteti mund të kontrollohet vetëm në mënyrë indirekte, duke përdorur indekse.

Një planifikues i veçantë kontrollon kopjet rezervë për integritetin e indekseve dhe përmbajtjes. Kontrolli është i ngadaltë dhe i gjatë, kështu që ne e kryejmë atë veçmas një herë në muaj. Mund të duhen disa ditë.

Më lexoni në Rusisht

Funksionet kryesore

prepare stërvitje
testcheck kontroll gatishmërie
maincommand ekipi kryesor
forcepostscript një funksion që ekzekutohet në fund ose me gabim. Ne e përdorim atë për të çmontuar ndarjen.

Funksionet e shërbimit

cleanup ne regjistrojmë gabime ose fshijmë skedarin log.
checklog analizoni regjistrin për shfaqjen e një rreshti me një gabim.
ret mbajtës i daljes.
checktimeout kontrolloni për kohë.

mjedis

VERBOSE=1 Ne shfaqim gabimet në ekran menjëherë (stdout).
SAVELOGSONSUCCES=1 ruani regjistrin pas suksesit.
INIT_REPO_IF_NOT_EXIST=1 Krijoni një depo nëse nuk ekziston. Çaktivizuar si parazgjedhje.
TIMEOUT koha maksimale për operacionin kryesor. Mund ta vendosni si 'm', 'h' ose 'd' në fund.

Modaliteti i ruajtjes për kopjet e vjetra. E parazgjedhur:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

Variablat brenda skriptit

ERROR_STRING — varg për regjistrimin e regjistrimit për gabim.
EXTRACT_ERROR_STRING - shprehje për vargun e shfaqjes nëse është gabim.
KILL_TIMEOUT_SIGNAL - sinjal për vrasje nëse skadon.
TAIL - sa vargje me gabime në ekran.
COLORMSG — ngjyra e mesazhit (e verdha e parazgjedhur).

Ai skript, i cili quhet wordpress, ka një emër të kushtëzuar, mashtrimi i tij është se ai gjithashtu rezervon bazën e të dhënave mysql. Kjo do të thotë se mund të përdoret për instalimet e Nexcloud me një nyje, ku gjithashtu mund të kopjoni bazën e të dhënave. Komoditeti nuk është vetëm që gjithçka është në një vend, por edhe përmbajtja e bazës së të dhënave është afër përmbajtjes së skedarëve, pasi diferenca kohore është minimale.

Restic vs Borg

Ka edhe krahasime midis Borg dhe Restic këtu në Habré, dhe ne nuk kishim për detyrë të bënim vetëm një tjetër, por tonën. Ishte e rëndësishme për ne se si do të dukej në të dhënat tona, me specifikat tona. Ne i sjellim ato.

Kriteret tona të përzgjedhjes, përveç atyre të përmendura tashmë (deduplikimi, rikuperimi i shpejtë, etj.):

Rezistenca ndaj punës së papërfunduar. Kontrollo për vrasje -9.
Madhësia në disk.
Kërkesa për burime (CPU, memorie).
Madhësia e njollave 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,6 TB.
Kushtet

Borg nuk di të punojë drejtpërdrejt me S3, dhe ne e montuam diskun si siguresë, nëpërmjet budallenj. Restic ia dërgoi vetë S3.

Goofys funksionon shumë shpejt dhe mirë, dhe ka moduli i cache-it të diskut, gjë që e shpejton edhe më shumë punën. Është në fazën beta dhe, sinqerisht, ne u rrëzuam me humbje të të dhënave gjatë testeve (të tjera). Por komoditeti është se vetë procedura e kopjimit nuk kërkon shumë lexim, por kryesisht shkrim, kështu që ne përdorim cache vetëm gjatë kontrolleve të integritetit.

Për të zvogëluar ndikimin e rrjetit, ne përdorëm një ofrues lokal - Yandex Cloud.

Krahasimi i rezultateve të testimit.

Kill -9 me një rifillim të mëtejshëm ishin të dy të suksesshëm.
Madhësia në disk. Borg mund të ngjesh, kështu që rezultatet janë siç priten.

Rezervues
Размер

Borg
562Gb

Vendas
628Gb

Nga CPU
Vetë Borg konsumon pak, me kompresim të paracaktuar, por duhet të vlerësohet së bashku me procesin budalla. Në total, ato janë të krahasueshme dhe përdorin rreth 1,2 bërthama në të njëjtën makinë virtuale testuese.
Kujtesa. Restic është afërsisht 0,5 GB, Borg është afërsisht 200 MB. Por kjo është e gjitha e parëndësishme në krahasim me cache-in e skedarëve të sistemit. Kështu që këshillohet të ndani më shumë memorie.
Dallimi në madhësinë e njollave ishte i habitshëm.

Rezervues
Размер

Borg
rreth 500 MB

Vendas
rreth 5 MB

Përvoja me S3 të Restic është e shkëlqyer. Puna me Borg përmes goofys nuk ngre asnjë pyetje, por është vërejtur se këshillohet të bësh një sasi të madhe pasi të ketë përfunduar kopja rezervë për të rivendosur plotësisht cache-in. E veçanta e S3 është se copat e pompuara më pak nuk do të dërgohen kurrë në kovë, që do të thotë se të dhënat e mbushura jo të plota çojnë në dëmtime të mëdha.
Kontrolli i integritetit funksionon mirë në të dyja rastet, por shpejtësia ndryshon ndjeshëm.
Restik Orë 3,5.
Borg, me një memorie të skedarit SSD 100 GB - Orë 5.Përafërsisht e njëjta shpejtësi rezulton nëse të dhënat janë në një disk lokal.
Borg lexon drejtpërdrejt nga S3 pa cache Orë 33. Një kohë monstruoze e gjatë.

Përfundimi është se Borg mund të ngjesh dhe ka bloza më të mëdha - gjë që e bën ruajtjen dhe operacionet GET/PUT në S3 më të lira. Por kjo vjen me koston e verifikimit më kompleks dhe më të ngadaltë. Sa i përket shpejtësisë së rikuperimit, nuk kemi vërejtur ndonjë ndryshim. Restic merr kopje rezervë të mëvonshme (pas të parës) pak më gjatë, por jo në mënyrë të konsiderueshme.

E fundit, por jo më pak e rëndësishme në zgjedhje ishte madhësia e komunitetit.

Dhe ne zgjodhëm borgun.

Disa fjalë për kompresimin

Borg ka një algoritëm të ri të shkëlqyer kompresimi në arsenalin e tij - zstd. Cilësia e kompresimit nuk është më e keqe se gzip, por shumë më e shpejtë. Dhe e krahasueshme në shpejtësi me lz4 të paracaktuar.

Për shembull, një depon e bazës së të dhënave MySQL kompresohet dy herë më mirë se lz4 me të njëjtën shpejtësi. Megjithatë, përvoja me të dhënat reale tregon se ka shumë pak ndryshim në raportin e kompresimit të nyjes Nextcloud.

Borg ka një mënyrë kompresimi mjaft bonus - nëse skedari ka entropi të lartë, atëherë kompresimi nuk aplikohet fare, gjë që rrit shpejtësinë. Aktivizohet nga opsioni kur krijoni
-C auto,zstd
për algoritmin zstd
Pra, me këtë opsion, në krahasim me ngjeshjen e paracaktuar, morëm
560 Gb dhe 562 Gb përkatësisht. Të dhënat nga shembulli i mësipërm, më lejoni t'ju kujtoj, pa kompresim rezultati është 628 Gb. Rezultati i një ndryshimi prej 2 GB na befasoi disi, por menduam se në fund të fundit do ta zgjidhnim. auto,zstd.

Metoda e verifikimit rezervë

Sipas planifikuesit, makina virtuale lëshohet drejtpërdrejt nga ofruesi ose nga klienti, gjë që redukton shumë ngarkesën e rrjetit. Të paktën është më e lirë sesa ta rrisni vetë dhe të drejtoni trafikun.

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/

Duke përdorur të njëjtën skemë, ne kontrollojmë skedarët me një antivirus (pas faktit). Në fund të fundit, përdoruesit ngarkojnë gjëra të ndryshme në Nextcloud dhe jo të gjithë kanë një antivirus. Kryerja e inspektimeve në kohën e derdhjes kërkon shumë kohë dhe ndërhyn në biznes.

Shkallueshmëria arrihet duke ekzekutuar vrapues në nyje të ndryshme me etiketa të ndryshme.
Monitorimi ynë mbledh statuset rezervë përmes API-së GitLab në një dritare; nëse është e nevojshme, problemet vërehen lehtësisht dhe po aq lehtësisht lokalizohen.

Përfundim

Si rezultat, ne e dimë me siguri që bëjmë kopje rezervë, që kopjet rezervë janë të vlefshme, problemet që lindin me to kërkojnë pak kohë dhe zgjidhen në nivelin e administratorit të detyrës. Rezervimet zënë shumë pak hapësirë në krahasim me tar.gz ose Bacula.

Burimi: www.habr.com

Si ju ndihmon GitLab të kopjoni memorie të mëdha NextCloud