Hvernig GitLab hjálpar þér að taka öryggisafrit af stórum NextCloud geymslum

Hæ Habr!

Í dag vil ég tala um reynslu okkar af því að gera sjálfvirkan öryggisafrit af stórum gögnum frá Nextcloud geymslum í mismunandi stillingum. Ég vinn sem þjónustustöð hjá Molniya AK, þar sem við gerum stillingarstjórnun á upplýsingatæknikerfum; Nextcloud er notað fyrir gagnageymslu. Þar á meðal, með dreifðri uppbyggingu, með offramboði.

Vandamálin sem stafa af eiginleikum uppsetninganna eru að það er mikið af gögnum. Útgáfuútgáfa frá Nextcloud, offramboð, huglægar ástæður og fleira skapar margar afrit.

Forsaga

Þegar Nextcloud er stjórnað kemur upp vandamálið við að skipuleggja skilvirkt öryggisafrit, sem verður að vera dulkóðað, þar sem gögnin eru verðmæt.

Við bjóðum upp á möguleika til að geyma afrit hjá okkur eða hjá viðskiptavininum á aðskildum vélum frá Nextcloud, sem krefst sveigjanlegrar sjálfvirkrar nálgunar við stjórnun.

Það eru margir viðskiptavinir, allir með mismunandi stillingar, og allir á sínum eigin síðum og með eigin einkenni. Þetta er staðlað tækni þegar öll vefsvæðið tilheyrir þér og afrit eru gerð úr krónum; það passar ekki vel.

Fyrst skulum við skoða inntaksgögnin. Við þurfum:

• Sveigjanleiki hvað varðar einn hnút eða nokkra. Fyrir stórar uppsetningar notum við minio sem geymslu.
• Finndu út um vandamál við að framkvæma öryggisafrit.
• Þú þarft að hafa öryggisafrit hjá viðskiptavinum þínum og/eða hjá okkur.
• Tökum á vandamálum fljótt og auðveldlega.
• Viðskiptavinir og uppsetningar eru mjög ólíkar hver öðrum - einsleitni er ekki hægt að ná.
• Endurheimtarhraði ætti að vera í lágmarki í tveimur tilfellum: fullum bata (hörmung), einni möppu eytt fyrir mistök.
• Aftvíföldunaraðgerð er krafist.

Til að leysa vandamálið við að stjórna afritum settum við upp GitLab. Nánari upplýsingar eftir tæklingu.

Við erum auðvitað ekki þau fyrstu til að leysa slíkt vandamál, en okkur sýnist að hagnýt, erfið reynsla okkar geti verið áhugaverð og við erum tilbúin að miðla henni.

Þar sem fyrirtækið okkar er með opinn uppspretta stefnu, vorum við að leita að opnum uppspretta lausn. Aftur á móti deilum við þróun okkar og birtum hana. Til dæmis, á GitHub er viðbótin okkar fyrir Nextcloud, sem við veitum viðskiptavinum og eykur gagnaöryggi ef eytt er fyrir slysni eða af ásetningi.

Afritunarverkfæri

Við hófum leit okkar að lausnaraðferðum með því að velja tæki til að búa til öryggisafrit.

Venjulegur tar + gzip virkar ekki vel - gögnin eru afrituð. Aukning inniheldur oft mjög fáar raunverulegar breytingar og mikið af gögnum í einni skrá er endurtekið.
Það er annað vandamál - offramboð á dreifðri gagnageymslu. Við notum minio og gögn þess eru í grundvallaratriðum óþörf. Eða þú þurftir að taka öryggisafrit í gegnum minio sjálft - hlaða því og nota öll bil á milli skráarkerfisins, og ekki síður mikilvægt, það er hætta á að gleyma sumum fötunum og meta-upplýsingunum. Eða notaðu tvítekningu.

Afritunarverkfæri með fjölföldun eru fáanleg í opnum hugbúnaði (á Habré voru það Grein um þetta þema) og úrslitakeppendur okkar voru Borg и Restic. Samanburður okkar á umsóknunum tveimur er hér að neðan, en í bili munum við segja þér hvernig við skipulögðum allt kerfið.

Umsjón með afritum

Borg og Restic eru góðar, en hvorug vara hefur miðstýrðan stjórnbúnað. Í þeim tilgangi að stjórna og stjórna völdum við tól sem við höfum þegar innleitt, án þess getum við ekki ímyndað okkur vinnu okkar, þar á meðal sjálfvirkni - þetta er hið vel þekkta CI/CD - GitLab.

Hugmyndin er sem hér segir: gitlab-runner er settur upp á hverjum hnút sem geymir Nextcloud gögn. Hlauparinn keyrir handrit á áætlun sem fylgist með afritunarferlinu og það ræsir Borg eða Restic.

Hvað fengum við? Viðbrögð frá framkvæmd, þægileg stjórn á breytingum, upplýsingar ef villur koma upp.

Hér hér á GitHub við birtum dæmi um handritið fyrir ýmis verkefni og enduðum með því að hengja það við öryggisafritið á ekki aðeins Nextcloud, heldur einnig mörgum öðrum þjónustum. Það er líka tímaáætlun þar ef þú vilt ekki stilla hann handvirkt (og við viljum ekki) og .gitlab-ci.yml

Það er engin leið til að breyta CI/CD tímamörkum í Gitlab API ennþá, en það er lítið. Það þarf að auka það, segjum við 1d.

GitLab, sem betur fer, getur ræst ekki aðeins samkvæmt skuldbindingu, heldur aðeins samkvæmt áætlun, þetta er nákvæmlega það sem við þurfum.

Nú um umbúðahandritið.

Við setjum eftirfarandi skilyrði fyrir þetta handrit:

• Það ætti að vera ræst bæði af hlauparanum og með hendi frá stjórnborðinu með sömu virkni.
• Það verða að vera villumeðferðaraðilar:
• skilakóða.
• leitaðu að streng í skránni. Til dæmis, fyrir okkur getur villa verið skilaboð sem forritið telur ekki banvænt.
• Vinnslutími. Afgreiðslutími verður að vera sanngjarn.
• Við þurfum mjög ítarlegan dagbók. En aðeins ef um villu er að ræða.
• Einnig eru gerðar nokkrar prófanir áður en byrjað er.
• Litlir bónusar til þæginda sem okkur fannst gagnlegir í stuðningsferlinu:
• Upphaf og endir eru skráðir í kerfisskrá staðbundinnar vélar. Þetta hjálpar til við að tengja kerfisvillur og öryggisafrit.
• Hluti af villuskránni, ef einhver er, er settur út í stdout, allur annálinn er skrifaður í sérstaka skrá. Það er þægilegt að skoða CI strax og meta villuna ef hún er léttvæg.
• Villuleitarstillingar.

Fullur annálinn er vistaður sem gripur í GitLab; ef það er engin villa er skránni eytt. Við skrifum handritið í bash.

Við munum vera fús til að íhuga allar tillögur og athugasemdir varðandi opinn uppspretta - velkomið.

Hvernig virkar þetta

Hlaupari með Bash executor er ræstur á afritunarhnútinn. Samkvæmt tímaáætlun er starf CI/CD hleypt af stokkunum í sérstakri rófu. Hlauparinn setur af stað universal wrapper script fyrir slík verkefni, það athugar gildi öryggisafritageymslunnar, tengipunkta og allt sem við viljum, tekur svo öryggisafrit og hreinsar það gamla upp. Lokið öryggisafrit sjálft er sent til S3.

Við vinnum samkvæmt þessu kerfi - það er utanaðkomandi AWS veitir eða rússneskt jafngildi (það er hraðara og gögnin fara ekki frá Rússlandi). Eða við setjum upp sérstakan smáþyrping fyrir viðskiptavininn á síðunni hans í þessum tilgangi. Við gerum þetta venjulega af öryggisástæðum, þegar viðskiptavinurinn vill alls ekki að gögnin fari út úr hringrásinni sinni.

Við notuðum ekki þann eiginleika að senda öryggisafrit í gegnum ssh. Þetta bætir ekki við öryggi og netgeta S3 veitunnar er miklu meiri en ssh vélin okkar.

Til að vernda staðbundna vélina þína fyrir tölvuþrjóta, þar sem hann getur eytt gögnum á S3, verður þú að virkja útgáfuútgáfu.
Afritið dulkóðar alltaf öryggisafritið.

Borg er með ódulkóðaðan hátt none, en við mælum eindregið ekki með því að kveikja á því. Í þessum ham verður ekki aðeins engin dulkóðun, heldur er tékksumman þess sem verið er að skrifa ekki reiknuð út, sem þýðir að aðeins er hægt að athuga heilleika óbeint með því að nota vísitölur.

Sérstakur tímaáætlun athugar afrit fyrir heilleika vísitölu og efnis. Athugunin er hæg og löng, svo við keyrum hana sérstaklega einu sinni í mánuði. Það getur tekið nokkra daga.

Readme á rússnesku

Helstu aðgerðir

• prepare þjálfun
• testcheck viðbúnaðarathugun
• maincommand kjarna lið
• forcepostscript fall sem er keyrt í lokin eða með villu. Við notum það til að aftengja skiptinguna.

Þjónustuaðgerðir

• cleanup Við skráum villur eða eyðum skránni.
• checklog flokka skrána fyrir tilvik línu með villu.
• ret útgöngustjóri.
• checktimeout athugaðu hvort tíminn er liðinn.

umhverfi

• VERBOSE=1 Við birtum villur á skjánum strax (stdout).
• SAVELOGSONSUCCES=1 vistaðu annálinn þegar vel tekst til.
• INIT_REPO_IF_NOT_EXIST=1 Búðu til geymslu ef hún er ekki til. Sjálfgefið óvirkt.
• TIMEOUT hámarkstími fyrir aðalaðgerðina. Þú getur stillt það sem 'm', 'h' eða 'd' í lokin.

Geymslustilling fyrir gömul eintök. Sjálfgefið:

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

Breytur inni í handritinu

• ERROR_STRING — strengur fyrir innritunarskrána fyrir villu.
• EXTRACT_ERROR_STRING — tjáning fyrir sýna streng ef villa.
• KILL_TIMEOUT_SIGNAL — merki um að drepa ef tími er liðinn.
• TAIL — hversu margir strengir með villum á skjánum.
• COLORMSG — litur skilaboða (sjálfgefinn gulur).

Það handrit, sem kallast wordpress, hefur skilyrt nafn, bragð þess er að það tekur líka afrit af mysql gagnagrunninum. Þetta þýðir að hægt er að nota það fyrir einshnúta Nexcloud uppsetningar, þar sem þú getur líka tekið öryggisafrit af gagnagrunninum. Þægindin felast ekki aðeins í því að allt er á einum stað, heldur er innihald gagnagrunnsins nálægt innihaldi skránna, þar sem tímamunurinn er lítill.

Restic vs Borg

Það er líka samanburður á Borg og Restic hér á Habré, og við höfðum ekki það verkefni að búa til bara annan, heldur okkar eigin. Það var mikilvægt fyrir okkur hvernig það myndi líta út á gögnum okkar, með sérstöðu okkar. Við komum með þau.

Valviðmiðin okkar, til viðbótar þeim sem þegar hafa verið nefnd (aftvíföldun, hraður bati osfrv.):

• Viðnám gegn óunnið verk. Athugaðu hvort drepið sé -9.
• Stærð á diski.
• Krafa um auðlindir (CPU, minni).
• Stærð geymdra kubba.
• Að vinna með S3.
• Heildarskoðun.

Til prófunar tókum við einn viðskiptavin með raunverulegum gögnum og heildarstærð 1,6 TB.
Skilyrði.

Borg kann ekki að vinna beint með S3, og við festum diskinn sem öryggi, í gegnum fífl. Restic sendi það til S3 sjálfs.

Goofys virkar mjög fljótt og vel, og það eru til disk skyndiminni mát, sem flýtir verkinu enn meira. Það er á beta stigi og í hreinskilni sagt hrundum við með gagnatap í prófunum (önnur). En þægindin eru að öryggisafritunarferlið sjálft krefst ekki mikils lesturs, heldur aðallega skrifs, þannig að við notum skyndiminni aðeins við heilleikaathuganir.

Til að draga úr áhrifum netsins notuðum við staðbundinn þjónustuaðila - Yandex Cloud.

Niðurstöður samanburðarprófa.

• Kill -9 með frekari endurræsingu tókst bæði.
• Stærð á diski. Borg getur þjappað saman þannig að útkoman er eins og búist var við.

Varamaður
Stærð

Borg
562Gb

Restic
628Gb

• Með CPU
  Borg sjálf eyðir litlu, með sjálfgefna þjöppun, en það verður að meta það ásamt guffaferlinu. Alls eru þeir sambærilegir og nota um 1,2 kjarna á sömu sýndarvélinni.
• Minni. Restic er um það bil 0,5GB, Borg er um það bil 200MB. En þetta er allt óverulegt miðað við skyndiminni kerfisskráa. Svo það er ráðlegt að úthluta meira minni.
• Munurinn á stærð kubbanna var sláandi.

Varamaður
Stærð

Borg
um 500MB

Restic
um 5MB

• S3 reynsla Restic er frábær. Að vinna með Borg í gegnum goofys vekur engar spurningar, en það hefur verið tekið fram að það er ráðlegt að gera umount eftir að öryggisafritinu er lokið til að endurstilla skyndiminni algjörlega. Sérkenni S3 er að vandældir bitar verða aldrei sendir í fötuna, sem þýðir að ófullnægjandi gögn leiða til mikils tjóns.
• Heildarathugunin virkar vel í báðum tilvikum, en hraðinn er verulega frábrugðinn.
  Restic 3,5 klst.
  Borg, með 100GB SSD skráarskyndiminni - 5 klst.Um það bil sama hraði ef gögnin eru á staðbundnum diski.
  Borg les beint úr S3 án skyndiminni 33 klst. Ótrúlega langur.

Niðurstaðan er sú að Borg getur þjappað saman og er með stærri klossa - sem gerir geymslu og GET/PUT aðgerðir í S3 ódýrari. En þetta kostar flóknari og hægari sannprófun. Hvað batahraðann varðar þá tókum við ekki eftir neinum mun. Restic tekur síðari öryggisafrit (eftir það fyrsta) aðeins lengur, en ekki verulega.

Síðast en ekki síst í valinu var stærð samfélagsins.

Og við völdum borg.

Nokkur orð um þjöppun

Borg er með frábært nýtt þjöppunaralgrím í vopnabúrinu sínu - zstd. Þjöppunargæðin eru ekki verri en gzip, en mun hraðari. Og sambærilegur í hraða við sjálfgefna lz4.

Til dæmis er MySQL gagnagrunnsdump þjappað tvisvar sinnum betur en lz4 á sama hraða. Hins vegar sýnir reynsla af raunverulegum gögnum að það er mjög lítill munur á þjöppunarhlutfalli Nextcloud hnútsins.

Borg er með frekar bónus þjöppunarstillingu - ef skráin hefur mikla óreiðu, þá er þjöppun alls ekki beitt, sem eykur hraðann. Virkt með valkosti þegar búið er til
-C auto,zstd
fyrir zstd reikniritið
Svo með þennan valkost, í samanburði við sjálfgefna þjöppun, fengum við
560Gb og 562Gb í sömu röð. Gögnin úr dæminu hér að ofan, minnir mig, án þjöppunar er niðurstaðan 628Gb. Niðurstaðan af 2GB mun kom okkur nokkuð á óvart, en við héldum að við myndum velja það eftir allt saman. auto,zstd.

Aðferð til að staðfesta öryggisafrit

Samkvæmt tímaáætluninni er sýndarvélin ræst beint frá veitunni eða frá viðskiptavininum, sem dregur verulega úr netálagi. Að minnsta kosti er það ódýrara en að hækka það sjálfur og keyra umferð.

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ð sama kerfi athugum við skrár með vírusvarnarforriti (eftir staðreynd). Þegar öllu er á botninn hvolft hlaða notendum upp mismunandi hlutum á Nextcloud og það eru ekki allir með vírusvörn. Það tekur of mikinn tíma að framkvæma skoðanir á upphellingu og truflar viðskiptin.

Sveigjanleiki er náð með því að keyra hlaupara á mismunandi hnútum með mismunandi merki.
Vöktun okkar safnar öryggisafritunarstöðu í gegnum GitLab API í einum glugga; ef nauðsyn krefur er auðvelt að taka eftir vandamálum og jafn auðveldlega staðsetja þau.

Ályktun

Þar af leiðandi vitum við fyrir víst að við gerum afrit, að öryggisafritin okkar eru gild, vandamál sem upp koma við þau taka lítinn tíma og eru leyst á vettvangi vaktstjóra. Afrit taka mjög lítið pláss miðað við tar.gz eða Bacula.

Heimild: www.habr.com