Kiel GitLab helpas vin sekurkopii grandajn NextCloud-stokojn

Hej Habr!

Hodiaŭ mi volas paroli pri nia sperto pri aŭtomatigo de la sekurkopio de grandaj datumoj de Nextcloud-stokadoj en malsamaj agordoj. Mi laboras kiel benzinejo ĉe Molniya AK, kie ni faras agordan administradon de IT-sistemoj; Nextcloud estas uzata por konservado de datumoj. Inkluzive, kun distribuita strukturo, kun redundo.

La problemoj estiĝantaj de la funkcioj de la instalaĵoj estas, ke ekzistas multaj datumoj. Versiado provizita de Nextcloud, redundo, subjektivaj kialoj kaj pli kreas multajn duplikatojn.

antaŭhistorio

Dum la administrado de Nextcloud, ŝprucas la problemo pri organizado de efika sekurkopio, kiu devas esti ĉifrita, ĉar la datumoj estas valoraj.

Ni ofertas eblojn por konservi sekurkopiojn ĉe nia loko aŭ ĉe la kliento sur apartaj maŝinoj de Nextcloud, kio postulas flekseblan aŭtomatigitan aliron al administrado.

Estas multaj klientoj, ĉiuj kun malsamaj agordoj, kaj ĉiuj en siaj propraj retejoj kaj kun siaj propraj trajtoj. Ĉi tio estas norma tekniko kiam la tuta retejo apartenas al vi, kaj sekurkopioj estas faritaj el kronoj; ĝi ne taŭgas bone.

Unue, ni rigardu la enigajn datumojn. Ni bezonas:

• Skalebleco laŭ unu nodo aŭ pluraj. Por grandaj instalaĵoj ni uzas minion kiel stokadon.
• Eksciu pri problemoj kun farado de sekurkopioj.
• Vi devas konservi sekurkopion ĉe viaj klientoj kaj/aŭ ĉe ni.
• Traktu problemojn rapide kaj facile.
• Klientoj kaj instalaĵoj estas tre malsamaj unu de la alia - unuformeco ne povas esti atingita.
• La reakiro rapideco devus esti minimuma en du scenaroj: plena reakiro (katastrofo), unu dosierujo forviŝita erare.
• Deduplika funkcio estas postulata.

Por solvi la problemon pri administrado de sekurkopioj, ni instalis GitLab. Pli da detaloj per ilaro.

Kompreneble, ni ne estas la unuaj, kiuj solvis tian problemon, sed ŝajnas al ni, ke nia praktika, malfacile gajnita sperto povas esti interesa kaj ni pretas ĝin dividi.

Ĉar nia kompanio havas malfermfontan politikon, ni serĉis malfermfontan solvon. Siavice, ni dividas niajn evoluojn kaj afiŝas ilin. Ekzemple, sur GitHub ekzistas nia kromaĵo por Nextcloud, kiun ni provizas al klientoj, plibonigante datuman sekurecon en kazo de hazarda aŭ intenca forigo.

Rezervaj iloj

Ni komencis nian serĉon pri solvo-metodoj elektante rezervan krean ilon.

Regula gudro + gzip ne funkcias bone - la datumoj estas duobligitaj. Pliigo ofte enhavas tre malmultajn realajn ŝanĝojn, kaj multe de la datenoj ene de ununura dosiero estas ripetita.
Estas alia problemo - redundo de distribuita datumstokado. Ni uzas minion kaj ĝiaj datumoj esence estas superfluaj. Aŭ vi devis fari sekurkopion per minio mem - ŝargu ĝin kaj uzu ĉiujn interspacilojn inter la dosiersistemo, kaj, ne malpli grave, ekzistas risko forgesi pri iuj siteloj kaj meta-informoj. Aŭ uzu deduplikadon.

Rezervaj iloj kun duobligo estas disponeblaj en malferma fonto (sur Habré estis artikoloj pri ĉi tiu temo) kaj niaj finalistoj estis urbo и Restu. Nia komparo de la du aplikaĵoj estas sube, sed nuntempe ni rakontos al vi kiel ni organizis la tutan skemon.

Administrado de sekurkopioj

Borg kaj Restic estas bonaj, sed neniu produkto havas centralizitan kontrolmekanismon. Por administrado kaj kontrolo, ni elektis ilon, kiun ni jam efektivigis, sen kiu ni ne povas imagi nian laboron, inkluzive de aŭtomatigo - ĉi tiu estas la konata CI/CD - GitLab.

La ideo estas jena: gitlab-runner estas instalita sur ĉiu nodo stokante Nextcloud-datumojn. La kuristo prizorgas skripton laŭ horaro, kiu kontrolas la rezervan procezon, kaj ĝi lanĉas Borg aŭ Restic.

Kion ni ricevis? Reago de ekzekuto, oportuna kontrolo de ŝanĝoj, detaloj en kazo de eraro.

tie ĉi tie sur GitHub ni afiŝis ekzemplojn de la skripto por diversaj taskoj, kaj ni finis alkroĉi ĝin al la sekurkopio de ne nur Nextcloud, sed ankaŭ de multaj aliaj servoj. Ekzistas ankaŭ planilo tie se vi ne volas agordi ĝin permane (kaj ni ne volas) kaj .gitlab-ci.yml

Ankoraŭ ne ekzistas maniero ŝanĝi la CI/CD-tempon en la Gitlab API, sed ĝi estas malgranda. Ĝi devas esti pliigita, diru al 1d.

GitLab, feliĉe, povas lanĉi ne nur laŭ kompromiso, sed nur laŭ horaro, ĝuste tion ni bezonas.

Nun pri la envolvaĵa skripto.

Ni starigas la jenajn kondiĉojn por ĉi tiu skripto:

• Ĝi devus esti lanĉita kaj de la kuristo kaj mane de la konzolo kun la sama funkcieco.
• Devas ekzisti erartraktiloj:
• revenkodo.
• serĉi ĉenon en la protokolo. Ekzemple, por ni eraro povas esti mesaĝo, kiun la programo ne konsideras fatala.
• Pretigo de tempodaŭro. La plumbotempo devas esti racia.
• Ni bezonas tre detalan protokolon. Sed nur en kazo de eraro.
• Kelkaj provoj ankaŭ estas faritaj antaŭ ol komenci.
• Malgrandaj gratifikoj por oportuno, kiujn ni trovis utilaj dum la subtena procezo:
• La komenco kaj fino estas registritaj en la syslog de la loka maŝino. Ĉi tio helpas konekti sistemajn erarojn kaj rezervan operacion.
• Parto de la erarprotokolo, se ekzistas, estas eligita al stdout, la tuta protokolo estas skribita al aparta dosiero. Estas oportune tuj rigardi CI kaj taksi la eraron se ĝi estas bagatela.
• Sencimigaj reĝimoj.

La plena protokolo estas konservita kiel artefakto en GitLab; se ne estas eraro, la protokolo estas forigita. Ni skribas la skripton en bash.

Ni volonte pripensos iujn ajn sugestojn kaj komentojn pri malferma fonto - bonvenon.

Kiel tio funkcias

Kuristo kun Bash-ekzekutoro estas lanĉita sur la rezerva nodo. Laŭ la planisto, laboro CI/CD estas lanĉita en speciala rapo. La kuristo lanĉas universalan envolvaĵan skripton por tiaj taskoj, ĝi kontrolas la validecon de la rezerva deponejo, muntado-punktoj kaj ĉio, kion ni volas, poste kopias kaj purigas la malnovan. La finita sekurkopio mem estas sendita al S3.

Ni laboras laŭ ĉi tiu skemo - ĝi estas ekstera AWS-provizanto aŭ rusa ekvivalento (ĝi estas pli rapida kaj la datumoj ne eliras de la Rusa Federacio). Aŭ ni instalas apartan minio-grupon por la kliento en lia retejo por ĉi tiuj celoj. Ni kutime faras tion pro sekurecaj kialoj, kiam la kliento tute ne volas, ke la datumoj forlasu sian cirkviton.

Ni ne uzis la funkcion sendi sekurkopion per ssh. Ĉi tio ne aldonas sekurecon, kaj la retkapabloj de la S3-provizanto estas multe pli altaj ol nia unu ssh-maŝino.

Por protekti vian lokan maŝinon kontraŭ retpirato, ĉar li povas forigi datumojn sur S3, vi devas ebligi versionadon.
La sekurkopio ĉiam ĉifras la sekurkopion.

Borg havas neĉifritan reĝimon none, sed ni forte ne rekomendas ŝalti ĝin. En ĉi tiu reĝimo, ne nur estos neniu ĉifrado, sed la ĉeksumo de kio estas skribita ne estas kalkulita, kio signifas ke integreco povas esti kontrolita nur nerekte, uzante indeksojn.

Aparta planilo kontrolas sekurkopiojn por la integreco de indeksoj kaj enhavo. La kontrolo estas malrapida kaj longa, do ni faras ĝin aparte unufoje monate. Ĝi povas daŭri plurajn tagojn.

Legu min en la rusa

Ĉefaj funkcioj

• prepare trejnado
• testcheck kontrolo de preteco
• maincommand kerna teamo
• forcepostscript funkcio kiu estas efektivigita en la fino aŭ per eraro. Ni uzas ĝin por malmunti la subdiskon.

Servaj funkcioj

• cleanup Ni registras erarojn aŭ forigas la protokoldosieron.
• checklog analizu la protokolon por la apero de linio kun eraro.
• ret eliro prizorganto.
• checktimeout kontrolu pri tempodaŭro.

medio

• VERBOSE=1 Ni tuj montras erarojn sur la ekrano (stdout).
• SAVELOGSONSUCCES=1 konservu la protokolon post sukceso.
• INIT_REPO_IF_NOT_EXIST=1 Kreu deponejon se ĝi ne ekzistas. Malŝaltita defaŭlte.
• TIMEOUT maksimuma tempo por la ĉefa operacio. Vi povas agordi ĝin kiel 'm', 'h' aŭ 'd' ĉe la fino.

Stoka reĝimo por malnovaj kopioj. Defaŭlta:

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

Variabloj ene de la skripto

• ERROR_STRING — ĉeno por la enregistro pro eraro.
• EXTRACT_ERROR_STRING — esprimo por montri ĉenon se eraro.
• KILL_TIMEOUT_SIGNAL — signalo por mortigo se timeout.
• TAIL — kiom da ŝnuroj kun eraroj sur ekrano.
• COLORMSG — koloro de mesaĝo (defaŭlte flava).

Tiu skripto, kiu nomiĝas wordpress, havas kondiĉan nomon, ĝia lertaĵo estas, ke ĝi ankaŭ subtenas la mysql-datumbazon. Ĉi tio signifas, ke ĝi povas esti uzata por ununodaj instalaĵoj de Nexcloud, kie vi ankaŭ povas subteni la datumbazon. La komforto ne nur estas, ke ĉio estas en unu loko, sed ankaŭ la enhavo de la datumbazo estas proksima al la enhavo de la dosieroj, ĉar la tempodiferenco estas minimuma.

Restika kontraŭ Borg

Ekzistas ankaŭ komparoj inter Borg kaj Restic ĉi tie sur Habré, kaj ni ne havis la taskon fari nur alian, sed nian. Gravis por ni kiel ĝi aspektus sur niaj datumoj, kun niaj specifaĵoj. Ni alportas ilin.

Niaj elektkriterioj, krom tiuj jam menciitaj (sendupliko, rapida reakiro, ktp.):

• Rezisto al nefinita laboro. Kontrolu por mortigo -9.
• Grandeco sur disko.
• Postulo por rimedoj (CPU, memoro).
• Grandeco de stokitaj blobs.
• Laborante kun S3.
• Kontrolo de integreco.

Por testado, ni prenis unu klienton kun realaj datumoj kaj totala grandeco de 1,6 TB.
Kondiĉoj.

Borg ne scias kiel labori rekte kun S3, kaj ni muntis la diskon kiel fuzeo, tra stultuloj. Restic sendis ĝin al S3 mem.

Goofys funkcias tre rapide kaj bone, kaj ekzistas Diska kaŝmemormodulo, kiu plirapidigas la laboron. Ĝi estas en la beta-fazo, kaj, sincere, ni kraŝis kun perdo de datumoj dum provoj (aliaj). Sed la oportuno estas, ke la rezerva proceduro mem ne postulas multe da legado, sed plejparte skribado, do ni uzas la kaŝmemoron nur dum integreckontroloj.

Por redukti la influon de la reto, ni uzis lokan provizanton - Yandex Cloud.

Kompartestrezultoj.

• Mortigi -9 kun plia rekomenco estis ambaŭ sukcesa.
• Grandeco sur disko. Borg povas kunpremi, do la rezultoj estas kiel atenditaj.

Rezervisto
grandeco

urbo
562Gb

Restu
628Gb

• Per CPU
  Borg mem konsumas malmulte, kun defaŭlta kunpremo, sed ĝi devas esti taksita kune kun la goofys-procezo. Entute ili estas kompareblaj kaj uzas ĉirkaŭ 1,2 kernojn sur la sama prova virtuala maŝino.
• Memoro. Restic estas proksimume 0,5GB, Borg estas proksimume 200MB. Sed ĉi tio ĉio estas sensignifa kompare kun la sistema dosierkaŝmemoro. Do estas konsilinde asigni pli da memoro.
• La diferenco en la grandeco de blob estis okulfrapa.

Rezervisto
grandeco

urbo
ĉirkaŭ 500MB

Restu
ĉirkaŭ 5MB

• La S3-sperto de Restic estas bonega. Labori kun Borg per goofys ne levas demandojn, sed oni rimarkis, ke estas konsilinde fari malmuntadon post kiam la sekurkopio estas kompleta por tute restarigi la kaŝmemoron. La propreco de S3 estas, ke subpumpitaj pecoj neniam estos senditaj al la sitelo, kio signifas, ke nekomplete plenigitaj datumoj kondukas al grava damaĝo.
• La integreckontrolo funkcias bone en ambaŭ kazoj, sed la rapideco diferencas signife.
  Restu 3,5 horoj.
  Borg, kun 100GB SSD-dosierkaŝmemoro - 5 horoj.Proksimume la sama rapideco rezultas se la datumoj estas sur loka disko.
  Borg legas rekte de S3 sen kaŝmemoro 33 horoj. Monstre longa.

La fundo estas, ke Borg povas kunpremi kaj havas pli grandajn makulojn - kio faras stokadon kaj operaciojn GET/PUT en S3 pli malmultekostaj. Sed ĉi tio kostas pli kompleksan kaj pli malrapidan konfirmon. Koncerne la rapidecon de reakiro, ni ne rimarkis neniun diferencon. Restic prenas postajn sekurkopiojn (post la unua) iom pli longe, sed ne signife.

Laste sed ne malplej en la elekto estis la grandeco de la komunumo.

Kaj ni elektis borg.

Kelkaj vortoj pri kunpremado

Borg havas bonegan novan kunpreman algoritmon en sia arsenalo - zstd. La kunprema kvalito ne estas pli malbona ol gzip, sed multe pli rapida. Kaj komparebla en rapideco al la defaŭlta lz4.

Ekzemple, MySQL-datumbaza rubujo estas kunpremita duoble pli bone ol lz4 je la sama rapideco. Tamen, sperto kun realaj datumoj montras, ke estas tre malmulte da diferenco en la kunprema proporcio de la Nextcloud-nodo.

Borg havas sufiĉe bonusan kunpreman reĝimon - se la dosiero havas altan entropion, tiam kunpremado tute ne estas aplikata, kio pliigas la rapidecon. Ebligita per opcio dum kreado
-C auto,zstd
por la zstd-algoritmo
Do kun ĉi tiu opcio, kompare kun la defaŭlta kunpremo, ni ricevis
560Gb kaj 562Gb respektive. La datumoj de la supra ekzemplo, lasu min memorigi vin, sen kunpremo la rezulto estas 628Gb. La rezulto de 2GB-diferenco iom surprizis nin, sed ni pensis, ke ni elektus ĝin finfine. auto,zstd.

Rezerva konfirmmetodo

Laŭ la planisto, la virtuala maŝino estas lanĉita rekte de la provizanto aŭ de la kliento, kio multe reduktas la retan ŝarĝon. Almenaŭ ĝi estas pli malmultekosta ol levi ĝin mem kaj stiri trafikon.

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/

Uzante la saman skemon, ni kontrolas dosierojn per antiviruso (post la fakto). Post ĉio, uzantoj alŝutas malsamajn aferojn al Nextcloud kaj ne ĉiuj havas antiviruson. Fari inspektadojn dum verŝado prenas tro da tempo kaj malhelpas komercon.

Skalebleco estas atingita per kurado de kuristoj sur malsamaj nodoj kun malsamaj etikedoj.
Nia monitorado kolektas rezervajn statusojn per la GitLab API en unu fenestro; se necese, problemoj estas facile rimarkitaj kaj same facile lokalizeblaj.

konkludo

Kiel rezulto, ni certe scias, ke ni faras sekurkopiojn, ke niaj sekurkopioj validas, problemoj, kiuj aperas kun ili, bezonas malmulte da tempo kaj estas solvitaj je la nivelo de la devo-administranto. Sekurkopioj okupas vere malmulte da spaco kompare kun tar.gz aŭ Bacula.

fonto: www.habr.com