Nola laguntzen dizu GitLab-ek NextCloud biltegiratze handien babeskopiak

Aupa Habr!

Gaur Nextcloud biltegietako datu handien babeskopiak automatizatzeko dugun esperientziari buruz hitz egin nahi dut konfigurazio ezberdinetan. Molniya AK-n zerbitzugune gisa lan egiten dut, non IT sistemen konfigurazio kudeaketa egiten dugu; Nextcloud erabiltzen da datuak biltegiratzeko. Barne, egitura banatuarekin, erredundantziarekin.

Instalazioen ezaugarrietatik sortzen diren arazoak datu asko daudela dira. Nextcloud-ek emandako bertsioak, erredundantziak, arrazoi subjektiboak eta gehiago bikoiztu asko sortzen ditu.

historiaurrea

Nextcloud administratzean, segurtasun kopia eraginkor bat antolatzeko arazoa sortzen da, enkriptatu egin behar dena, datuak baliotsuak baitira.

Babeskopiak gure etxean edo bezeroarengan gordetzeko aukerak eskaintzen ditugu Nextcloud-eko makina bereizietan, eta horrek administrazioaren ikuspegi automatizatu malgua eskatzen du.

Bezero asko daude, denak konfigurazio ezberdinekin, eta denak beren guneetan eta bere ezaugarriekin. Teknika estandarra da gune osoa zurea denean eta babeskopiak koroetatik egiten direnean; ez da ondo egokitzen.

Lehenik eta behin, ikus ditzagun sarrerako datuak. Behar dugu:

• Eskalagarritasuna nodo baten edo hainbaten arabera. Instalazio handietarako minio erabiltzen dugu biltegiratze gisa.
• Ezagutu babeskopiak egiteko arazoei buruz.
• Babeskopia bat egin behar duzu zure bezeroekin eta/edo gurekin.
• Arazoei azkar eta erraz aurre egin.
• Bezeroak eta instalazioak oso desberdinak dira elkarrengandik - ezin da uniformetasuna lortu.
• Berreskuratze-abiadura minimoa izan behar da bi agertokitan: berreskurapen osoa (hondamendia), karpeta bat akatsez ezabatu da.
• Desduplicazio funtzioa beharrezkoa da.

Babeskopia kudeatzeko arazoa konpontzeko, GitLab instalatu dugu. Xehetasun gehiago aurrekariaren arabera.

Jakina, ez gara horrelako arazo bat konpontzen lehenak, baina iruditzen zaigu gure esperientzia praktikoa, gogor lortutakoa, interesgarria izan daitekeela eta partekatzeko prest gaude.

Gure enpresak kode irekiko politika daukanez, kode irekiko irtenbide baten bila ari ginen. Era berean, gure garapenak partekatzen ditugu eta argitaratzen ditugu. Adibidez, GitHub-en dago Nextcloud-erako gure plugina, bezeroei eskaintzen dieguna, datuen segurtasuna areagotuz ustekabean edo nahita ezabatuz gero.

Backup tresnak

Konponbide-metodoen bila hasi ginen babeskopia sortzeko tresna bat aukeratuz.

Tar + gzip arruntek ez dute ondo funtzionatzen - datuak bikoiztuta daude. Gehikuntza batek askotan benetako aldaketa gutxi izaten ditu, eta fitxategi bakarreko datu asko errepikatzen dira.
Beste arazo bat dago: banatutako datuen biltegiratze erredundantzia. Minio erabiltzen dugu eta bere datuak funtsean erredundanteak dira. Edo babeskopia bat egin behar izan duzu minio-ren bidez - kargatu eta erabili fitxategi-sistemaren arteko tarte guztiak, eta, ez da hain garrantzitsua, kubo eta meta-informazio batzuk ahazteko arriskua dago. Edo deduplicazioa erabili.

Bikoiztutako babeskopia tresnak kode irekian daude eskuragarri (Habré-n zeuden Artikulua gai honi buruz) eta gure finalistak izan ziren Borg и Atseden. Behean dago bi aplikazioen alderaketa, baina oraingoz eskema osoa nola antolatu dugun kontatuko dizuegu.

Babeskopia kudeatzea

Borg eta Restic onak dira, baina produktu batek ez du kontrol-mekanismo zentralizaturik. Kudeaketa eta kontrolerako, dagoeneko inplementatu dugun tresna bat aukeratu dugu, eta hori gabe ezin dugu gure lana imajinatu, automatizazioa barne - hau da CI/CD ezaguna - GitLab.

Ideia hau da: gitlab-runner instalatuta dago nodo bakoitzean Nextcloud datuak gordetzeko. Korrikalariak script bat exekutatzen du babeskopia-prozesua kontrolatzen duen programazio batean, eta Borg edo Restic abiarazten du.

Zer lortu dugu? Exekuzioaren iritzia, aldaketen kontrol erosoa, akatsen kasuan xehetasunak.

Hemen hemen GitHub-en hainbat atazatarako script-aren adibideak argitaratu genituen, eta Nextcloud-en ez ezik, beste zerbitzu askoren babeskopiari erantsi genion azkenean. Antolatzaile bat ere badago hor eskuz konfiguratu nahi ez baduzu (eta guk ez dugu nahi) eta .gitlab-ci.yml

Gitlab APIan CI/CD denbora-muga aldatzeko modurik ez dago oraindik, baina txikia da. Handitu egin behar da, esan 1d.

GitLab, zorionez, konpromiso baten arabera ez ezik, egutegi baten arabera bakarrik abiarazi daiteke, hau da behar duguna.

Orain wrapper gidoiari buruz.

Script honetarako baldintza hauek ezarri ditugu:

• Lasterkariak eta eskuz abiarazi behar du kontsolatik funtzionalitate berarekin.
• Errore-kudeatzaileak egon behar dira:
• itzultzeko kodea.
• bilatu kate bat erregistroan. Adibidez, guretzat errore bat programak hilgarritzat jotzen ez duen mezua izan daiteke.
• Prozesatzeko denbora-muga. Epeak arrazoizkoa izan behar du.
• Oso erregistro zehatza behar dugu. Baina akatsen kasuan bakarrik.
• Hasi baino lehen proba batzuk ere egiten dira.
• Laguntza-prozesuan zehar erabilgarriak aurkitu ditugun erosotasunerako hobari txikiak:
• Hasiera eta amaiera tokiko makinaren syslog-en erregistratzen dira. Horrek sistemaren akatsak eta babeskopia eragiketak konektatzen laguntzen du.
• Errore-erregistroaren zati bat, baldin badago, stdout-era ateratzen da, erregistro osoa fitxategi bereizi batean idazten da. Komenigarria da berehala CI begiratu eta errorea hutsala bada ebaluatzea.
• Arazketa moduak.

Erregistro osoa artefaktu gisa gordetzen da GitLab-en; akatsik ez badago, erregistroa ezabatzen da. Gidoia bash-en idazten dugu.

Pozik hartuko ditugu iradokizunak eta iruzkinak kode irekiari buruz - ongi etorriak.

Nola egiten du lan

Bash exekutatzailea duen korrikalari bat abiarazten da babeskopia-nodoan. Planifikatzailearen arabera, CI/CD lana arbia berezi batean abiarazten da. Korrikalariak bilgarri unibertsaleko script bat abiarazten du horrelako zereginetarako, babeskopien biltegiaren, muntatze-puntuen eta nahi dugun guztiaren baliozkotasuna egiaztatzen du, ondoren zaharraren babeskopia egin eta garbitzen du. Amaitutako babeskopia bera S3ra bidaltzen da.

Eskema honen arabera lan egiten dugu: kanpoko AWS hornitzaile bat da edo Errusiako baliokide bat da (bizkorragoa da eta datuak ez dira Errusiako Federaziotik irteten). Edo bezeroarentzako minio kluster bereizi bat instalatzen dugu bere webgunean helburu horietarako. Segurtasun arrazoiengatik egiten dugu normalean, bezeroak datuak bere zirkuitutik batere utzi nahi ez dituenean.

Ez dugu ssh bidez babeskopia bidaltzeko funtzioa erabili. Horrek ez du segurtasunik gehitzen, eta S3 hornitzailearen sare-gaitasunak gure ssh makina bakarra baino askoz ere handiagoak dira.

Zure tokiko makina hacker batetik babesteko, S3-n datuak ezaba ditzakeenez, bertsioa gaitu behar duzu.
Babeskopiak beti zifratzen du babeskopia.

Borgek zifratu gabeko modua du none, baina ez dugu gomendatzen hura aktibatzea. Modu honetan, ez da enkriptatzerik izango, baizik eta idazten denaren checksum-a ez da kalkulatzen, hau da, osotasuna zeharka baino ezin da egiaztatu, indizeak erabiliz.

Antolatzaile bereizi batek indizeen eta edukien osotasuna egiaztatzen du babeskopiak. Egiaztapena motela eta luzea da, beraz, hilean behin bereizita egiten dugu. Hainbat egun behar izan ditzake.

Irakur nazazu errusieraz

Funtzio nagusiak

• prepare prestakuntza
• testcheck presttasuna egiaztatzea
• maincommand oinarrizko taldea
• forcepostscript amaieran edo akatsen bidez exekutatzen den funtzioa. Partizioa desmuntatzeko erabiltzen dugu.

Zerbitzu-funtzioak

• cleanup Akatsak erregistratzen ditugu edo log fitxategia ezabatzen dugu.
• checklog analizatu erregistroa errore bat duen lerro bat agertzeko.
• ret irteera kudeatzailea.
• checktimeout egiaztatu denbora-muga.

Ingurumena

• VERBOSE=1 Akatsak pantailan berehala bistaratzen ditugu (stdout).
• SAVELOGSONSUCCES=1 gorde erregistroa arrakastaz gero.
• INIT_REPO_IF_NOT_EXIST=1 Sortu biltegi bat existitzen ez bada. Lehenespenez desgaituta dago.
• TIMEOUT eragiketa nagusirako gehienezko denbora. 'm', 'h' edo 'd' gisa ezar dezakezu amaieran.

Kopi zaharren biltegiratze modua. Lehenetsia:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Gidoiaren barruko aldagaiak

• ERROR_STRING — akatsen erregistrorako katea.
• EXTRACT_ERROR_STRING — Erakutsi katea errorea bada adierazpena.
• KILL_TIMEOUT_SIGNAL — denbora-muga agortzen bada hiltzeko seinalea.
• TAIL — pantailan erroreak dituzten zenbat kate.
• COLORMSG — mezuaren kolorea (horia lehenetsia).

Wordpress deitzen den script horrek baldintzazko izena du, bere trikimailua mysql datu-basearen babeskopia ere egiten duela da. Horrek esan nahi du nodo bakarreko Nexcloud instalazioetarako erabil daitekeela, non datu-basearen babeskopia ere egin dezakezun. Erosotasuna ez da dena leku bakarrean egotea, baizik eta datu-basearen edukia fitxategien edukietatik gertu egotea da, denbora-aldea gutxienekoa baita.

Restic vs Borg

Borg eta Restic-en arteko konparaketak ere badaude hemen Habré, eta ez genuen beste bat egiteko zeregina, gurea baizik. Guretzat garrantzitsua zen gure datuetan nola ikusiko zen, gure berezitasunekin. Guk ekartzen ditugu.

Gure hautaketa-irizpideak, lehen aipatutakoez gain (desduplikatzea, berreskuratze azkarra, etab.):

• Amaitu gabeko lanen aurkako erresistentzia. Egiaztatu hiltzeko -9.
• Tamaina diskoan.
• Baliabideen eskakizuna (CPU, memoria).
• Biltegiratutako bloben tamaina.
• S3-rekin lan egiten.
• Osotasuna egiaztatzea.

Proba egiteko, bezero bat hartu genuen datu errealak eta 1,6 TB-ko tamaina guztira.
Baldintzak.

Borgek ez daki zuzenean nola lan egin S3-rekin, eta diskoa metxa gisa muntatu dugu, bidez tontoak. Restic-ek S3 berari bidali zion.

Goofys oso azkar eta ondo funtzionatzen du, eta badaude disko-cache modulua, lana are gehiago bizkortzen duena. Beta fasean dago, eta, egia esan, datu-galerekin huts egin genuen probetan (besteak). Baina erosotasuna da segurtasun-kopia-prozedurak berak ez duela irakurketa handirik behar, batez ere idaztea eskatzen duela, beraz, cachea osotasun egiaztapenetan soilik erabiltzen dugu.

Sarearen eragina murrizteko, tokiko hornitzaile bat erabili dugu: Yandex Cloud.

Konparazio proben emaitzak.

• Kill -9 gehiago berrabiaraziz biak arrakastatsuak izan ziren.
• Tamaina diskoan. Borg-ek konprimitu egin dezake, beraz, emaitzak espero zirenak dira.

Babeskopia
tamaina

Borg
562Gb

Atseden
628Gb

• CPU bidez
  Borgek berak gutxi kontsumitzen du, konpresio lehenetsiarekin, baina goofys prozesuarekin batera ebaluatu behar da. Guztira, konparagarriak dira eta 1,2 nukleo inguru erabiltzen dituzte probako makina birtualean.
• Memoria. Restic 0,5 GB inguru da, Borg 200 MB gutxi gorabehera. Baina hau guztia hutsala da sistemako fitxategien cachearekin alderatuta. Beraz, memoria gehiago esleitzea komeni da.
• Tamainaren aldea deigarria zen.

Babeskopia
tamaina

Borg
500 MB inguru

Atseden
5 MB inguru

• Restic-en S3-rekin esperientzia bikaina da. Borg-ekin goofys bidez lan egiteak ez du inolako galderarik sortzen, baina ohartu da komenigarria dela babeskopia amaitu ondoren desmuntatzea cachea guztiz berrezartzeko. S3-ren berezitasuna da azpian ponpatutako zatiak ez direla inoiz ontzira bidaliko, eta horrek esan nahi du guztiz bete gabeko datuek kalte handiak eragiten dituztela.
• Osotasun egiaztapenak ondo funtzionatzen du bi kasuetan, baina abiadura nabarmen desberdina da.
  Atseden 3,5 ordu.
  Borg, 100 GB SSD fitxategien cache batekin - 5 ordu.Gutxi gorabehera, abiadura berdina da datuak disko lokal batean badaude.
  Borgek zuzenean irakurtzen du S3-tik cacherik gabe 33 ordu. Izugarri luzea.

Beheko kontua da Borgek konprimitu dezakeela eta blob handiagoak dituela, eta horrek biltegiratze eta GET/PUT eragiketak S3-n merkeago egiten ditu. Baina hori egiaztapen konplexuago eta motelago baten kostua da. Berreskuratze abiadurari dagokionez, ez dugu alderik nabaritu. Restic-ek ondorengo babeskopiak (lehenengoaren ondoren) apur bat gehiago hartzen ditu, baina ez nabarmen.

Aukeran azkena, baina ez behintzat, komunitatearen tamaina izan zen.

Eta borg aukeratu genuen.

Konpresioari buruzko hitz batzuk

Borgek konpresio algoritmo berri bikaina du bere armategian - zstd. Konpresioaren kalitatea ez da gzip baino okerragoa, baina askoz azkarragoa da. Eta lehenetsitako lz4 abiaduraren parekoa.

Adibidez, MySQL datu-baseen iraulketa lz4 baino bi aldiz hobeto konprimitzen da abiadura berean. Hala ere, datu errealekin izandako esperientziak erakusten du oso alde txikia dagoela Nextcloud nodoaren konpresio-erlazioan.

Borg-ek konpresio modua nahiko bonusa du - fitxategiak entropia handia badu, konpresioa ez da batere aplikatzen, eta horrek abiadura handitzen du. Sortzean aukerak gaituta
-C auto,zstd
zstd algoritmorako
Beraz, aukera honekin, konpresio lehenetsiarekin alderatuta, lortu dugu
560 Gb eta 562 Gb hurrenez hurren. Goiko adibideko datuak, gogorarazten dizut, konpresiorik gabe emaitza 628Gb-koa dela. 2GB diferentziaren emaitzak zertxobait harritu gintuen, baina azkenean aukeratuko genuela pentsatu genuen. auto,zstd.

Babeskopia egiaztatzeko metodoa

Antolatzailearen arabera, makina birtuala hornitzailetik edo bezerotik zuzenean abiarazten da, eta horrek sarearen karga asko murrizten du. Gutxienez, zuk zeuk igotzea eta trafikoa gidatzea baino merkeagoa da.

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/

Eskema bera erabiliz, antibirus batekin fitxategiak egiaztatzen ditugu (ondoren). Azken finean, erabiltzaileek gauza desberdinak igotzen dituzte Nextcloud-era eta denek ez dute antibirusik. Ikuskapenak isurtzeko unean egiteak denbora gehiegi behar du eta negozioak oztopatzen ditu.

Eskalagarritasuna etiketa desberdinak dituzten nodo ezberdinetan korrikalariak exekutatzen direla lortzen da.
Gure monitorizazioak GitLab APIaren bidez babeskopien egoerak biltzen ditu leiho bakarrean; behar izanez gero, arazoak erraz antzematen dira eta erraz aurkitzen dira.

Ondorioa

Ondorioz, ziur badakigu babeskopiak egiten ditugula, gure babeskopiak baliozkoak direla, haiekin sortzen diren arazoak denbora gutxi behar dute eta betebeharko administratzailearen mailan konpontzen direla. Backupek leku gutxi hartzen dute tar.gz edo Bacula-rekin alderatuta.

Iturria: www.habr.com