🥇Kako GitLab pomaže u izradi sigurnosnih kopija velikih skladišta NextCloud

Bok, Habr!

Danas želim govoriti o našem iskustvu automatizacije sigurnosnog kopiranja velikih podataka iz Nextcloud skladišta u različitim konfiguracijama. Radim kao CTO u "Molina AK", gdje se bavimo konfiguracijsko upravljanje IT sustava, a za pohranu podataka koristimo Nextcloud. Uključujući i distribuiranu strukturu sa rezervnim kopijama.

Problemi koji proizlaze iz specifičnosti instalacija su da podataka ima puno. Verzija koju nudi Nextcloud, rezervisanje, subjektivni razlozi i drugo stvaraju mnogo dupliciranja.

Povijest

Pri administraciji Nextclouda, oštro se postavlja problem organizacije učinkovitog backupa koji je obavezno potrebno šifrirati, jer su podaci dragocjeni.

Nudimo opcije pohrane backup-a kod nas ili kod klijenta na njegovim odvojenim mašinama od Nextclouda, što zahtijeva fleksibilan automatizirani pristup administraciji.

Ima puno klijenata, svi oni imaju različite konfiguracije, i svi su na svojim platformama i sa svojim osobitostima. Tu standardna metoda kada cijela platforma pripada vama i backupi se rade iz crona nije primjenjiva.

Za početak pogledajmo ulazne podatke. Potrebno nam je:

Skalabilnost u smislu jedne ili više nodova. Za velike instalacije koristimo minio kao skladište.
Biti obaviješten o problemima s izvršenjem backupa.
Backup treba pohranjivati kod klijenata i/ili kod nas.
Brzo i lako rješavanje problema.
Klijenti i instalacije se značajno razlikuju jedni od drugih — ujednačenost je teško postići.
Brzina oporavka treba biti minimalna prema dva scenarija: potpuno obnavljanje (katastrofa), jedan folder — slučajno izbrisan.
Funkcija deduplifikacije je obavezna.

Za rješavanje zadatka upravljanja backup-ima integrirali smo GitLab. Više informacija u nastavku.

Naravno, nismo prvi koji rješavaju sličan problem, ali nam se čini da naše praktično iskustvo može biti zanimljivo i spremni smo ga podijeliti.

Budući da je u našoj tvrtki usvojena politika otvorenog koda, rješenje smo tražili isključivo s otvorenim izvorom. S druge strane, dijelimo svoje razvojne projekte i objavljujemo ih. Na primjer, na GitHub-u postoji naš plugin za Nextcloud, koji postavljamo klijentima, pojačavajući sigurnost podataka u slučaju slučajnog ili namjernog brisanja.

Alati za backupiranje

Potraga za rješenjima započela je odabir alata za izradu sigurnosnih kopija.

Obični tar + gzip slabo rade — podaci se dupliciraju. Inkremenat često sadrži vrlo malo promjena i velika većina podataka unutar jednog datoteke se ponavlja.
Postoji još jedan problem — višak podataka u distribuiranom skladištu podataka. Koristimo minio i njegovi podaci u suštini su višak. Ili se backup trebao raditi preko samog minio — opterećivati ga i koristiti sve posrednike između datotečnog sustava, a što je jednako važno, postoji rizik da zaboravimo dio bunara i meta-informacija. Ili treba koristiti deduplifikaciju.

Postoje alati za izradu sigurnosnih kopija s deduplifikacijom u otvorenom kodu (na Habré su članaka bili na ovu temu) i naši finalisti su bili Borg i Restic. O našem uspoređivanju dvaju aplikacija dolje, a sada ćemo reći kako smo organizirali cijelu shemu.

Upravljanje izradom sigurnosnih kopija

Borg i Restic su dobri, ali nijedan od tih proizvoda nema centralizirani mehanizam upravljanja. Za svrhe upravljanja i kontrole odabrali smo alat koji imamo implementiran, bez kojeg ne možemo zamisliti svoj rad, uključujući automatizaciju — to je poznati CI/CD – GitLab.

Ideja je sljedeća: na svaku čvoru koja pohranjuje podatke Nextcloud postaviti gitlab-runner. Runner pokreće skriptu prema rasporedu koja prati proces izrade sigurnosne kopije, a ta pokreće Borg ili Restic.

Što smo dobili? Povratnu informaciju o izvršenju, jednostavnu kontrolu nad promjenama, detalje u slučaju greške.

Evo ovdje na GitHubu objavili smo primjere skripti za različite zadatke, a na kraju smo ga priključili na backup ne samo Nextcloud-a, već i mnogih drugih servisa. Tamo je i planifikator, ako ne želite ručno ga postavljati (a nama se ne da) i .gitlab-ci.yml

U API-ju GitLaba trenutno nema mogućnosti za promjenu tajmauta CI/CD, a on je tamo mali. Treba ga povećati, recimo do 1d.

GitLab srećom može raditi ne samo na temelju commit-a, već i prema rasporedu, točno ono što nam treba.

Sada o skripti-omotaču.

Postavili smo sljedeće uvjete za ovu skriptu:

Mora se pokretati kao runner i ručno iz konzole s istom funkcionalnošću.
Obavezno moraju biti obradnici grešaka:
return code.
pretraživanje linije u logu. Na primjer, za nas greška može biti poruka koju program ne smatra fatalnom.
Obrada timeout-a. Vrijeme izvođenja mora biti razmjerno.
Trebamo detaljan zapis. Ali samo u slučaju greške.
Također se provodi niz testova prije početka.
Male pogodnosti za udobnost koje smo otkrili korisnima tijekom podrške:
Pokretanje i završetak bilježi se u sistemskom logu lokalnog računala. To pomaže u povezivanju sistemskih grešaka i rada rezervne kopije.
Dio loga grešaka, kada ih ima, ispisuje se na stdout, cijeli log se piše u poseban fajl. Praktično je odmah pogledati u CI i procijeniti grešku ako je trivijalna.
Načini za debagiranje.

Potpuni log čuva se kao artefakt u GitLabu, ako nema grešaka, log se briše. Skriptu pišemo na bashu.

Svaka sugestija i primjedba o open sourceu bit će dobrodošla — welcome.

Kako to funkcionira

Na nodu koja se pravi rezervna kopija pokreće se runner s bash executorom. U scheduleru u posebnom repozitoriju pokreće se CI/CD job. Runner pokreće skriptu univerzalnu omotnicu za takve zadatke, u njoj se provode provjere valjanosti repozitorija rezervne kopije, točaka montiranja i svega što želimo, zatim se obavlja rezervna kopija i čišćenje starog. Sama gotova rezervna kopija šalje se na S3.

Radimo prema ovoj shemi — to je vanjski pružatelj AWS ili ruski analog (brže je i podaci ne napuštaju Rusiju). Ili klijentu postavljamo poseban minio klaster na njegovoj lokaciji za ove svrhe. To obično radimo iz sigurnosnih razloga, kada klijent ne želi da podaci napuste njihov kontur.

Nismo koristili opciju slanja rezervne kopije putem ssh. Time se ne povećava sigurnost, a mrežne mogućnosti pružatelja S3 su mnogo veće od jedne naše ssh mašine.

Da bismo se zaštitili od hakera na lokalnom računalu — jer on može obrisati podatke na S3, obavezno je uključiti verzioniranje.
rezervna kopija uvijek šifrira rezervnu kopiju.

Borg ima način bez šifriranja none, ali ga kategorički ne preporučujemo uključivati. U ovom načinu ne samo da neće biti šifriranja, već se ne izračunava kontrolna suma onoga što se zapisuje, takže se cjelovitost može provjeriti samo neizravno, prema indeksima.

Prema posebnom rasporedu provodi se provjera rezervnih kopija na cjelovitost indeksa i sadržaja. Provjera se odvija sporo i dugo, zbog čega je pokrećemo odvojeno jednom mjesečno. Može trajati nekoliko dana.

Readme na ruskom

Glavne funkcije

prepare priprema
testcheck provjera spremnosti
maincommand glavna komanda
forcepostscript funkcija koja se izvršava na kraju ili u slučaju greške. Koristimo je da odmontiramo particiju.

Funkcije usluge

cleanup zapisujemo greške ili brišemo log datoteku.
checklog parsiramo log za prisutnost grešaka.
ret izlazni handler.
checktimeout provera vremenskog ograničenja.

Okruženje

VERBOSE=1 prikazujemo greške odmah na ekranu (stdout).
SAVELOGSONSUCCES=1 čuvamo log u slučaju uspeha.
INIT_REPO_IF_NOT_EXIST=1 Kreiramo repozitorijum ako ne postoji. Po defaultu je isključeno.
TIMEOUT maksimalno vreme za glavnu operaciju. Možete ga postaviti kao ‘m’, ‘h’ ili ‘d’ na kraju.

Režim čuvanja starih kopija. Po defaultu:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

Varijable unutar skripta

ERROR_STRING — string za provere u logu zbog greške.
EXTRACT_ERROR_STRING — izraz za prikaz stringa ukoliko dođe do greške.
KILL_TIMEOUT_SIGNAL — signal za prekidanje ako dođe do prekoračenja vremenskog ograničenja.
TAIL — koliko stringova sa greškama na ekranu.
COLORMSG — boja poruke (podrazumevano žuta).

Skripta nazvana wordpress je uslovno naziva, njena karakteristika je da takođe pravi backup MySQL baze. To znači da se može koristiti za jednokratne instalacije Nextcloud, gde možete takođe backupovati bazu. Povoljnost nije samo u tome što je sve na jednom mestu, već i što je sadržaj baze blizu sadržaju datoteka, jer je razlika u vremenu minimalna.

Restic vs Borg

Poređenja Borg-a i Restic-a uključuju ovde na Habr-u, i nismo imali zadatak da napravimo samo još jedno, već sopstveno. Bilo nam je važno kako će izgledati na našim podacima, sa našom specifičnošću. Uključujemo ih.

Naši kriterijumi izbora, osim već pomenutih (dedupikacija, brzo obnavljanje itd.):

Otpornost na nedovršeni rad. Provera na kill -9.
Velicina na disku.
Zahtjevi prema resursima (CPU, memorija).
Veličina čuvanih blob-ova.
Rad sa S3.
Provera integriteta.

Za testiranje smo uzeli jednog klijenta sa stvarnim podacima i ukupnom veličinom od 1,6TB.
Uslovi.

Borg ne zna direktno raditi sa S3, i montirali smo kao fuse disk, preko goofys. Restic je slao u S3 sam.

Goofys radi veoma brzo i dobro, i postoji modul za disk caching, što dodatno ubrzava rad. Nalazi se u beta fazi, i moram priznati da nam je padao sa gubitkom podataka na testovima (drugim). Ali pogodnost je u tome što sama procedura backupovanja ne zahteva puno čitanja, već pre svega pisanje, tako da keš koristimo samo prilikom provere integriteta.

Da bismo smanjili uticaj mreže, koristili smo lokalnog provajdera — Yandex Cloud.

Rezultati testiranja poređenja.

Kill -9 s daljnjim ponovnim pokretanjem, oboje je uspješno prošlo.
Veličina na disku. Borg može komprimirati, stoga su očekivani rezultati.

Backuper
Veličina

Borg
562Gb

Restic
628Gb

Prema CPU-u
Sam borg troši malo, s zadanim komprimiranim, ali treba procijeniti zajedno s procesom goofys. Zajedno su uporedivi i troše oko 1,2 jezgre na istoj testnoj virtualnoj mašini.
Memorija. Restic približno 0,5Gb, Borg oko 200Mb. No, to su sve neznatni troškovi u usporedbi s datotečnim predmemorijom sustava. Stoga je poželjno dodijeliti više memorije.
Razlika u veličinama blobova pokazala se drastičnom.

Backuper
Veličina

Borg
oko 500Mb

Restic
oko 5Mb

Rad s S3 od Restica je odličan. Rad Borga putem goofys ne izaziva pitanja, ali je primjećeno da je poželjno nakon završetka sigurnosne kopije izvršiti umount kako bi se u potpunosti resetirala predmemorija. Karakteristika rada S3 je da nedopunjeni dijelovi nikada neće biti poslani u bazi, a to znači da nepotpuno učitani podaci dovode do velikih oštećenja.
Provjera cjelovitosti dobro funkcionira u oba slučaja, ali brzina se značajno razlikuje.
Restic – 3,5 sata.
Borg, s datotečnom predmemorijom od 100Gb SSD – 5 sati. Otprilike isti rezultat brzine ako su podaci na lokalnom disku.
Borg čita direktno s S3 bez predmemorije 33 sata. Ogromno dugo.

U suštini, Borg može komprimirati i ima veće blobove — što čini skladištenje i GET/PUT operacije u S3 jeftinijima. No, to dolazi s kompliciranijom i sporijom provjerom. Što se tiče brzine oporavka — nismo primijetili razliku. Kasnije sigurnosne kopije (nakon prve) restic radi malo duže, ali ne značajno.

Dimenzija zajednice također nije bila bez značaja u izboru.

I odabrali smo borg.

Par riječi o kompresiji

Borg ima u svom arsenalu odličan novi algoritam kompresije — zstd. Po kvaliteti kompresije nije lošiji od gzip-a, ali je značajno brži. I usporediv po brzini s zadanim lz4.

Na primjer, dump MySQL baze komprimira se otprilike dvostruko bolje od lz4 pri istoj brzini. Ipak, iskustvo s stvarnim podacima pokazuje vrlo malu razliku u stupnju kompresije čvora Nextcloud.

U Borgu postoji prilično bonus način kompresije — ako datoteka ima visoku entropiju, tada se kompresija uopće ne primjenjuje, što povećava brzinu rada. Uključuje se opcijom prilikom stvaranja
-C auto,zstd
za algoritam zstd
Tako da s ovom opcijom u usporedbi s zadanom kompresijom, dobili smo
560Gb i 562Gb, redom. Podatke iz gornjeg primjera, podsjećam, bez kompresije rezultat je 628Gb. Rezultat od 2Gb razlike nas je prilično iznenadio, no odlučili smo se ipak odabrati. auto,zstd.

Metodologija provjere sigurnosne kopije

Prema rasporedu, virtualna mašina se pokreće izravno kod pružatelja ili kod klijenta, što značajno smanjuje mrežno opterećenje. U svakom slučaju, to je jeftinije nego podizati kod sebe i prenositi promet.

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\/

Na isti način provjeravamo datoteke antivirusom (naknadno). Naime, korisnici učitavaju razne stvari u Nextcloud i ne posjeduju svi antivirus. Izvođenje provjere u trenutku učitavanja preuzima previše vremena i ometa poslovanje.

Skalabilnost se postiže pokretanjem runnera na različitim čvorovima s različitim oznakama.
U našem monitoring sustavu prikupljamo status sigurnosnih kopija putem API-ja GitLab-a u jednom prozoru, a po potrebi je lako primijetiti probleme, a tako ih je lako i lokalizirati.

Zaključak

Kao rezultat, točno znamo da radimo sigurnosne kopije, da su naše sigurnosne kopije valjane, a problemi koji se s njima javljaju zahtijevaju malo vremena i rješavaju se na razini dežurnog administratora. Sigurnosne kopije zapravo zauzimaju malo prostora u usporedbi s tar.gz ili Bacula.

Izvor: habr.com