Hoe GitLab u helpt bij het maken van back-ups van grote NextCloud-opslagruimtes

Hé Habr!

Vandaag wil ik het hebben over onze ervaring met het automatiseren van de back-up van big data vanuit Nextcloud-opslag in verschillende configuraties. Ik werk als servicestation bij Molniya AK, waar we het configuratiebeheer van IT-systemen doen; Nextcloud wordt gebruikt voor gegevensopslag. Inclusief, met een gedistribueerde structuur, met redundantie.

De problemen die voortvloeien uit de kenmerken van de installaties zijn dat er veel gegevens zijn. Versiebeheer geleverd door Nextcloud, redundantie, subjectieve redenen en meer zorgen voor veel duplicaten.

prehistorie

Bij het beheer van Nextcloud ontstaat het probleem van het organiseren van een effectieve back-up, die gecodeerd moet zijn, aangezien de gegevens waardevol zijn.

Wij bieden mogelijkheden om back-ups bij ons of bij de klant op aparte machines van Nextcloud op te slaan, wat een flexibele geautomatiseerde aanpak van het beheer vereist.

Er zijn veel klanten, allemaal met verschillende configuraties, en allemaal op hun eigen sites en met hun eigen kenmerken. Dit is een standaardtechniek als de hele site van jou is en er back-ups worden gemaakt van kronen; dit past niet goed.

Laten we eerst eens kijken naar de invoergegevens. Wij hebben nodig:

• Schaalbaarheid in termen van één knooppunt of meerdere. Voor grote installaties gebruiken wij minio als opslag.
• Lees meer over problemen met het maken van back-ups.
• U dient een back-up bij uw klanten en/of bij ons te bewaren.
• Los problemen snel en gemakkelijk op.
• Klanten en installaties zijn zeer verschillend van elkaar; uniformiteit is niet te realiseren.
• De herstelsnelheid zou minimaal moeten zijn in twee scenario's: volledig herstel (ramp), één map per ongeluk gewist.
• Deduplicatiefunctie is vereist.

Om het probleem van het beheren van back-ups op te lossen, hebben we GitLab geïnstalleerd. Meer details per tackle.

Natuurlijk zijn we niet de eersten die een dergelijk probleem oplossen, maar het lijkt ons dat onze praktische, zuurverdiende ervaring interessant kan zijn en we zijn bereid deze te delen.

Omdat ons bedrijf een open source-beleid voert, waren we op zoek naar een open source-oplossing. Op onze beurt delen wij onze ontwikkelingen en plaatsen deze. Op GitHub is er bijvoorbeeld onze plug-in voor Nextcloud, die wij aan klanten leveren, waardoor de gegevensbeveiliging wordt verbeterd in geval van accidentele of opzettelijke verwijdering.

Back-uphulpmiddelen

We begonnen onze zoektocht naar oplossingsmethoden door een tool voor het maken van back-ups te kiezen.

Normale tar + gzip werkt niet goed - de gegevens zijn gedupliceerd. Een verhoging bevat vaak zeer weinig daadwerkelijke wijzigingen, en veel van de gegevens binnen één bestand worden herhaald.
Er is nog een probleem: redundantie van gedistribueerde gegevensopslag. We gebruiken minio en de gegevens ervan zijn in principe overbodig. Of je moest een back-up maken via Minio zelf - laad deze en gebruik alle spacers tussen het bestandssysteem, en, niet minder belangrijk, het risico bestaat dat je sommige buckets en meta-informatie vergeet. Of maak gebruik van deduplicatie.

Back-uptools met duplicatie zijn beschikbaar in open source (op Habré waren er Artikel over dit onderwerp) en onze finalisten waren Borg и Restisch. Onze vergelijking van de twee toepassingen vindt u hieronder, maar voor nu vertellen we u hoe we het hele schema hebben georganiseerd.

Back-ups beheren

Borg en Restic zijn goed, maar geen van beide producten heeft een gecentraliseerd controlemechanisme. Met het oog op beheer en controle hebben we gekozen voor een tool die we al hebben geïmplementeerd, zonder welke we ons werk niet kunnen voorstellen, inclusief automatisering - dit is het bekende CI/CD - GitLab.

Het idee is als volgt: gitlab-runner wordt geïnstalleerd op elk knooppunt dat Nextcloud-gegevens opslaat. De runner voert een script uit volgens een schema dat het back-upproces bewaakt, en start Borg of Restic.

Wat hebben we gekregen? Feedback van de uitvoering, gemakkelijke controle over wijzigingen, details in geval van een fout.

Hier hier op GitHub we hebben voorbeelden van het script voor verschillende taken gepost en uiteindelijk hebben we het toegevoegd aan de back-up van niet alleen Nextcloud, maar ook van vele andere services. Er is daar ook een planner, als je deze niet handmatig wilt configureren (en dat willen we niet) en .gitlab-ci.yml

Er is nog geen manier om de CI/CD-time-out in de Gitlab API te wijzigen, maar deze is klein. Het moet verhoogd worden, zeg maar 1d.

GitLab kan gelukkig niet alleen volgens een commit starten, maar ook alleen volgens een schema, dit is precies wat we nodig hebben.

Nu over het wrapper-script.

We stellen de volgende voorwaarden voor dit script:

• Het moet zowel door de hardloper als met de hand vanaf de console met dezelfde functionaliteit worden gelanceerd.
• Er moeten foutafhandelaars zijn:
• retourcode.
• zoek naar een string in het logbestand. Voor ons kan een fout bijvoorbeeld een melding zijn die het programma niet als fataal beschouwt.
• Time-out bij verwerking. De doorlooptijd moet redelijk zijn.
• We hebben een zeer gedetailleerd logboek nodig. Maar alleen in geval van een fout.
• Ook worden er een aantal testen gedaan voordat er gestart wordt.
• Kleine bonussen voor het gemak die we nuttig vonden tijdens het ondersteuningsproces:
• Het begin en einde worden vastgelegd in de syslog van de lokale machine. Dit helpt bij het verbinden van systeemfouten en back-upbewerkingen.
• Een deel van het foutenlogboek, indien aanwezig, wordt uitgevoerd naar stdout; het volledige logbestand wordt naar een afzonderlijk bestand geschreven. Het is handig om meteen naar CI te kijken en de fout te evalueren als deze triviaal is.
• Foutopsporingsmodi.

Het volledige logboek wordt opgeslagen als een artefact in GitLab; als er geen fout is, wordt het logboek verwijderd. We schrijven het script in bash.

We nemen graag alle suggesties en opmerkingen met betrekking tot open source in overweging - welkom.

Hoe werkt dit

Er wordt een runner met een Bash-uitvoerder gestart op het back-upknooppunt. Volgens de planner wordt job CI/CD gelanceerd in een speciale raap. De runner lanceert voor dergelijke taken een universeel wrapper-script, controleert de geldigheid van de back-uprepository, koppelpunten en alles wat we willen, maakt vervolgens een back-up en ruimt de oude op. De voltooide back-up zelf wordt naar S3 verzonden.

We werken volgens dit schema: het is een externe AWS-provider of een Russisch equivalent (het is sneller en de gegevens verlaten de Russische Federatie niet). Of wij installeren hiervoor een apart miniocluster bij de klant op zijn locatie. Meestal doen we dit uit veiligheidsoverwegingen, wanneer de klant helemaal niet wil dat de gegevens hun circuit verlaten.

We hebben geen gebruik gemaakt van de mogelijkheid om een ​​back-up via ssh te verzenden. Dit voegt geen beveiliging toe en de netwerkmogelijkheden van de S3-provider zijn veel hoger dan die van onze ene ssh-machine.

Om uw lokale machine tegen een hacker te beschermen, aangezien hij gegevens op S3 kan wissen, moet u versiebeheer inschakelen.
De back-up codeert altijd de back-up.

Borg heeft een niet-versleutelde modus none, maar we raden u ten zeerste af om deze in te schakelen. In deze modus zal er niet alleen geen versleuteling plaatsvinden, maar wordt de controlesom van wat er wordt geschreven niet berekend, wat betekent dat de integriteit alleen indirect kan worden gecontroleerd met behulp van indexen.

Een aparte planner controleert back-ups op de integriteit van indexen en inhoud. De controle is langzaam en lang, daarom voeren we deze een keer per maand afzonderlijk uit. Het kan enkele dagen duren.

Lees mij in het Russisch

De belangrijkste functie

• prepare opleiding
• testcheck gereedheidscontrole
• maincommand kernteam
• forcepostscript een functie die uiteindelijk of per fout wordt uitgevoerd. We gebruiken het om de partitie te ontkoppelen.

Servicefuncties

• cleanup Wij registreren fouten of wissen het logbestand.
• checklog parseer het logboek op het voorkomen van een regel met een fout.
• ret exit-handler.
• checktimeout controleer op time-out.

Milieu

• VERBOSE=1 Fouten geven wij direct weer op het scherm (stdout).
• SAVELOGSONSUCCES=1 sla het logboek op bij succes.
• INIT_REPO_IF_NOT_EXIST=1 Maak een repository aan als deze nog niet bestaat. Standaard uitgeschakeld.
• TIMEOUT maximale tijd voor de hoofdbewerking. Je kunt dit aan het einde instellen als 'm', 'h' of 'd'.

Opslagmodus voor oude exemplaren. Standaard:

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

Variabelen in het script

• ERROR_STRING — tekenreeks voor het inchecklogboek voor fouten.
• EXTRACT_ERROR_STRING — expressie voor toonreeks bij fout.
• KILL_TIMEOUT_SIGNAL — signaal voor doden bij time-out.
• TAIL — hoeveel strings met fouten op het scherm.
• COLORMSG — kleur van het bericht (standaard geel).

Dat script, dat wordpress heet, heeft een voorwaardelijke naam, de truc is dat het ook een back-up maakt van de mysql-database. Dit betekent dat het kan worden gebruikt voor Nexcloud-installaties met één knooppunt, waarbij u ook een back-up van de database kunt maken. Het gemak is niet alleen dat alles op één plek staat, maar ook de inhoud van de database ligt dicht bij de inhoud van de bestanden, omdat het tijdsverschil minimaal is.

Restic versus Borg

Er zijn ook vergelijkingen tussen Borg en Restic hier op Habré, en we hadden niet de taak om er nog één te maken, maar onze eigen. Het was belangrijk voor ons hoe het eruit zou zien op onze gegevens, met onze specifieke kenmerken. Wij brengen ze.

Onze selectiecriteria, naast de reeds genoemde (deduplicatie, snel herstel, enz.):

• Weerstand tegen onvoltooid werk. Controleer op kill -9.
• Grootte op schijf.
• Vereiste voor bronnen (CPU, geheugen).
• Grootte van opgeslagen blobs.
• Werken met S3.
• Integriteitscontrole.

Voor het testen hebben we één client met echte gegevens en een totale grootte van 1,6 TB genomen.
Voorwaarden.

Borg weet niet hoe hij rechtstreeks met S3 moet werken, en we hebben de schijf als zekering gemonteerd, via gekke dingen. Restic stuurde het naar S3 zelf.

Goofys werkt heel snel en goed, en die zijn er schijfcachemodule, wat het werk nog meer versnelt. Het bevindt zich in de bètafase en eerlijk gezegd zijn we gecrasht door gegevensverlies tijdens tests (andere). Maar het gemak is dat de back-upprocedure zelf niet veel lezen vereist, maar vooral schrijven, dus gebruiken we de cache alleen tijdens integriteitscontroles.

Om de invloed van het netwerk te verminderen, hebben we een lokale provider gebruikt: Yandex Cloud.

Vergelijking testresultaten.

• Kill -9 met een nieuwe herstart was beide succesvol.
• Grootte op schijf. Borg kan comprimeren, dus de resultaten zijn zoals verwacht.

Back-up
maat

Borg
562Gb

Restisch
628Gb

• Door CPU
  Borg zelf verbruikt weinig, met standaardcompressie, maar het moet samen met het goofys-proces worden geëvalueerd. In totaal zijn ze vergelijkbaar en gebruiken ze ongeveer 1,2 cores op dezelfde virtuele testmachine.
• Geheugen. Restic is ongeveer 0,5 GB, Borg is ongeveer 200 MB. Maar dit is allemaal onbelangrijk vergeleken met de cache van systeembestanden. Het is dus raadzaam om meer geheugen toe te wijzen.
• Het verschil in kloddergrootte was opvallend.

Back-up
maat

Borg
ongeveer 500MB

Restisch
ongeveer 5MB

• De ervaring met de S3 van Restic is uitstekend. Het werken met Borg via goofys roept geen vragen op, maar er is opgemerkt dat het raadzaam is om umount uit te voeren nadat de back-up is voltooid om de cache volledig te resetten. Het bijzondere van S3 is dat ondergepompte brokken nooit de emmer in gaan, waardoor onvolledig ingevulde data tot grote schade leidt.
• De integriteitscontrole werkt in beide gevallen goed, maar de snelheid verschilt aanzienlijk.
  Restiek 3,5 uur.
  Borg, met een SSD-bestandscache van 100 GB – 5 uurOngeveer hetzelfde snelheidsresultaat als de gegevens op een lokale schijf staan.
  Borg leest rechtstreeks van S3 zonder cache 33 uur. Monsterlijk lang.

Het komt erop neer dat Borg kan comprimeren en grotere blobs heeft - wat opslag en GET/PUT-bewerkingen in S3 goedkoper maakt. Maar dit gaat ten koste van een complexere en langzamere verificatie. Wat betreft de herstelsnelheid merkten we geen verschil. Restic duurt volgende back-ups (na de eerste) iets langer, maar niet significant.

Last but not least bij de keuze was de omvang van de gemeenschap.

En wij kozen voor borg.

Een paar woorden over compressie

Borg heeft een uitstekend nieuw compressie-algoritme in zijn arsenaal: zstd. De compressiekwaliteit is niet slechter dan gzip, maar veel sneller. En qua snelheid vergelijkbaar met de standaard lz4.

Een MySQL-databasedump wordt bijvoorbeeld twee keer beter gecomprimeerd dan lz4 met dezelfde snelheid. Uit ervaring met echte data blijkt echter dat er heel weinig verschil is in de compressieverhouding van de Nextcloud-node.

Borg heeft een nogal bonuscompressiemodus: als het bestand een hoge entropie heeft, wordt er helemaal geen compressie toegepast, wat de snelheid verhoogt. Ingeschakeld door optie bij het maken
-C auto,zstd
voor het zstd-algoritme
Dus met deze optie kregen we, in vergelijking met de standaardcompressie
560Gb en 562Gb respectievelijk. Ik wil u eraan herinneren dat de gegevens uit het bovenstaande voorbeeld zonder compressie 628 Gb zijn. Het resultaat van een verschil van 2GB verraste ons enigszins, maar we dachten dat we er toch voor zouden kiezen. auto,zstd.

Back-upverificatiemethode

Volgens de planner wordt de virtuele machine rechtstreeks vanuit de provider of vanaf de client gelanceerd, waardoor de netwerkbelasting aanzienlijk wordt verminderd. Het is in ieder geval goedkoper dan zelf opknappen en verkeer genereren.

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/

Met hetzelfde schema controleren we bestanden met een antivirusprogramma (achteraf). Gebruikers uploaden immers verschillende dingen naar Nextcloud en niet iedereen heeft een antivirusprogramma. Het uitvoeren van inspecties tijdens het storten kost te veel tijd en hindert de bedrijfsvoering.

Schaalbaarheid wordt bereikt door runners op verschillende knooppunten met verschillende tags uit te voeren.
Onze monitoring verzamelt back-upstatussen via de GitLab API in één venster; indien nodig worden problemen gemakkelijk opgemerkt en net zo gemakkelijk gelokaliseerd.

Conclusie

Hierdoor weten wij zeker dat wij back-ups maken, dat onze back-ups geldig zijn, problemen die daarmee ontstaan ​​vergen weinig tijd en worden op het niveau van de dienstdoende beheerder opgelost. Back-ups nemen heel weinig ruimte in beslag vergeleken met tar.gz of Bacula.

Bron: www.habr.com