Ako vám GitLab pomáha zálohovať veľké úložiská NextCloud

Čau Habr!

Dnes chcem hovoriť o našich skúsenostiach s automatizáciou zálohovania veľkých dát z úložísk Nextcloud v rôznych konfiguráciách. Pracujem ako servis v Molniya AK, kde robíme konfiguračný manažment IT systémov, Nextcloud slúži na ukladanie dát. Vrátane, s distribuovanou štruktúrou, s redundanciou.

Problémy vyplývajúce z vlastností inštalácií spočívajú v tom, že existuje veľa údajov. Verzia poskytovaná Nextcloud, redundancia, subjektívne dôvody a ďalšie vytvárajú veľa duplikátov.

pravek

Pri administrácii Nextcloudu vzniká problém zorganizovať efektívnu zálohu, ktorá musí byť šifrovaná, keďže dáta sú cenné.

Ponúkame možnosti ukladania záloh u nás alebo u zákazníka na samostatných strojoch od Nextcloud, čo si vyžaduje flexibilný automatizovaný prístup k správe.

Existuje veľa klientov, všetci s rôznymi konfiguráciami a všetci na svojich vlastných stránkach a s vlastnými charakteristikami. Toto je štandardná technika, keď celá stránka patrí vám a zálohy sa robia z korún; nesedí to dobre.

Najprv sa pozrime na vstupné údaje. Potrebujeme:

• Škálovateľnosť z hľadiska jedného alebo viacerých uzlov. Pre veľké inštalácie používame minio ako úložisko.
• Zistite o problémoch s vykonávaním zálohovania.
• Musíte mať zálohu u svojich klientov a/alebo u nás.
• Vyrovnajte sa s problémami rýchlo a jednoducho.
• Klienti a inštalácie sa navzájom veľmi líšia - nemožno dosiahnuť jednotnosť.
• Rýchlosť obnovy by mala byť minimálna v dvoch scenároch: úplné obnovenie (katastrofa), jeden priečinok bol omylom vymazaný.
• Vyžaduje sa funkcia deduplikácie.

Aby sme vyriešili problém so správou záloh, nainštalovali sme GitLab. Viac podrobností pri riešení.

Samozrejme, nie sme prví, ktorí riešia takýto problém, no zdá sa nám, že naše praktické, ťažko nadobudnuté skúsenosti môžu byť zaujímavé a sme pripravení sa o ne podeliť.

Keďže naša spoločnosť má politiku open source, hľadali sme riešenie s otvoreným zdrojom. Na druhej strane zdieľame náš vývoj a uverejňujeme ho. Napríklad na GitHub existuje náš plugin pre Nextcloud, ktoré poskytujeme klientom, čím zvyšujeme bezpečnosť údajov v prípade náhodného alebo úmyselného vymazania.

Zálohovacie nástroje

Naše hľadanie metód riešenia sme začali výberom nástroja na vytváranie záloh.

Bežný tar + gzip nefunguje dobre - údaje sú duplikované. Prírastok často obsahuje veľmi málo skutočných zmien a veľká časť údajov v rámci jedného súboru sa opakuje.
Je tu ďalší problém – redundancia distribuovaného úložiska dát. Používame minio a jeho dáta sú v podstate nadbytočné. Alebo ste museli urobiť zálohu cez samotné minio - načítať ju a použiť všetky medzery medzi súborovým systémom, a čo je nemenej dôležité, existuje riziko zabudnutia na niektoré vedrá a metainformácie. Alebo použite deduplikáciu.

Zálohovacie nástroje s duplikáciou sú dostupné v open source (na Habré boli Článok na túto tému) a naši finalisti boli Borg и Vidiecky. Naše porovnanie týchto dvoch aplikácií je uvedené nižšie, ale zatiaľ vám povieme, ako sme celú schému zorganizovali.

Správa záloh

Borg a Restic sú dobré, ale ani jeden produkt nemá centralizovaný mechanizmus kontroly. Pre účely riadenia a kontroly sme zvolili nástroj, ktorý už máme implementovaný, bez ktorého si našu prácu vrátane automatizácie nevieme predstaviť - ide o známy CI/CD - GitLab.

Myšlienka je nasledovná: gitlab-runner je nainštalovaný na každom uzle, ktorý ukladá dáta Nextcloud. Bežec spustí skript podľa plánu, ktorý monitoruje proces zálohovania, a spustí Borg alebo Restic.

čo sme dostali? Spätná väzba od vykonania, pohodlná kontrola nad zmenami, detaily v prípade chyby.

Tu tu na GitHub zverejnili sme príklady skriptu pre rôzne úlohy a nakoniec sme ho pripojili k zálohe nielen Nextcloudu, ale aj mnohých ďalších služieb. Je tam aj plánovač, ak ho nechcete konfigurovať ručne (a my nechceme) a .gitlab-ci.yml

V Gitlab API zatiaľ nie je možné zmeniť časový limit CI/CD, ale je malý. Treba ho zvýšiť, povedzme 1d.

GitLab, našťastie, dokáže spustiť nielen podľa commitu, ale iba podľa harmonogramu, presne to potrebujeme.

Teraz o obalovom skripte.

Pre tento skript sme nastavili nasledujúce podmienky:

• Mal by sa spúšťať bežcom aj ručne z konzoly s rovnakou funkcionalitou.
• Musia existovať obslužné nástroje chýb:
• návratový kód.
• vyhľadajte reťazec v protokole. Pre nás môže byť chybou napríklad správa, ktorú program nepovažuje za fatálnu.
• Časový limit spracovania. Dodacia lehota musí byť primeraná.
• Potrebujeme veľmi podrobný denník. Ale len v prípade chyby.
• Pred spustením sa tiež vykoná niekoľko testov.
• Malé bonusy pre pohodlie, ktoré sme považovali za užitočné počas procesu podpory:
• Začiatok a koniec sú zaznamenané v syslog lokálneho počítača. To pomáha pri spájaní systémových chýb a zálohovania.
• Časť protokolu chýb, ak existuje, sa odošle do stdout, celý protokol sa zapíše do samostatného súboru. Je vhodné okamžite sa pozrieť na CI a vyhodnotiť chybu, ak je triviálna.
• Režimy ladenia.

Celý protokol sa uloží ako artefakt v GitLab; ak nedôjde k chybe, protokol sa vymaže. Scenár píšeme v bash.

Radi zvážime akékoľvek návrhy a pripomienky týkajúce sa open source – vítame vás.

Ako to funguje

Na záložnom uzle sa spustí bežec s vykonávačom Bash. Podľa plánovača sa úloha CI/CD spustí v špeciálnej repke. Runner pre takéto úlohy spustí univerzálny wrapper skript, skontroluje platnosť záložného úložiska, body pripojenia a všetko, čo chceme, potom zálohuje a vyčistí ten starý. Samotná hotová záloha sa odošle do S3.

Pracujeme podľa tejto schémy - je to externý poskytovateľ AWS alebo ruský ekvivalent (je to rýchlejšie a dáta neopúšťajú Ruskú federáciu). Alebo klientovi na jeho stránku na tieto účely nainštalujeme samostatný minio cluster. Väčšinou to robíme z bezpečnostných dôvodov, keď klient vôbec nechce, aby dáta opustili jeho okruh.

Funkciu posielania zálohy cez ssh sme nevyužili. To nepridáva bezpečnosť a sieťové možnosti poskytovateľa S3 sú oveľa vyššie ako náš jeden ssh stroj.

Aby ste ochránili svoj lokálny počítač pred hackerom, keďže môže vymazať údaje na S3, musíte povoliť vytváranie verzií.
Záloha vždy zašifruje zálohu.

Borg má nešifrovaný režim none, ale dôrazne ho neodporúčame zapínať. V tomto režime nielenže nebude existovať žiadne šifrovanie, ale nevypočítava sa ani kontrolný súčet toho, čo sa zapisuje, čo znamená, že integritu možno kontrolovať iba nepriamo pomocou indexov.

Samostatný plánovač kontroluje zálohy na integritu indexov a obsahu. Kontrola je pomalá a dlhá, preto ju spúšťame samostatne raz za mesiac. Môže to trvať niekoľko dní.

Readme v ruštine

Hlavné funkcie

• prepare tréning
• testcheck kontrola pripravenosti
• maincommand jadro tímu
• forcepostscript funkcia, ktorá sa vykoná na konci alebo chybne. Používame ho na odpojenie oddielu.

Servisné funkcie

• cleanup Zaznamenávame chyby alebo vymažeme súbor denníka.
• checklog analyzovať protokol o výskyte riadku s chybou.
• ret výstupný manipulátor.
• checktimeout skontrolujte časový limit.

prostredie

• VERBOSE=1 Chyby okamžite zobrazíme na obrazovke (stdout).
• SAVELOGSONSUCCES=1 po úspechu uložte denník.
• INIT_REPO_IF_NOT_EXIST=1 Vytvorte úložisko, ak neexistuje. Predvolene vypnuté.
• TIMEOUT maximálny čas na hlavnú operáciu. Na konci ho môžete nastaviť ako „m“, „h“ alebo „d“.

Režim ukladania starých kópií. Predvolená hodnota:

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

Premenné vo vnútri skriptu

• ERROR_STRING — reťazec pre protokol kontroly chýb.
• EXTRACT_ERROR_STRING — výraz pre zobrazenie reťazca v prípade chyby.
• KILL_TIMEOUT_SIGNAL — signál na zabitie, ak uplynie časový limit.
• TAIL — koľko reťazcov s chybami na obrazovke.
• COLORMSG — farba správy (predvolená žltá).

Tento skript, ktorý sa nazýva wordpress, má podmienený názov, jeho trik je v tom, že zálohuje aj databázu mysql. To znamená, že môže byť použitý pre jednouzlové inštalácie Nexcloud, kde môžete tiež zálohovať databázu. Výhodou je nielen to, že je všetko na jednom mieste, ale aj obsah databázy je blízky obsahu súborov, keďže časový rozdiel je minimálny.

Restic vs Borg

Existujú aj porovnania medzi Borgom a Resticom tu na Habréa nemali sme za úlohu vyrobiť len ďalší, ale vlastný. Bolo pre nás dôležité, ako to bude vyzerať na našich dátach, s našimi špecifikami. My ich prinášame.

Naše výberové kritériá, okrem už spomenutých (deduplikácia, rýchle zotavenie atď.):

• Odolnosť voči nedokončenej práci. Skontrolujte zabitie -9.
• Veľkosť na disku.
• Požiadavka na zdroje (CPU, pamäť).
• Veľkosť uložených guľôčok.
• Práca s S3.
• Kontrola integrity.

Na testovanie sme zobrali jedného klienta s reálnymi dátami a celkovou veľkosťou 1,6 TB.
Podmienky.

Borg nevie pracovať priamo s S3 a disk sme namontovali ako poistku, cez goofys. Restic to poslal do S3 sám.

Goofys funguje veľmi rýchlo a dobre a takých je modul vyrovnávacej pamäte disku, čo prácu ešte urýchli. Je vo fáze beta a úprimne povedané, počas testov (iné) sme havarovali so stratou údajov. Výhodou však je, že samotná procedúra zálohovania nevyžaduje veľa čítania, ale väčšinou zápisu, takže vyrovnávaciu pamäť používame iba pri kontrolách integrity.

Na zníženie vplyvu siete sme použili miestneho poskytovateľa - Yandex Cloud.

Výsledky porovnávacích testov.

• Kill -9 s ďalším reštartom boli úspešné.
• Veľkosť na disku. Borg môže komprimovať, takže výsledky sú podľa očakávania.

Backuper
Veľkosť

Borg
562Gb

Vidiecky
628Gb

• Podľa CPU
  Borg sám spotrebuje málo, s predvolenou kompresiou, ale musí byť vyhodnotený spolu s goofys procesom. Celkovo sú porovnateľné a využívajú približne 1,2 jadra na rovnakom testovacom virtuálnom stroji.
• Pamäť. Restic má približne 0,5 GB, Borg približne 200 MB. Ale to všetko je bezvýznamné v porovnaní s vyrovnávacou pamäťou systémových súborov. Preto je vhodné vyčleniť viac pamäte.
• Rozdiel vo veľkosti blob bol markantný.

Backuper
Veľkosť

Borg
asi 500 MB

Vidiecky
asi 5 MB

• Skúsenosti s Restic's S3 sú vynikajúce. Práca s Borgom cez goofys nevyvoláva žiadne otázky, ale bolo poznamenané, že je vhodné vykonať umount po dokončení zálohy, aby sa úplne vynulovala vyrovnávacia pamäť. Zvláštnosťou S3 je, že nedostatočne načerpané kúsky sa nikdy neodošlú do vedra, čo znamená, že neúplne vyplnené údaje vedú k veľkým škodám.
• Kontrola integrity funguje v oboch prípadoch dobre, ale rýchlosť sa výrazne líši.
  Restic 3,5 hodín.
  Borg, so 100 GB vyrovnávacou pamäťou SSD – 5 hodín.Približne rovnaký výsledok rýchlosti, ak sú dáta na lokálnom disku.
  Borg číta priamo z S3 bez vyrovnávacej pamäte 33 hodín. Obludne dlhé.

Pointa je, že Borg môže komprimovať a má väčšie guličky – vďaka čomu je ukladanie a operácie GET/PUT v S3 lacnejšie. To však prichádza za cenu zložitejšieho a pomalšieho overovania. Čo sa týka rýchlosti obnovy, nezaznamenali sme žiadny rozdiel. Restic trvá následné zálohy (po prvej) trochu dlhšie, ale nie výrazne.

V neposlednom rade pri výbere bola veľkosť komunity.

A vybrali sme si borg.

Pár slov o kompresii

Borg má vo svojom arzenáli vynikajúci nový kompresný algoritmus - zstd. Kvalita kompresie nie je horšia ako gzip, ale oveľa rýchlejšia. A rýchlosť je porovnateľná s predvoleným lz4.

Napríklad výpis databázy MySQL je komprimovaný dvakrát lepšie ako lz4 pri rovnakej rýchlosti. Skúsenosti s reálnymi dátami však ukazujú, že v kompresnom pomere uzla Nextcloud je veľmi malý rozdiel.

Borg má skôr bonusový režim kompresie – ak má súbor vysokú entropiu, tak sa kompresia vôbec neuplatňuje, čo zvyšuje rýchlosť. Povolené možnosťou pri vytváraní
-C auto,zstd
pre algoritmus zstd
Takže s touto možnosťou sme v porovnaní s predvolenou kompresiou dostali
560 Gb a 562 Gb. Dáta z vyššie uvedeného príkladu pripomínam, bez kompresie je výsledkom 628Gb. Výsledok 2GB rozdielu nás trochu prekvapil, ale mysleli sme si, že si ho predsa len vyberieme. auto,zstd.

Metóda overenia zálohy

Podľa plánovača sa virtuálny stroj spúšťa priamo od poskytovateľa alebo od klienta, čo výrazne znižuje zaťaženie siete. Prinajmenšom je to lacnejšie, ako si to sami navyšovať a riadiť premávku.

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/

Pomocou rovnakej schémy kontrolujeme súbory antivírusom (po skutočnosti). Koniec koncov, používatelia nahrávajú na Nextcloud rôzne veci a nie každý má antivírus. Vykonávanie kontrol v čase nalievania zaberá príliš veľa času a zasahuje do podnikania.

Škálovateľnosť sa dosahuje spustením bežcov na rôznych uzloch s rôznymi značkami.
Naše monitorovanie zhromažďuje stavy zálohovania cez GitLab API v jednom okne; v prípade potreby sa problémy dajú ľahko zistiť a rovnako ľahko lokalizovať.

Záver

Vďaka tomu s istotou vieme, že zálohy robíme, že naše zálohy sú platné, problémy, ktoré s nimi vzniknú, zaberú málo času a riešia sa na úrovni správcu povinností. Zálohy zaberajú naozaj málo miesta v porovnaní s tar.gz alebo Bacula.

Zdroj: hab.com