Kako vam GitLab pomaže napraviti sigurnosnu kopiju velikih NextCloud pohrana

Hej Habr!

Danas želim govoriti o našem iskustvu u automatizaciji sigurnosnog kopiranja velikih podataka iz Nextcloud pohrana u različitim konfiguracijama. Radim kao serviser u Molniya AK, gdje radimo upravljanje konfiguracijom IT sustava, Nextcloud se koristi za pohranu podataka. Uključujući, s distribuiranom strukturom, s redundancijom.

Problemi koji proizlaze iz značajki instalacija su veliki podaci. Versioniranje koje pruža Nextcloud, redundancija, subjektivni razlozi i drugo stvara mnogo duplikata.

prapovijest

Prilikom administriranja Nextclouda javlja se problem organiziranja učinkovite sigurnosne kopije koja mora biti kriptirana jer su podaci vrijedni.

Nudimo mogućnosti pohranjivanja sigurnosnih kopija kod nas ili kod korisnika na odvojenim strojevima od Nextclouda, što zahtijeva fleksibilan automatizirani pristup administraciji.

Postoji mnogo klijenata, svi s različitim konfiguracijama, i svi na svojim stranicama i sa svojim karakteristikama. Ovo je standardna tehnika kada cijela stranica pripada vama, a sigurnosne kopije se izrađuju od krunica; ne pristaje dobro.

Prvo, pogledajmo ulazne podatke. Trebamo:

• Skalabilnost u smislu jednog ili nekoliko čvorova. Za velike instalacije koristimo minio kao spremište.
• Saznajte više o problemima s izvođenjem sigurnosnih kopija.
• Morate imati sigurnosnu kopiju kod svojih klijenata i/ili kod nas.
• Brzo i jednostavno rješavajte probleme.
• Klijenti i instalacije su vrlo različiti jedni od drugih - ne može se postići uniformnost.
• Brzina oporavka trebala bi biti minimalna u dva scenarija: potpuni oporavak (katastrofa), jedna mapa izbrisana greškom.
• Potrebna je funkcija deduplikacije.

Kako bismo riješili problem upravljanja sigurnosnim kopijama, instalirali smo GitLab. Više detalja po priboru.

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

Budući da naša tvrtka ima politiku otvorenog koda, tražili smo rješenje otvorenog koda. Zauzvrat, mi dijelimo svoj razvoj i objavljujemo ga. Na primjer, na GitHubu postoji naš dodatak za Nextcloud, koje pružamo klijentima, povećavajući sigurnost podataka u slučaju slučajnog ili namjernog brisanja.

Alati za sigurnosno kopiranje

Potragu za metodama rješenja započeli smo odabirom alata za izradu sigurnosne kopije.

Uobičajeni tar + gzip ne radi dobro - podaci se dupliciraju. Povećanje često sadrži vrlo malo stvarnih promjena, a većina podataka unutar jedne datoteke se ponavlja.
Postoji još jedan problem - redundantnost distribuirane pohrane podataka. Koristimo minio i njegovi su podaci u osnovi suvišni. Ili ste morali napraviti sigurnosnu kopiju kroz sam minio - učitati ga i koristiti sve razmake između datotečnog sustava, i, ne manje važno, postoji rizik da zaboravite na neke od spremnika i metainformacija. Ili upotrijebite deduplikaciju.

Alati za sigurnosno kopiranje s dupliciranjem dostupni su u otvorenom kodu (na Habréu je bilo Članak na ovu temu) i bili su naši finalisti Borg и Restić. Naša usporedba dviju aplikacija nalazi se u nastavku, ali za sada ćemo vam reći kako smo organizirali cijelu shemu.

Upravljanje sigurnosnim kopijama

Borg i Restic su dobri, ali niti jedan proizvod nema centralizirani kontrolni mehanizam. Za potrebe upravljanja i kontrole odabrali smo alat koji već imamo implementiran, a bez kojeg ne možemo zamisliti svoj rad, pa tako ni automatizaciju - to je dobro poznati CI/CD - GitLab.

Ideja je sljedeća: gitlab-runner je instaliran na svakom čvoru koji pohranjuje Nextcloud podatke. Runner pokreće skriptu prema rasporedu koja nadzire proces sigurnosne kopije i pokreće Borg ili Restic.

Što smo dobili? Povratne informacije o izvršenju, prikladna kontrola promjena, detalji u slučaju pogreške.

ovdje je ovdje na GitHubu objavili smo primjere skripti za razne zadatke, a na kraju smo je priložili sigurnosnoj kopiji ne samo Nextclouda, već i mnogih drugih usluga. Tu je i planer ako ga ne želite ručno konfigurirati (a mi to ne želimo) i .gitlab-ci.yml

Još uvijek ne postoji način da se promijeni CI/CD timeout u Gitlab API-ju, ali je mali. Treba ga povećati, recimo 1d.

GitLab, srećom, može se pokrenuti ne samo prema komitu, već samo prema rasporedu, to je upravo ono što nam treba.

Sada o skripti omotača.

Postavili smo sljedeće uvjete za ovu skriptu:

• Trebao bi ga pokrenuti i trkač i ručno s konzole s istom funkcionalnošću.
• Moraju postojati rukovatelji greškama:
• povratni kod.
• potražite niz u zapisniku. Na primjer, za nas pogreška može biti poruka koju program ne smatra fatalnom.
• Istek vremena obrade. Vrijeme isporuke mora biti razumno.
• Trebamo vrlo detaljan dnevnik. Ali samo u slučaju greške.
• Također se provodi niz testova prije početka.
• Mali bonusi za praktičnost koji su nam bili korisni tijekom procesa podrške:
• Početak i kraj bilježe se u syslog lokalnog stroja. Ovo pomaže u povezivanju grešaka sustava i operacija sigurnosnog kopiranja.
• Dio dnevnika grešaka, ako ga ima, izlazi u stdout, cijeli dnevnik se piše u zasebnu datoteku. Prikladno je odmah pogledati CI i procijeniti pogrešku ako je trivijalna.
• Načini otklanjanja pogrešaka.

Cijeli zapisnik sprema se kao artefakt u GitLabu; ako nema pogreške, dnevnik se briše. Skriptu pišemo u bashu.

Rado ćemo razmotriti sve prijedloge i komentare u vezi s otvorenim kodom - dobrodošli.

Kako ovo radi

Runner s Bash egzekutorom pokreće se na rezervnom čvoru. Prema planeru, posao CI/CD se pokreće u posebnom repu. Runner pokreće univerzalnu omotnu skriptu za takve zadatke, provjerava valjanost repozitorija sigurnosne kopije, točaka montiranja i svega što želimo, zatim sigurnosno kopira i čisti staro. Sama gotova sigurnosna kopija se šalje na S3.

Radimo prema ovoj shemi - to je vanjski AWS pružatelj usluga ili ruski ekvivalent (brži je i podaci ne napuštaju Rusku Federaciju). Ili instaliramo zasebni minio klaster za klijenta na njegovu stranicu za te potrebe. Obično to činimo iz sigurnosnih razloga, kada klijent ne želi da podaci uopće napuste njihov krug.

Nismo koristili značajku slanja sigurnosne kopije putem ssh-a. Ovo ne povećava sigurnost, a mrežne mogućnosti S3 davatelja mnogo su veće od našeg jednog ssh stroja.

Kako biste zaštitili svoj lokalni stroj od hakera, budući da on može obrisati podatke na S3, morate omogućiti verziju.
Sigurnosna kopija uvijek šifrira sigurnosnu kopiju.

Borg ima nešifrirani način rada none, ali toplo ne preporučujemo da ga uključite. U ovom načinu rada ne samo da neće biti enkripcije, već se ne izračunava kontrolni zbroj onoga što se piše, što znači da se integritet može provjeriti samo neizravno, pomoću indeksa.

Zasebni planer provjerava sigurnosne kopije za integritet indeksa i sadržaja. Provjera je spora i duga, pa je provodimo posebno jednom mjesečno. Može potrajati nekoliko dana.

Readme na ruskom

Glavne funkcije

• prepare trening
• testcheck provjera spremnosti
• maincommand glavni tim
• forcepostscript funkcija koja se izvršava na kraju ili greškom. Koristimo ga za demontiranje particije.

Uslužne funkcije

• cleanup Bilježimo pogreške ili brišemo log datoteku.
• checklog raščlaniti dnevnik za pojavu retka s pogreškom.
• ret rukovatelj izlazom.
• checktimeout provjerite čekanje.

okolina

• VERBOSE=1 Greške odmah prikazujemo na ekranu (stdout).
• SAVELOGSONSUCCES=1 spremite zapisnik nakon uspjeha.
• INIT_REPO_IF_NOT_EXIST=1 Napravite spremište ako ne postoji. Onemogućeno prema zadanim postavkama.
• TIMEOUT maksimalno vrijeme za glavnu operaciju. Možete ga postaviti kao 'm', 'h' ili 'd' na kraju.

Način pohrane za stare kopije. Zadano:

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

Varijable unutar skripte

• ERROR_STRING — niz za grešku u dnevniku prijave.
• EXTRACT_ERROR_STRING — izraz za prikaz niza u slučaju pogreške.
• KILL_TIMEOUT_SIGNAL — signal za ubijanje ako istekne vrijeme.
• TAIL — koliko nizova s ​​greškama na ekranu.
• COLORMSG — boja poruke (zadana žuta).

Ta skripta, koja se zove wordpress, ima uvjetni naziv, trik joj je u tome što također radi sigurnosnu kopiju mysql baze podataka. To znači da se može koristiti za instalacije Nexclouda s jednim čvorom, gdje također možete napraviti sigurnosnu kopiju baze podataka. Pogodnost nije samo u tome što je sve na jednom mjestu, već je i sadržaj baze podataka blizak sadržaju datoteka, jer je vremenska razlika minimalna.

Restić protiv Borga

Postoje i usporedbe između Borga i Restića ovdje na Habréu, a mi nismo imali zadatak napraviti samo još jednu, već svoju. Bilo nam je važno kako će to izgledati na našim podacima, s našim specifičnostima. Mi ih donosimo.

Naši kriteriji odabira, uz već spomenute (deduplikacija, brzi oporavak, itd.):

• Otpor prema nedovršenom poslu. Provjeri ubojstvo -9.
• Veličina na disku.
• Potreba za resursima (CPU, memorija).
• Veličina pohranjenih mrlja.
• Rad sa S3.
• Provjera integriteta.

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

Borg ne zna raditi direktno sa S3, a disk smo montirali kao osigurač, preko glupane. Restic ga je poslao samom S3.

Goofys radi jako brzo i dobro, a ima ih disk cache modul, što još više ubrzava rad. U beta fazi je i, iskreno, pali smo s gubitkom podataka tijekom testova (drugih). Ali pogodnost je u tome što sama procedura sigurnosnog kopiranja ne zahtijeva puno čitanja, već uglavnom pisanja, tako da predmemoriju koristimo samo tijekom provjere integriteta.

Kako bismo smanjili utjecaj mreže, koristili smo lokalnog pružatelja usluga - Yandex Cloud.

Rezultati usporednog testiranja.

• Ubiti -9 s daljnjim ponovnim pokretanjem oba su bila uspješna.
• Veličina na disku. Borg može komprimirati, pa su rezultati očekivani.

Backuper
Veličina

Borg
562Gb

Restić
628Gb

• Po CPU-u
  Borg sam po sebi troši malo, sa zadanom kompresijom, ali mora se procijeniti zajedno s goofys procesom. Ukupno su usporedivi i koriste oko 1,2 jezgre na istom testnom virtualnom stroju.
• Memorija. Restic je otprilike 0,5GB, Borg je otprilike 200MB. Ali sve je to beznačajno u usporedbi s predmemorijom sistemskih datoteka. Stoga je preporučljivo dodijeliti više memorije.
• Razlika u veličini mrlja bila je zapanjujuća.

Backuper
Veličina

Borg
oko 500 MB

Restić
oko 5 MB

• Resticovo S3 iskustvo je izvrsno. Rad s Borgom preko goofysa ne postavlja nikakva pitanja, ali je primijećeno da je preporučljivo učiniti umount nakon što je sigurnosna kopija dovršena kako biste u potpunosti resetirali predmemoriju. Posebnost S3 je u tome što nedovoljno ispumpani chunkovi nikada neće biti poslani u spremnik, što znači da nepotpuno ispunjeni podaci dovode do velike štete.
• Provjera integriteta radi dobro u oba slučaja, ali se brzina značajno razlikuje.
  Restic 3,5 sati.
  Borg, sa 100GB SSD predmemorije datoteka – 5 sati.Približno jednak rezultat brzine ako su podaci na lokalnom disku.
  Borg čita izravno sa S3 bez predmemorije 33 sati. Monstruozno dugo.

Zaključak je da Borg može komprimirati i ima veće blobove - što čini pohranu i GET/PUT operacije u S3 jeftinijima. Ali to dolazi po cijenu složenije i sporije provjere. Što se tiče brzine oporavka, nismo primijetili nikakvu razliku. Restic-u su potrebne sljedeće sigurnosne kopije (nakon prve) malo duže, ali ne značajno.

Posljednje, ali ne i najmanje važno u izboru je bila veličina zajednice.

I odabrali smo borg.

Nekoliko riječi o kompresiji

Borg u svom arsenalu ima odličan novi algoritam kompresije - zstd. Kvaliteta kompresije nije lošija od gzipa, ali je mnogo brža. I usporediv u brzini sa zadanim lz4.

Na primjer, ispis MySQL baze podataka komprimiran je dva puta bolje od lz4 pri istoj brzini. Međutim, iskustvo sa stvarnim podacima pokazuje da postoji vrlo mala razlika u omjeru kompresije Nextcloud čvora.

Borg ima prilično bonus način kompresije - ako datoteka ima visoku entropiju, kompresija se uopće ne primjenjuje, što povećava brzinu. Omogućeno opcijom prilikom izrade
-C auto,zstd
za zstd algoritam
Dakle, s ovom opcijom, u usporedbi sa zadanom kompresijom, dobili smo
560Gb odnosno 562Gb. Podaci iz gornjeg primjera, da vas podsjetim, bez kompresije rezultat je 628Gb. Rezultat od 2GB razlike donekle nas je iznenadio, ali smo mislili da ćemo ga ipak izabrati. auto,zstd.

Sigurnosna metoda provjere

Prema planeru, virtualni stroj se pokreće izravno od davatelja ili od klijenta, što uvelike smanjuje opterećenje mreže. Barem je jeftinije nego da ga sami uzgajate i pokrećete 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/

Koristeći istu shemu, provjeravamo datoteke s antivirusom (naknadno). Uostalom, korisnici postavljaju različite stvari na Nextcloud i nemaju svi antivirus. Obavljanje pregleda u vrijeme točenja oduzima previše vremena i ometa poslovanje.

Skalabilnost se postiže pokretanjem pokretača na različitim čvorovima s različitim oznakama.
Naš nadzor prikuplja backup statuse putem GitLab API-ja u jednom prozoru, po potrebi se problemi lako uočavaju i jednako lako lokaliziraju.

Zaključak

Kao rezultat toga, pouzdano znamo da radimo sigurnosne kopije, da su naše sigurnosne kopije valjane, problemi koji nastanu s njima oduzimaju malo vremena i rješavaju se na razini dežurnog administratora. Sigurnosne kopije zauzimaju jako malo prostora u usporedbi s tar.gz ili Bacula.

Izvor: www.habr.com