Hoe GitLab jo helpt by reservekopy fan grutte NextCloud-opslach

Hoi Habr!

Hjoed wol ik prate oer ús ûnderfining yn it automatisearjen fan de reservekopy fan grutte gegevens fan Nextcloud-opslach yn ferskate konfiguraasjes. Ik wurkje as tsjinststasjon by Molniya AK, wêr't wy konfiguraasjebehear fan IT-systemen dogge; Nextcloud wurdt brûkt foar gegevensopslach. Ynklusyf, mei in ferdielde struktuer, mei oerstalligens.

De problemen dy't fuortkomme út 'e funksjes fan' e ynstallaasjes binne dat d'r in protte gegevens binne. Ferzjeferzje levere troch Nextcloud, redundânsje, subjektive redenen, en mear makket in protte duplikaten.

prehistoarje

By it administrearjen fan Nextcloud ûntstiet it probleem fan it organisearjen fan in effektive reservekopy, dy't fersifere wurde moat, om't de gegevens weardefol binne.

Wy biede opsjes foar it bewarjen fan backups op ús plak of by de klant op aparte masines fan Nextcloud, wat in fleksibele automatisearre oanpak fan administraasje fereasket.

D'r binne in protte kliïnten, allegear mei ferskate konfiguraasjes, en allegear op har eigen siden en mei har eigen skaaimerken. Dit is in standert technyk as de hiele side fan jo heart, en backups wurde makke fan kroanen; it past net goed.

Litte wy earst nei de ynfiergegevens sjen. Wy hawwe nedich:

• Skalberens yn termen fan ien knooppunt of meardere. Foar grutte ynstallaasjes brûke wy minio as opslach.
• Fyn út oer problemen mei it útfieren fan backups.
• Jo moatte in reservekopy hâlde mei jo kliïnten en/of by ús.
• Omgean mei problemen fluch en maklik.
• Klanten en ynstallaasjes binne hiel ferskillend fan elkoar - unifoarmens kin net berikt wurde.
• De herstelsnelheid moat minimaal wêze yn twa senario's: folsleine herstel (ramp), ien map per flater wiske.
• Deduplikaasjefunksje is fereaske.

Om it probleem fan it behearen fan backups op te lossen, hawwe wy GitLab ynstalleare. Mear details troch tackle.

Fansels binne wy ​​net de earste om sa'n probleem op te lossen, mar it liket ús dat ús praktyske, hurd fertsjinne ûnderfining ynteressant wêze kin en wy binne ree om it te dielen.

Sûnt ús bedriuw in iepen boarne-belied hat, sochten wy nei in iepen boarne-oplossing. Op ús beurt diele wy ús ûntwikkelingen en pleatse se. Bygelyks, op GitHub is d'r ús plugin foar Nextcloud, dy't wy oan kliïnten leverje, it ferbetterjen fan gegevensfeiligens yn gefal fan tafallich of opsetlik wiskjen.

Reservekopy ark

Wy begon ús sykjen nei oplossingsmetoaden troch te kiezen foar in ark foar oanmeitsjen fan reservekopy.

Reguliere tar + gzip wurket net goed - de gegevens binne duplikearre. In tanimming befettet faak heul pear feitlike feroarings, en in protte fan 'e gegevens binnen in inkele bestân wurdt werhelle.
D'r is in oar probleem - redundânsje fan ferspraat gegevens opslach. Wy brûke minio en syn gegevens binne yn prinsipe oerstallich. Of jo moasten in reservekopy meitsje fia minio sels - lade it en brûk alle spacers tusken it bestânsysteem, en, net minder wichtich, is d'r in risiko om guon fan 'e bakken en meta-ynformaasje te ferjitten. Of brûk deduplikaasje.

Reservekopy-ark mei duplikaasje binne beskikber yn iepen boarne (op Habré wiene d'r artikels oer dit tema) en ús finalisten wiene Borg и Restyk. Us ferliking fan de twa applikaasjes is hjirûnder, mar foar no sille wy jo fertelle hoe't wy it heule skema organisearre hawwe.

Behear fan backups

Borg en Restic binne goed, mar gjin produkt hat in sintralisearre kontrôle meganisme. Foar it doel fan behear en kontrôle hawwe wy in ark keazen dat wy al hawwe ymplementearre, sûnder dat wy ús wurk net kinne foarstelle, ynklusyf automatisearring - dit is de bekende CI / CD - GitLab.

It idee is as folget: gitlab-runner is ynstalleare op elke knooppunt dy't Nextcloud-gegevens opslaan. De runner rint in skript op in skema dat kontrolearret de reservekopy proses, en it lansearret Borg of Restic.

Wat hawwe wy krigen? Feedback fan útfiering, handige kontrôle oer feroarings, details yn gefal fan in flater.

hjir hjir op GitHub wy pleatst foarbylden fan it skript foar ferskate taken, en wy einigje mei hechtsje it oan de reservekopy fan net allinne Nextcloud, mar ek in protte oare tsjinsten. D'r is ek in planner as jo it net manuell ynstelle wolle (en wy wolle net) en .gitlab-ci.yml

D'r is noch gjin manier om de CI / CD-timeout yn 'e Gitlab API te feroarjen, mar it is lyts. It moat ferhege wurde, sis mar 1d.

GitLab, gelokkich, kin net allinich lansearje neffens in commit, mar allinich neffens in skema, dit is krekt wat wy nedich binne.

No oer it wrapperskript.

Wy sette de folgjende betingsten foar dit skript:

• It moat wurde lansearre sawol troch de runner en mei de hân fan 'e konsole mei deselde funksjonaliteit.
• D'r moatte flaterhannelers wêze:
• werom koade.
• sykje nei in tekenrige yn it log. Bygelyks, foar ús kin in flater in berjocht wêze dat it programma net fataal beskôget.
• Timeout foar ferwurkjen. De levertiid moat ridlik wêze.
• Wy hawwe in heul detaillearre log nedich. Mar allinich yn gefal fan in flater.
• In oantal testen wurde ek útfierd foardat jo begjinne.
• Lytse bonussen foar gemak dy't wy nuttich fûnen tidens it stipeproses:
• It begjin en ein wurde opnommen yn it syslog fan 'e lokale masine. Dit helpt te ferbinen systeem flaters en reservekopy operaasje.
• In diel fan it flaterlog, as der ien is, wurdt útfierd nei stdout, it heule log wurdt skreaun nei in apart bestân. It is handich om fuortendaliks nei CI te sjen en de flater te evaluearjen as it trivial is.
• Debuggen modes.

It folsleine log wurdt bewarre as artefakt yn GitLab; as d'r gjin flater is, wurdt it log wiske. Wy skriuwe it skript yn bash.

Wy sille graach alle suggestjes en opmerkingen beskôgje oangeande iepen boarne - wolkom.

Hoe docht dit wurk

In runner mei in Bash-útfierder wurdt lansearre op it backupknooppunt. Neffens de planner wurdt baan CI / CD lansearre yn in spesjale raap. De runner lanseart in universele wrapperskript foar sokke taken, it kontrolearret de jildigens fan 'e reservekopy-repository, mountpunten en alles wat wy wolle, en makket dan in reservekopy op en makket de âlde op. De klear reservekopy sels wurdt stjoerd nei S3.

Wy wurkje neffens dit skema - it is in eksterne AWS-provider as in Russyske ekwivalint (it is rapper en de gegevens ferlitte de Russyske Federaasje net). Of wy ynstallearje in apart minio-kluster foar de klant op syn side foar dizze doelen. Wy dogge dit normaal om feiligens redenen, as de klant net wol dat de gegevens har circuit hielendal ferlitte.

Wy hawwe de funksje net brûkt om reservekopy te ferstjoeren fia ssh. Dit foeget gjin feiligens ta, en de netwurkmooglikheden fan 'e S3-provider binne folle heger as ús ien ssh-masine.

Om jo lokale masine te beskermjen tsjin in hacker, om't hy gegevens op S3 kin wiskje, moatte jo ferzjeferzje ynskeakelje.
De reservekopy fersiferet altyd de reservekopy.

Borg hat in net fersifere modus none, mar wy riede it net oan om it oan te setten. Yn dizze modus sil d'r net allinich gjin fersifering wêze, mar de kontrôlesum fan wat skreaun wurdt wurdt net berekkene, wat betsjut dat yntegriteit allinich yndirekt kin wurde kontrolearre, mei yndeksen.

In aparte planner kontrolearret backups foar de yntegriteit fan yndeksen en ynhâld. De kontrôle is stadich en lang, dus wy rinne it ien kear yn 'e moanne apart. It kin ferskate dagen duorje.

Readme yn it Russysk

Haadfunksjes

• prepare tarieding
• testcheck reewilligens kontrôle
• maincommand kearnteam
• forcepostscript in funksje dy't op it lêst of troch flater wurdt útfierd. Wy brûke it om de partysje te ûntkoppelen.

Service funksjes

• cleanup Wy registrearje flaters of wiskje it logbestân.
• checklog parse it log foar it foarkommen fan in rigel mei in flater.
• ret útgong handler.
• checktimeout kontrolearje foar timeout.

Miljeu

• VERBOSE=1 Wy werjaan flaters op it skerm fuortendaliks (stdout).
• SAVELOGSONSUCCES=1 bewarje it log op sukses.
• INIT_REPO_IF_NOT_EXIST=1 Meitsje in repository as it net bestiet. Standert útskeakele.
• TIMEOUT maksimum tiid foar de wichtichste operaasje. Jo kinne it ynstelle as 'm', 'h' of 'd' oan 'e ein.

Opslachmodus foar âlde kopyen. Standert:

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

Fariabelen binnen it skript

• ERROR_STRING - tekenrige foar it ynchecklogboek foar flater.
• EXTRACT_ERROR_STRING - ekspresje foar show string as flater.
• KILL_TIMEOUT_SIGNAL - sinjaal foar killing as timeout.
• TAIL - hoefolle snaren mei flaters op it skerm.
• COLORMSG - kleur fan berjocht (standert giel).

Dat skript, dat wurdt neamd, hat in betingst namme, syn trúk is dat it ek in reservekopy fan de mysql databank. Dit betsjut dat it kin wurde brûkt foar single-node Nexcloud-ynstallaasjes, wêr't jo ek in reservekopy kinne fan 'e databank. It gemak is net allinich dat alles op ien plak is, mar ek de ynhâld fan 'e databank is tichtby de ynhâld fan' e bestannen, om't it tiidferskil minimaal is.

Restic vs Borg

Der binne ek ferlikingen tusken Borg en Restic hjir op Habré, en wy hiene net de taak om mar in oar te meitsjen, mar ús eigen. It wie wichtich foar ús hoe't it soe útsjen op ús gegevens, mei ús spesifiken. Wy bringe se.

Us seleksjekritearia, neist de al neamde (deduplikaasje, rappe herstel, ensfh.):

• Ferset tsjin ûnfoltôge wurk. Kontrolearje op kill -9.
• Grutte op skiif.
• Eask foar boarnen (CPU, ûnthâld).
• Grutte fan bewarre blobs.
• Wurkje mei S3.
• Yntegriteit kontrôle.

Foar testen namen wy ien kliïnt mei echte gegevens en in totale grutte fan 1,6 TB.
Betingsten.

Borg wit net hoe om te wurkjen direkt mei S3, en wy mounted de skiif as in fuse, fia goofys. Restic stjoerde it nei S3 sels.

Goofys wurket hiel fluch en goed, en der binne disk cache module, wat it wurk noch mear fersnelt. It is yn 'e beta-stadium, en, earlik sein, ferûngelokke wy mei gegevensferlies tidens testen (oaren). Mar it gemak is dat de reservekopyproseduere sels net folle lêzen fereasket, mar meast skriuwen, dus wy brûke de cache allinich by yntegriteitskontrôles.

Om de ynfloed fan it netwurk te ferminderjen, brûkten wy in lokale provider - Yandex Cloud.

Fergeliking testresultaten.

• Kill -9 mei in fierdere trochstart wiene beide suksesfol.
• Grutte op skiif. Borg kin komprimearje, sadat de resultaten binne lykas ferwachte.

Backuper
grutte

Borg
562Gb

Restyk
628Gb

• Troch CPU
  Borg sels ferbrûkt bytsje, mei standert kompresje, mar it moat wurde evaluearre tegearre mei de goofys proses. Yn totaal binne se fergelykber en brûke sawat 1,2 kearnen op deselde test firtuele masine.
• Oantinken. Restic is likernôch 0,5GB, Borg is likernôch 200MB. Mar dit is allegear ûnbelangryk yn ferliking mei it cache fan it systeembestân. Sa is it oan te rieden om mear ûnthâld te jaan.
• It ferskil yn blobgrutte wie opfallend.

Backuper
grutte

Borg
oer 500MB

Restyk
oer 5MB

• De S3-ûnderfining fan Restic is poerbêst. Wurkje mei Borg fia goofys ropt gjin fragen op, mar it is opmurken dat it oan te rieden is om umount te dwaan neidat de reservekopy foltôge is om de cache folslein werom te setten. De eigenaardichheid fan S3 is dat ûnder-pompte brokken nea nei de bak stjoerd wurde, wat betsjut dat ûnfolslein ynfolle gegevens liede ta grutte skea.
• De yntegriteitskontrôle wurket yn beide gefallen goed, mar de snelheid ferskilt signifikant.
  Restic 3,5 oeren.
  Borg, mei in 100GB SSD-bestâncache - 5 oeren.Ongefear deselde snelheid resultaat as de gegevens op in lokale skiif.
  Borg lêst direkt út S3 sûnder cache 33 oeren. Monster lang.

De ûnderste line is dat Borg kin compress en hat gruttere blobs - dat makket opslach en GET / PUT operaasjes yn S3 goedkeaper. Mar dit komt ten koste fan kompleksere en stadiger ferifikaasje. Wat de herstelsnelheid oanbelanget, hawwe wy gjin ferskil opmurken. Restic nimt de folgjende backups (nei de earste) wat langer, mar net signifikant.

Last but not least yn de kar wie de grutte fan de mienskip.

En wy hawwe foar borg keazen.

In pear wurden oer kompresje

Borg hat in poerbêste nij kompresje algoritme yn syn arsenal - zstd. De kompresjekwaliteit is net slimmer dan gzip, mar folle rapper. En fergelykber yn snelheid mei de standert lz4.

Bygelyks, in MySQL-database-dump wurdt twa kear better komprimearre as lz4 mei deselde snelheid. Underfining mei echte gegevens lit lykwols sjen dat d'r heul lyts ferskil is yn 'e kompresjeferhâlding fan' e Nextcloud-knooppunt.

Borg hat in nochal bonus kompresje modus - as de triem hat hege entropy, dan kompresje wurdt net tapast hielendal, dat fergruttet de snelheid. Ynskeakele troch opsje by it meitsjen
-C auto,zstd
foar it zstd-algoritme
Dus mei dizze opsje, yn ferliking mei de standert kompresje, hawwe wy krigen
560Gb en 562Gb respektivelik. De gegevens út it foarbyld hjirboppe, lit my jo herinnerje, sûnder kompresje is it resultaat 628Gb. It resultaat fan in 2GB-ferskil ferraste ús wat, mar wy tochten dat wy it nei alle gedachten soene kieze. auto,zstd.

Backup ferifikaasje metoade

Neffens de planner wurdt de firtuele masine direkt fan 'e provider of fan' e kliïnt lansearre, wat de netwurklast sterk ferminderet. It is teminsten goedkeaper dan it sels te ferheegjen en ferkear te riden.

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/

Mei itselde skema kontrolearje wy bestannen mei in antyvirus (nei it feit). Ommers, brûkers uploade ferskillende dingen nei Nextcloud en net elkenien hat in antivirus. It útfieren fan ynspeksjes op it momint fan it skinen nimt te folle tiid en bemuoit it bedriuw.

Skalberens wurdt berikt troch runners op ferskate knopen mei ferskate tags te rinnen.
Us tafersjoch sammelt reservekopystatusen fia de GitLab API yn ien finster; as it nedich is, wurde problemen maklik opmurken en like maklik lokalisearre.

konklúzje

As gefolch, wy witte wis dat wy meitsje backups, dat ús backups binne jildich, problemen dy't ûntsteane mei harren nimme bytsje tiid en wurde oplost op it nivo fan de plicht behearder. Reservekopy nimme echt bytsje romte yn fergeliking mei tar.gz of Bacula.

Boarne: www.habr.com