Kako vam GitLab pomaga varnostno kopirati velike shrambe NextCloud

Pozdravljeni, Habr!

Danes želim govoriti o naših izkušnjah pri avtomatizaciji varnostnega kopiranja velikih podatkov iz shramb Nextcloud v različnih konfiguracijah. Delam kot serviser v Molniya AK, kjer izvajamo upravljanje konfiguracije IT sistemov, za shranjevanje podatkov se uporablja Nextcloud. Vključno s porazdeljeno strukturo, z redundanco.

Težave, ki izhajajo iz značilnosti inštalacij, so, da je veliko podatkov. Različice, ki jih zagotavlja Nextcloud, redundanca, subjektivni razlogi in drugo ustvarjajo številne dvojnike.

prazgodovina

Pri upravljanju Nextclouda se pojavi problem organiziranja učinkovite varnostne kopije, ki mora biti šifrirana, saj so podatki dragoceni.

Ponujamo možnosti shranjevanja varnostnih kopij pri nas ali pri stranki na ločene stroje od Nextclouda, kar zahteva fleksibilen avtomatiziran pristop k administraciji.

Strank je veliko, vse z različnimi konfiguracijami, vse na svojih straneh in s svojimi značilnostmi. To je standardna tehnika, ko celotno spletno mesto pripada vam in so varnostne kopije narejene iz kron; ne ustreza dobro.

Najprej si oglejmo vhodne podatke. Potrebujemo:

• Razširljivost v smislu enega ali več vozlišč. Za velike instalacije uporabljamo minio kot skladišče.
• Pozanimajte se o težavah pri izvajanju varnostnih kopij.
• Pri svojih strankah in/ali pri nas morate imeti varnostno kopijo.
• Hitro in enostavno se spopadite s težavami.
• Stranke in inštalacije se med seboj zelo razlikujejo – enotnosti ni mogoče doseči.
• Hitrost obnovitve bi morala biti minimalna v dveh scenarijih: popolna obnovitev (katastrofa), ena mapa pomotoma izbrisana.
• Potrebna je funkcija deduplikacije.

Za rešitev problema upravljanja varnostnih kopij smo namestili GitLab. Več podrobnosti po priboru.

Seveda nismo prvi, ki smo rešili tak problem, vendar se nam zdi, da so naše praktične, težko pridobljene izkušnje lahko zanimive in smo jih pripravljeni deliti.

Ker ima naše podjetje odprtokodno politiko, smo iskali odprtokodno rešitev. Po drugi strani delimo svoj razvoj in ga objavljamo. Na primer, na GitHubu obstaja naš vtičnik za Nextcloud, ki jih nudimo strankam, s čimer povečamo varnost podatkov v primeru nenamernega ali namernega izbrisa.

Orodja za varnostno kopiranje

Iskanje metod rešitve smo začeli z izbiro orodja za ustvarjanje varnostnih kopij.

Običajni tar + gzip ne deluje dobro - podatki so podvojeni. Povečanje pogosto vsebuje zelo malo dejanskih sprememb in večina podatkov v eni datoteki se ponovi.
Obstaja še ena težava - redundanca porazdeljenega shranjevanja podatkov. Uporabljamo minio in njegovi podatki so v bistvu odveč. Ali pa ste morali narediti varnostno kopijo prek samega minia - naložite ga in uporabite vse distančnike med datotečnim sistemom in, kar je nič manj pomembno, obstaja nevarnost, da pozabite na nekatere vedra in metainformacije. Ali pa uporabite deduplikacijo.

Orodja za varnostno kopiranje s podvajanjem so na voljo v odprti kodi (na Habréju so bili Člen o tej temi) in naši finalisti so bili Borg и Restic. Spodaj je naša primerjava obeh aplikacij, zdaj pa vam bomo povedali, kako smo organizirali celotno shemo.

Upravljanje varnostnih kopij

Borg in Restic sta dobra, vendar noben izdelek nima centraliziranega nadzornega mehanizma. Za namen vodenja in nadzora smo izbrali že implementirano orodje, brez katerega si ne moremo predstavljati svojega dela, vključno z avtomatizacijo - to je dobro znani CI/CD - GitLab.

Ideja je naslednja: gitlab-runner je nameščen na vsako vozlišče, ki shranjuje podatke Nextcloud. Runner zažene skript po urniku, ki spremlja postopek varnostnega kopiranja, in zažene Borg ali Restic.

Kaj smo dobili? Povratne informacije o izvedbi, priročen nadzor nad spremembami, podrobnosti v primeru napake.

Tu tukaj na GitHubu objavili smo primere skripta za različne naloge in na koncu smo ga priložili v varnostno kopijo ne samo Nextclouda, ampak tudi številnih drugih storitev. Tam je tudi razporejevalnik, če ga ne želite konfigurirati ročno (in tega ne želimo) in .gitlab-ci.yml

V API-ju Gitlab še ni mogoče spremeniti časovne omejitve CI/CD, vendar je majhna. Povečati ga je treba, recimo 1d.

GitLab se na srečo lahko zažene ne samo glede na objavo, ampak samo po urniku, to je točno tisto, kar potrebujemo.

Zdaj pa o ovojnem skriptu.

Za ta skript smo postavili naslednje pogoje:

• Zagnati ga mora tako tekač kot ročno iz konzole z enako funkcionalnostjo.
• Obstajati morajo obdelovalci napak:
• povratna koda.
• poiščite niz v dnevniku. Na primer, za nas je lahko napaka sporočilo, ki ga program ne šteje za usodno.
• Časovna omejitev obdelave. Dobavni rok mora biti razumen.
• Potrebujemo zelo podroben dnevnik. Vendar le v primeru napake.
• Pred začetkom se izvedejo tudi številni testi.
• Majhni bonusi za udobje, ki so se nam zdeli koristni med postopkom podpore:
• Začetek in konec sta zabeležena v sistemskem dnevniku lokalnega računalnika. To pomaga povezati sistemske napake in varnostno kopiranje.
• Del dnevnika napak, če obstaja, se izpiše v stdout, celoten dnevnik pa se zapiše v ločeno datoteko. Primerno je takoj pogledati CI in ovrednotiti napako, če je nepomembna.
• Načini odpravljanja napak.

Celoten dnevnik se shrani kot artefakt v GitLab; če ni napake, se dnevnik izbriše. Skript napišemo v bashu.

Z veseljem bomo upoštevali vse predloge in komentarje glede odprte kode - dobrodošli.

Kako to deluje

Na rezervnem vozlišču se zažene tekalnik z izvajalcem Bash. Glede na razporejevalnik se opravilo CI/CD zažene v posebni repi. Runner zažene univerzalni ovojni skript za takšna opravila, preveri veljavnost rezervnega repozitorija, mount točk in vsega, kar želimo, nato varnostno kopira in počisti staro. Sama dokončana varnostna kopija se pošlje v S3.

Delamo po tej shemi - je zunanji ponudnik AWS ali ruski ekvivalent (je hitrejši in podatki ne zapustijo Ruske federacije). Ali pa za te namene naročniku na njegovo spletno stran namestimo ločen minio grozd. To ponavadi naredimo iz varnostnih razlogov, ko odjemalec ne želi, da podatki sploh zapustijo njegovo vezje.

Nismo uporabili funkcije pošiljanja varnostne kopije prek ssh. To ne dodaja varnosti, omrežne zmogljivosti ponudnika S3 pa so veliko višje od naše enotne ssh naprave.

Če želite zaščititi svoj lokalni računalnik pred hekerjem, ker lahko izbriše podatke na S3, morate omogočiti različico.
Varnostna kopija vedno šifrira varnostno kopijo.

Borg ima nešifriran način none, vendar toplo ne priporočamo vklopa. V tem načinu ne samo, da ne bo šifriranja, ampak tudi kontrolna vsota zapisanega ni izračunana, kar pomeni, da je celovitost mogoče preveriti le posredno, z uporabo indeksov.

Ločen razporejevalnik preverja varnostne kopije glede celovitosti indeksov in vsebine. Kontrola je počasna in dolga, zato jo izvajamo posebej enkrat mesečno. Lahko traja več dni.

Readme v ruščini

Glavne funkcije

• prepare priprava
• testcheck preverjanje pripravljenosti
• maincommand jedro ekipe
• forcepostscript funkcija, ki se izvede na koncu ali po napaki. Uporabljamo ga za odklop particije.

Storitvene funkcije

• cleanup Zabeležimo napake ali izbrišemo dnevniško datoteko.
• checklog razčleniti dnevnik za pojav vrstice z napako.
• ret izhodni vodnik.
• checktimeout preveri časovno omejitev.

okolje

• VERBOSE=1 Napake takoj prikažemo na zaslonu (stdout).
• SAVELOGSONSUCCES=1 shranite dnevnik po uspehu.
• INIT_REPO_IF_NOT_EXIST=1 Ustvarite repozitorij, če ne obstaja. Privzeto onemogočeno.
• TIMEOUT najdaljši čas za glavno operacijo. Na koncu ga lahko nastavite kot 'm', 'h' ali 'd'.

Način shranjevanja starih izvodov. Privzeto:

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

Spremenljivke znotraj skripta

• ERROR_STRING — niz za prijavo dnevnika za napako.
• EXTRACT_ERROR_STRING — izraz za prikaz niza ob napaki.
• KILL_TIMEOUT_SIGNAL — signal za ubijanje, če je pretekel čas.
• TAIL — koliko nizov z napakami na zaslonu.
• COLORMSG — barva sporočila (privzeto rumena).

Tista skripta, ki se imenuje wordpress, ima pogojno ime, njena finta je v tem, da tudi varnostno kopira bazo mysql. To pomeni, da se lahko uporablja za namestitve Nexcloud z enim vozliščem, kjer lahko tudi varnostno kopirate bazo podatkov. Priročnost ni le v tem, da je vse na enem mestu, ampak je tudi vsebina baze podatkov blizu vsebini datotek, saj je časovna razlika minimalna.

Restic proti Borgu

Obstajajo tudi primerjave med Borgom in Resticem tukaj na Habréju, in nismo imeli naloge narediti še enega, ampak svojega. Pomembno nam je bilo, kako bo to videti na naših podatkih, z našimi specifikami. Pripeljemo jih.

Naša izbirna merila poleg že omenjenih (deduplikacija, hitra obnovitev itd.):

• Odpor do nedokončanega dela. Preverite za ubijanje -9.
• Velikost na disku.
• Potreba po virih (CPU, pomnilnik).
• Velikost shranjenih madežev.
• Delo s S3.
• Preverjanje integritete.

Za testiranje smo vzeli enega odjemalca z realnimi podatki in skupno velikostjo 1,6 TB.
Pogoji.

Borg ne zna delati direktno s S3, disk pa smo montirali kot varovalko, preko trapasto. Restic ga je poslal samemu S3.

Goofys deluje zelo hitro in dobro in obstajajo modul diskovnega predpomnilnika, kar še dodatno pospeši delo. Je v fazi beta in, odkrito povedano, med testi (drugi) smo se zrušili zaradi izgube podatkov. Toda ugodnost je v tem, da sam postopek varnostnega kopiranja ne zahteva veliko branja, ampak predvsem pisanja, zato predpomnilnik uporabljamo samo med preverjanjem integritete.

Za zmanjšanje vpliva omrežja smo uporabili lokalnega ponudnika - Yandex Cloud.

Rezultati primerjalnega testiranja.

• Ubijanje -9 z nadaljnjim ponovnim zagonom je bilo uspešno.
• Velikost na disku. Borg lahko stisne, zato so rezultati pričakovani.

Backuper
Velikost

Borg
562Gb

Restic
628Gb

• Po procesorju
  Sam Borg porabi malo, s privzetim stiskanjem, vendar ga je treba oceniti skupaj s postopkom goofys. Skupaj sta primerljiva in uporabljata približno 1,2 jedra na istem testnem virtualnem stroju.
• Spomin. Restic je približno 0,5 GB, Borg pa približno 200 MB. Toda vse to je nepomembno v primerjavi s predpomnilnikom sistemskih datotek. Zato je priporočljivo dodeliti več pomnilnika.
• Razlika v velikosti madežev je bila presenetljiva.

Backuper
Velikost

Borg
približno 500 MB

Restic
približno 5 MB

• Resticova izkušnja S3 je odlična. Delo z Borgom prek goofysa ne sproža nobenih vprašanj, vendar je bilo ugotovljeno, da je priporočljivo narediti umount, ko je varnostna kopija končana, da popolnoma ponastavite predpomnilnik. Posebnost S3 je, da premalo črpani kosi nikoli ne bodo poslani v vedro, kar pomeni, da nepopolno izpolnjeni podatki povzročijo veliko škodo.
• Preverjanje celovitosti deluje dobro v obeh primerih, vendar se hitrost bistveno razlikuje.
  Restic 3,5 ure.
  Borg, s 100 GB predpomnilnikom datotek SSD – 5 ure.Približno enak rezultat hitrosti, če so podatki na lokalnem disku.
  Borg bere neposredno iz S3 brez predpomnilnika 33 ure. Pošastno dolga.

Bistvo je, da lahko Borg stisne in ima večje blobove - zaradi česar so shranjevanje in operacije GET/PUT v S3 cenejše. Toda to gre za ceno bolj zapletenega in počasnejšega preverjanja. Kar zadeva hitrost okrevanja, nismo opazili nobene razlike. Restic potrebuje naslednje varnostne kopije (po prvi) nekoliko dlje, vendar ne bistveno.

Ne nazadnje je bila pri izbiri pomembna tudi velikost skupnosti.

In izbrali smo borg.

Nekaj ​​besed o stiskanju

Borg ima v svojem arzenalu odličen nov algoritem stiskanja - zstd. Kakovost stiskanja ni slabša od gzip, vendar veliko hitrejša. In po hitrosti primerljiv s privzetim lz4.

Na primer, izpis baze podatkov MySQL je stisnjen dvakrat bolje kot lz4 pri enaki hitrosti. Vendar izkušnje z resničnimi podatki kažejo, da je razlika v kompresijskem razmerju vozlišča Nextcloud zelo majhna.

Borg ima precej dodaten način stiskanja - če ima datoteka visoko entropijo, se stiskanje sploh ne uporabi, kar poveča hitrost. Omogočeno z možnostjo pri ustvarjanju
-C auto,zstd
za algoritem zstd
S to možnostjo smo torej v primerjavi s privzetim stiskanjem dobili
560 Gb oziroma 562 Gb. Podatki iz zgornjega primera, naj vas spomnim, brez stiskanja je rezultat 628Gb. Rezultat 2 GB razlike nas je nekoliko presenetil, a smo mislili, da se bomo vseeno odločili zanj. auto,zstd.

Rezervni način preverjanja

Glede na planer se virtualni stroj zažene neposredno od ponudnika ali od odjemalca, kar močno zmanjša obremenitev omrežja. Vsaj ceneje je, kot da ga sami dvignete in zganjate 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/

Z isto shemo preverjamo datoteke z protivirusnim programom (naknadno). Navsezadnje uporabniki nalagajo različne stvari v Nextcloud in nimajo vsi protivirusnega programa. Opravljanje pregledov ob točenju vzame preveč časa in moti poslovanje.

Razširljivost je dosežena z izvajanjem tekačev na različnih vozliščih z različnimi oznakami.
Naše spremljanje zbira statuse varnostnih kopij preko GitLab API v enem oknu, po potrebi so težave zlahka opazne in prav tako enostavno lokalizirane.

Zaključek

Posledično vemo, da delamo varnostne kopije, da so naše varnostne kopije veljavne, težave, ki nastanejo z njimi, trajajo malo časa in se rešujejo na nivoju dežurnega skrbnika. Varnostne kopije zavzamejo zelo malo prostora v primerjavi s tar.gz ali Baculo.

Vir: www.habr.com