Jak vám GitLab pomáhá zálohovat velká úložiště NextCloud

Čau Habr!

Dnes chci mluvit o našich zkušenostech s automatizací zálohování velkých dat z úložišť Nextcloud v různých konfiguracích. Pracuji jako servisní stanice v Molniya AK, kde děláme konfigurační management IT systémů, pro ukládání dat slouží Nextcloud. Včetně, s distribuovanou strukturou, s redundancí.

Problémy vyplývající z vlastností instalací spočívají v tom, že existuje mnoho dat. Verze poskytované Nextcloud, redundance, subjektivní důvody a další vytváří mnoho duplikátů.

pravěk

Při správě Nextcloud vyvstává problém s organizací efektivní zálohy, která musí být šifrována, protože data jsou cenná.

Nabízíme možnosti pro ukládání záloh u nás nebo u zákazníků na strojích oddělených od NextCloud, což vyžaduje flexibilní automatizovaný přístup k správě.

Existuje mnoho klientů, všichni s různými konfiguracemi a všichni na svých vlastních stránkách a se svými vlastními vlastnostmi. Jedná se o standardní techniku, kdy celý web patří vám a zálohy jsou vytvořeny z korun; nesedí dobře.

Для начала посмотрим на вводные данные. Potřebujeme:

• Škálovatelnost z hlediska jednoho nebo několika uzlů. Pro velké instalace používáme minio jako úložiště.
• Informujte se o problémech s prováděním zálohování.
• Musíte mít zálohu u svých klientů a/nebo u nás.
• Vypořádejte se s problémy rychle a snadno.
• Klienti a instalace se od sebe velmi liší – nelze dosáhnout jednotnosti.
• Rychlost obnovy by měla být minimální ve dvou scénářích: úplná obnova (katastrofa), jedna složka byla omylem vymazána.
• Je vyžadována funkce deduplikace.

Abychom vyřešili problém se správou záloh, nainstalovali jsme GitLab. Více podrobností při řešení.

Nejsme samozřejmě první, kdo takový problém řeší, ale zdá se nám, že naše praktické, pracně nabyté zkušenosti mohou být zajímavé a jsme připraveni se o ně podělit.

Protože naše společnost má politiku open source, hledali jsme řešení s otevřeným zdrojovým kódem. Na oplátku sdílíme náš vývoj a zveřejňujeme je. Například na GitHubu existuje náš plugin pro Nextcloud, které klientům poskytujeme, zvyšující bezpečnost dat v případě náhodného nebo úmyslného smazání.

Zálohovací nástroje

Naše hledání metod řešení jsme začali výběrem nástroje pro vytváření záloh.

Běžný tar + gzip nefunguje dobře - data jsou duplikovaná. Přírůstek často obsahuje velmi málo skutečných změn a velká část dat v rámci jednoho souboru se opakuje.
Je tu další problém – redundance distribuovaného úložiště dat. Používáme minio a jeho data jsou v podstatě nadbytečná. Nebo jste museli udělat zálohu přes samotné minio - načíst ji a použít všechny mezerníky mezi souborovým systémem a neméně důležité je riziko, že zapomenete na některé buckety a metainformace. Nebo použijte deduplikaci.

Zálohovací nástroje s duplikací jsou dostupné v open source (na Habré byly články na toto téma) a naši finalisté byli Borg и Venkovský. Naše srovnání obou aplikací je níže, ale prozatím vám prozradíme, jak jsme celé schéma zorganizovali.

Správa záloh

Borg a Restic jsou dobré, ale ani jeden produkt nemá centralizovaný kontrolní mechanismus. Pro účely řízení a kontroly jsme zvolili nástroj, který již máme implementovaný, bez kterého si naši práci včetně automatizace neumíme představit - to je známé CI/CD - GitLab.

Myšlenka je následující: gitlab-runner je nainstalován na každém uzlu ukládajícím data Nextcloud. Běžec spustí skript podle plánu, který monitoruje proces zálohování, a spustí Borg nebo Restic.

co jsme dostali? Zpětná vazba od provedení, pohodlná kontrola nad změnami, detaily v případě chyby.

zde je zde na GitHubu zveřejnili jsme příklady skriptu pro různé úlohy a nakonec jsme jej připojili k zálohování nejen Nextcloudu, ale i mnoha dalších služeb. K dispozici je také plánovač, pokud jej nechcete konfigurovat ručně (a my nechceme) a .gitlab-ci.yml

V Gitlab API zatím není možné změnit časový limit CI/CD, ale je malý. Je třeba zvýšit, řekněme 1d.

GitLab se naštěstí umí spouštět nejen podle commitu, ale pouze podle harmonogramu, to je přesně to, co potřebujeme.

Nyní o obalovém skriptu.

Pro tento skript jsme nastavili následující podmínky:

• Měl by být spuštěn jak běžcem, tak ručně z konzole se stejnou funkčností.
• Musí existovat obslužné nástroje chyb:
• návratový kód.
• vyhledejte řetězec v protokolu. Například pro nás může být chybou zpráva, kterou program nepovažuje za fatální.
• Časový limit zpracování. Doba realizace musí být přiměřená.
• Potřebujeme velmi podrobný protokol. Ale jen v případě chyby.
• Před spuštěním se také provádí řada testů.
• Malé bonusy pro pohodlí, které jsme považovali za užitečné během procesu podpory:
• Začátek a konec jsou zaznamenány v syslog místního počítače. To pomáhá propojit systémové chyby a zálohovat provoz.
• Část chybového protokolu, pokud existuje, je odeslána do stdout, celý protokol je zapsán do samostatného souboru. Je vhodné se ihned podívat na CI a vyhodnotit chybu, pokud je triviální.
• Režimy ladění.

Celý protokol se uloží jako artefakt v GitLabu; pokud nedojde k chybě, protokol se smaže. Skript píšeme v bash.

Rádi zvážíme jakékoli návrhy a připomínky týkající se open source – vítáme.

Jak to funguje

Na záložním uzlu je spuštěn běžec s Bash exekutorem. Podle plánovače se úloha CI/CD spouští ve speciálním tuřínu. Runner pro takové úlohy spustí univerzální wrapper skript, zkontroluje platnost záložního úložiště, přípojných bodů a všeho, co chceme, pak zazálohuje a vyčistí ten starý. Samotná dokončená záloha je odeslána do S3.

Pracujeme podle tohoto schématu - je to externí poskytovatel AWS nebo ruský ekvivalent (je rychlejší a data neopouštějí Ruskou federaci). Nebo klientovi na jeho stránky pro tyto účely nainstalujeme samostatný minio cluster. Většinou to děláme z bezpečnostních důvodů, kdy klient nechce, aby data vůbec opustila jeho okruh.

Nepoužili jsme funkci odesílání zálohy přes ssh. To nepřidává zabezpečení a síťové možnosti poskytovatele S3 jsou mnohem vyšší než u našeho jednoho ssh stroje.

Abyste ochránili svůj místní počítač před hackerem, protože může vymazat data na S3, musíte povolit verzování.
Záloha vždy zálohu zašifruje.

Borg má nešifrovaný režim none, ale důrazně nedoporučujeme jej zapínat. V tomto režimu nejenže nedojde k žádnému šifrování, ale nevypočítá se kontrolní součet toho, co se zapisuje, což znamená, že integritu lze kontrolovat pouze nepřímo pomocí indexů.

Samostatný plánovač kontroluje zálohy na integritu indexů a obsahu. Kontrola je pomalá a dlouhá, proto ji spouštíme samostatně jednou za měsíc. Může to trvat několik dní.

Readme v ruštině

Hlavní funkcí

• prepare trénink
• testcheck kontrola připravenosti
• maincommand základní tým
• forcepostscript funkce, která se provede na konci nebo chybně. Používáme jej k odpojení oddílu.

Servisní funkce

• cleanup Zaznamenáme chyby nebo vymažeme soubor protokolu.
• checklog analyzovat protokol pro výskyt řádku s chybou.
• ret výstupní manipulátor.
• checktimeout zkontrolujte časový limit.

životní prostředí

• VERBOSE=1 Chyby zobrazujeme na obrazovce okamžitě (stdout).
• SAVELOGSONSUCCES=1 po úspěchu uložte protokol.
• INIT_REPO_IF_NOT_EXIST=1 Vytvořte úložiště, pokud neexistuje. Ve výchozím nastavení zakázáno.
• TIMEOUT maximální čas pro hlavní operaci. Na konci jej můžete nastavit jako „m“, „h“ nebo „d“.

Režim ukládání starých kopií. Výchozí:

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

Proměnné uvnitř skriptu

• ERROR_STRING — řetězec pro přihlášení k chybovému protokolu.
• EXTRACT_ERROR_STRING — výraz pro show string if error.
• KILL_TIMEOUT_SIGNAL — signál pro zabití, pokud vypršel časový limit.
• TAIL — kolik řetězců s chybami na obrazovce.
• COLORMSG — barva zprávy (výchozí žlutá).

Tento skript, který se nazývá wordpress, má podmíněné jméno, jeho trik je v tom, že také zálohuje databázi mysql. To znamená, že jej lze použít pro jednouzlové instalace Nexcloud, kde můžete také zálohovat databázi. Výhodou je nejen to, že je vše na jednom místě, ale také obsah databáze se blíží obsahu souborů, protože časový rozdíl je minimální.

Restic vs Borg

Existují také srovnání mezi Borg a Restic tady na Habréa neměli jsme za úkol vyrobit jen další, ale vlastní. Bylo pro nás důležité, jak to bude vypadat na našich datech, s našimi specifiky. Přinášíme je.

Naše kritéria výběru, kromě již zmíněných (deduplikace, rychlé zotavení atd.):

• Odolnost vůči nedokončené práci. Zkontrolovat zabití -9.
• Velikost na disku.
• Požadavek na zdroje (CPU, paměť).
• Velikost uložených kapek.
• Práce s S3.
• Kontrola integrity.

K testování jsme vzali jednoho klienta s reálnými daty a celkovou velikostí 1,6 TB.
Podmínky.

Borg neumí pracovat přímo s S3 a namontovali jsme disk jako pojistku, přes praštěný. Restic to poslal do S3 sám.

Goofys funguje velmi rychle a dobře a existují modul diskové mezipaměti, což práci ještě urychlí. Je ve fázi beta a upřímně řečeno, během testů (jiných) jsme se zhroutili se ztrátou dat. Výhodou ale je, že samotná procedura zálohování nevyžaduje mnoho čtení, ale většinou zápis, takže cache používáme pouze při kontrolách integrity.

Abychom snížili vliv sítě, použili jsme místního poskytovatele - Yandex Cloud.

Výsledky srovnávacích testů.

• Kill -9 s dalším restartem byly oba úspěšné.
• Velikost na disku. Borg umí komprimovat, takže výsledky jsou podle očekávání.

Backuper
velikost

Borg
562Gb

Venkovský
628Gb

• Podle CPU
  Borg sám spotřebovává málo, s výchozí kompresí, ale musí být vyhodnocen společně s goofys procesem. Celkově jsou srovnatelné a využívají asi 1,2 jádra na stejném testovacím virtuálním počítači.
• Paměť. Restic má přibližně 0,5 GB, Borg přibližně 200 MB. Ale to vše je bezvýznamné ve srovnání s mezipamětí systémových souborů. Proto je vhodné alokovat více paměti.
• Rozdíl ve velikosti blobu byl markantní.

Backuper
velikost

Borg
asi 500 MB

Venkovský
asi 5 MB

• Zkušenosti s Restic's S3 jsou vynikající. Práce s Borg přes goofys nevyvolává žádné otázky, ale bylo poznamenáno, že je vhodné provést umount po dokončení zálohování, aby se mezipaměť úplně resetovala. Zvláštností S3 je, že nedostatečně napumpované kusy nebudou nikdy odeslány do bucketu, což znamená, že neúplně vyplněná data vedou k velkým škodám.
• Kontrola integrity funguje v obou případech dobře, ale rychlost se výrazně liší.
  Restic 3,5 hodin.
  Borg, se 100GB mezipamětí SSD souborů – 5 hodin.Výsledek přibližně stejné rychlosti, pokud jsou data na místním disku.
  Borg čte přímo z S3 bez mezipaměti 33 hodin. Příšerně dlouhé.

Pointa je, že Borg umí komprimovat a má větší bloby – což zlevňuje úložiště a operace GET/PUT v S3. To je ale za cenu složitějšího a pomalejšího ověřování. Co se týče rychlosti obnovy, nezaznamenali jsme žádný rozdíl. Restic trvá následné zálohy (po první) trochu déle, ale ne výrazně.

V neposlední řadě při výběru byla velikost komunity.

A vybrali jsme borg.

Pár slov o kompresi

Borg má ve svém arzenálu vynikající nový kompresní algoritmus - zstd. Kvalita komprese není horší než gzip, ale mnohem rychlejší. A rychlostí srovnatelnou s výchozím lz4.

Například výpis databáze MySQL je komprimován dvakrát lépe než lz4 při stejné rychlosti. Zkušenosti s reálnými daty však ukazují, že v kompresním poměru uzlu Nextcloud je velmi malý rozdíl.

Borg má spíše bonusový režim komprese – pokud má soubor vysokou entropii, pak se komprese vůbec neuplatňuje, což zvyšuje rychlost. Povoleno volbou při vytváření
-C auto,zstd
pro algoritmus zstd
Takže s touto možností jsme ve srovnání s výchozí kompresí dostali
560Gb, respektive 562Gb. Data z příkladu výše připomenu, bez komprese je výsledek 628Gb. Výsledek 2GB rozdílu nás poněkud překvapil, ale říkali jsme si, že si to přece jen vybereme. auto,zstd.

Způsob ověření zálohy

Podle plánovače se virtuální stroj spouští přímo od poskytovatele nebo od klienta, což značně snižuje zatížení sítě. Přinejmenším je to levnější, než si to zvednout sami a řídit provoz.

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/

Pomocí stejného schématu kontrolujeme soubory antivirem (ostatně). Uživatelé totiž na Nextcloud nahrávají různé věci a ne každý má antivirus. Provádění kontrol v době nalévání zabere příliš mnoho času a narušuje podnikání.

Škálovatelnosti je dosaženo spuštěním běžců na různých uzlech s různými značkami.
Naše monitorování shromažďuje stavy zálohování prostřednictvím GitLab API v jednom okně; v případě potřeby lze problémy snadno rozpoznat a stejně snadno lokalizovat.

Závěr

Díky tomu s jistotou víme, že zálohujeme, že naše zálohy jsou platné, problémy, které s nimi vzniknou, zaberou málo času a jsou řešeny na úrovni správce povinností. Zálohy zabírají opravdu málo místa ve srovnání s tar.gz nebo Bacula.

Zdroj: www.habr.com