Hvordan GitLab hjælper dig med at sikkerhedskopiere store NextCloud-lager

Hej Habr!

I dag vil jeg tale om vores erfaring med at automatisere backup af big data fra Nextcloud-lager i forskellige konfigurationer. Jeg arbejder som servicestation hos Molniya AK, hvor vi laver konfigurationsstyring af IT-systemer; Nextcloud bruges til datalagring. Herunder, med en distribueret struktur, med redundans.

Problemerne som følge af installationernes funktioner er, at der er mange data. Versionering leveret af Nextcloud, redundans, subjektive årsager og mere skaber mange dubletter.

forhistorie

Ved administration af Nextcloud opstår problemet med at organisere en effektiv backup, som skal krypteres, da dataene er værdifulde.

Vi tilbyder muligheder for at gemme backups hos os eller hos kunden på separate maskiner fra Nextcloud, hvilket kræver en fleksibel automatiseret tilgang til administration.

Der er mange klienter, alle med forskellige konfigurationer, og alle på deres egne websteder og med deres egne karakteristika. Dette er en standardteknik, når hele webstedet tilhører dig, og sikkerhedskopier er lavet af kroner; det passer ikke godt.

Lad os først se på inputdataene. Vi behøver:

• Skalerbarhed i form af en node eller flere. Til store installationer bruger vi minio som opbevaring.
• Find ud af om problemer med at udføre sikkerhedskopier.
• Du skal have en sikkerhedskopi med dine kunder og/eller hos os.
• Håndter problemer hurtigt og nemt.
• Klienter og installationer er meget forskellige fra hinanden - ensartethed kan ikke opnås.
• Gendannelseshastigheden bør være minimal i to scenarier: fuld gendannelse (katastrofe), én mappe slettet ved en fejl.
• Deduplikeringsfunktion er påkrævet.

For at løse problemet med at administrere sikkerhedskopier installerede vi GitLab. Flere detaljer ved tackling.

Vi er selvfølgelig ikke de første til at løse et sådant problem, men det forekommer os, at vores praktiske, hårdt tjente erfaring kan være interessant, og vi er klar til at dele den.

Da vores virksomhed har en open source-politik, ledte vi efter en open source-løsning. Til gengæld deler vi vores udvikling og poster dem. For eksempel er der på GitHub vores plugin til Nextcloud, som vi leverer til kunder, hvilket forbedrer datasikkerheden i tilfælde af utilsigtet eller bevidst sletning.

Værktøjer til sikkerhedskopiering

Vi begyndte vores søgen efter løsningsmetoder ved at vælge et værktøj til oprettelse af backup.

Almindelig tar + gzip fungerer ikke godt - dataene er duplikeret. Et trin indeholder ofte meget få faktiske ændringer, og meget af dataene i en enkelt fil gentages.
Der er et andet problem - redundans af distribueret datalagring. Vi bruger minio, og dens data er grundlæggende overflødige. Eller du skulle lave en sikkerhedskopi gennem selve minio - indlæs den og brug alle afstandene mellem filsystemet, og ikke mindre vigtigt er der risiko for at glemme nogle af buckets og meta-information. Eller brug deduplikering.

Sikkerhedskopieringsværktøjer med duplikering er tilgængelige i open source (på Habré var der Artikel om dette tema) og vores finalister var Borg и Restic. Vores sammenligning af de to ansøgninger er nedenfor, men indtil videre vil vi fortælle dig, hvordan vi organiserede hele ordningen.

Håndtering af sikkerhedskopier

Borg og Restic er gode, men ingen af ​​produkterne har en centraliseret kontrolmekanisme. Med henblik på styring og kontrol valgte vi et værktøj, som vi allerede har implementeret, uden hvilket vi ikke kan forestille os vores arbejde, herunder automatisering - det er den velkendte CI/CD - GitLab.

Ideen er som følger: gitlab-runner er installeret på hver node, der lagrer Nextcloud-data. Løberen kører et script efter en tidsplan, der overvåger backup-processen, og det starter Borg eller Restic.

Hvad fik vi? Feedback fra udførelse, bekvem kontrol over ændringer, detaljer i tilfælde af fejl.

her her på GitHub vi postede eksempler på scriptet til forskellige opgaver, og vi endte med at vedhæfte det til backup af ikke kun Nextcloud, men også mange andre tjenester. Der er også en skemalægger der, hvis du ikke vil konfigurere den manuelt (og det vil vi ikke) og .gitlab-ci.yml

Der er ingen måde at ændre CI/CD timeout i Gitlab API endnu, men den er lille. Det skal øges, siger til 1d.

GitLab, heldigvis, kan lancere ikke kun i henhold til en commit, men kun i henhold til en tidsplan, det er præcis, hvad vi har brug for.

Nu om indpakningsmanuskriptet.

Vi sætter følgende betingelser for dette script:

• Den skal startes både af løberen og i hånden fra konsollen med samme funktionalitet.
• Der skal være fejlbehandlere:
• returkode.
• søg efter en streng i loggen. For os kan en fejl f.eks. være en besked, som programmet ikke betragter som fatal.
• Behandlingstimeout. Leveringstiden skal være rimelig.
• Vi har brug for en meget detaljeret log. Men kun i tilfælde af fejl.
• Der udføres også en række tests inden start.
• Små bonusser for nemheds skyld, som vi fandt nyttige under supportprocessen:
• Start og slut registreres i syslog på den lokale maskine. Dette hjælper med at forbinde systemfejl og sikkerhedskopiering.
• En del af fejlloggen, hvis nogen, udlæses til stdout, hele loggen skrives til en separat fil. Det er praktisk straks at se på CI og vurdere fejlen, hvis den er triviel.
• Fejlfindingstilstande.

Den fulde log gemmes som en artefakt i GitLab; hvis der ikke er nogen fejl, slettes loggen. Vi skriver manuskriptet i bash.

Vi vil med glæde overveje eventuelle forslag og kommentarer vedrørende open source - velkommen.

Hvordan fungerer denne her

En runner med en Bash executor startes på backup-knuden. Ifølge skemalæggeren lanceres job CI/CD i en speciel majroe. Løberen lancerer et universelt wrapper-script til sådanne opgaver, det tjekker gyldigheden af ​​backup-lageret, monteringspunkter og alt, hvad vi ønsker, og sikkerhedskopierer derefter og rydder op i det gamle. Selve den færdige backup sendes til S3.

Vi arbejder i henhold til denne ordning - det er en ekstern AWS-udbyder eller en tilsvarende russisk (det er hurtigere, og dataene forlader ikke Den Russiske Føderation). Eller vi installerer en separat minioklynge til klienten på hans websted til disse formål. Det gør vi normalt af sikkerhedsmæssige årsager, når klienten slet ikke ønsker, at data skal forlade deres kredsløb.

Vi brugte ikke funktionen til at sende backup via ssh. Dette tilføjer ikke sikkerhed, og netværkskapaciteterne hos S3-udbyderen er meget højere end vores ene ssh-maskine.

For at beskytte din lokale maskine mod en hacker, da han kan slette data på S3, skal du aktivere versionering.
Sikkerhedskopien krypterer altid sikkerhedskopien.

Borg har en ukrypteret tilstand none, men vi anbefaler på det kraftigste ikke at slå det til. I denne tilstand vil der ikke kun være nogen kryptering, men kontrolsummen af ​​det, der skrives, beregnes ikke, hvilket betyder, at integriteten kun kan kontrolleres indirekte ved hjælp af indekser.

En separat planlægger kontrollerer sikkerhedskopier for integriteten af ​​indekser og indhold. Tjekket er langsomt og langt, så vi kører det separat en gang om måneden. Det kan tage flere dage.

Læs mig på russisk

Den vigtigste funktion

• prepare uddannelse
• testcheck beredskabskontrol
• maincommand kerne hold
• forcepostscript en funktion, der udføres til sidst eller ved en fejl. Vi bruger den til at afmontere partitionen.

Servicefunktioner

• cleanup Vi registrerer fejl eller sletter logfilen.
• checklog parse loggen for forekomsten af ​​en linje med en fejl.
• ret udgangsbehandler.
• checktimeout tjek for timeout.

Miljø

• VERBOSE=1 Vi viser fejl på skærmen med det samme (stdout).
• SAVELOGSONSUCCES=1 gem loggen ved succes.
• INIT_REPO_IF_NOT_EXIST=1 Opret et lager, hvis det ikke findes. Deaktiveret som standard.
• TIMEOUT maksimal tid for hovedoperationen. Du kan indstille det som 'm', 'h' eller 'd' til sidst.

Lagringstilstand for gamle kopier. Standard:

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

Variabler inde i scriptet

• ERROR_STRING — streng for check-in-loggen for fejl.
• EXTRACT_ERROR_STRING — udtryk for vis streng hvis fejl.
• KILL_TIMEOUT_SIGNAL — signal for drab, hvis timeout.
• TAIL — hvor mange strenge med fejl på skærmen.
• COLORMSG — meddelelsens farve (standard gul).

Det script, som kaldes wordpress, har et betinget navn, dets trick er, at det også sikkerhedskopierer mysql-databasen. Det betyder, at den kan bruges til single-node Nexcloud installationer, hvor du også kan sikkerhedskopiere databasen. Bekvemmeligheden er ikke kun, at alt er samlet ét sted, men også indholdet af databasen er tæt på indholdet af filerne, da tidsforskellen er minimal.

Restic vs Borg

Der er også sammenligninger mellem Borg og Restic her på Habré, og vi havde ikke til opgave at lave bare endnu en, men vores egen. Det var vigtigt for os, hvordan det ville se ud på vores data, med vores detaljer. Vi bringer dem.

Vores udvælgelseskriterier, ud over de allerede nævnte (deduplikering, hurtig genopretning osv.):

• Modstand mod ufærdigt arbejde. Check for kill -9.
• Størrelse på disk.
• Krav til ressourcer (CPU, hukommelse).
• Størrelse af gemte klatter.
• Arbejder med S3.
• Integritetstjek.

Til test tog vi en klient med rigtige data og en samlet størrelse på 1,6 TB.
Betingelser.

Borg ved ikke, hvordan man arbejder direkte med S3, og vi monterede disken som en sikring, via fjolser. Restic sendte den til S3 selv.

Fedtmuler fungerer meget hurtigt og godt, og det er der disk cache modul, hvilket fremskynder arbejdet endnu mere. Det er i betastadiet, og ærligt talt styrtede vi ned med datatab under test (andre). Men bekvemmeligheden er, at selve sikkerhedskopieringsproceduren ikke kræver meget læsning, men mest skrivning, så vi bruger kun cachen under integritetstjek.

For at reducere netværkets indflydelse brugte vi en lokal udbyder - Yandex Cloud.

Sammenligning af testresultater.

• Kill -9 med en yderligere genstart var begge vellykkede.
• Størrelse på disk. Borg kan komprimere, så resultaterne er som forventet.

Backuper
størrelse

Borg
562Gb

Restic
628Gb

• Med CPU
  Borg selv bruger lidt med standardkomprimering, men det skal evalueres sammen med goofys-processen. I alt er de sammenlignelige og bruger omkring 1,2 kerner på den samme virtuelle testmaskine.
• Hukommelse. Restic er cirka 0,5 GB, Borg er cirka 200 MB. Men alt dette er ubetydeligt sammenlignet med systemfilens cache. Så det er tilrådeligt at allokere mere hukommelse.
• Forskellen i klatstørrelse var slående.

Backuper
størrelse

Borg
omkring 500 MB

Restic
omkring 5 MB

• Restics S3-oplevelse er fremragende. At arbejde med Borg gennem goofys rejser ingen spørgsmål, men det er blevet bemærket, at det er tilrådeligt at gøre umount efter sikkerhedskopieringen er færdig for at nulstille cachen fuldstændigt. Det særlige ved S3 er, at underpumpede bidder aldrig vil blive sendt til spanden, hvilket betyder, at ufuldstændigt udfyldte data fører til store skader.
• Integritetskontrollen fungerer godt i begge tilfælde, men hastigheden er markant forskellig.
  Restic 3,5 timer.
  Borg, med en 100 GB SSD-filcache – 5 timer.Omtrent samme hastighed resultat, hvis data er på en lokal disk.
  Borg læser direkte fra S3 uden cache 33 timer. Uhyrligt lang.

Konklusionen er, at Borg kan komprimere og har større klatter - hvilket gør opbevaring og GET/PUT operationer i S3 billigere. Men dette kommer på bekostning af mere kompleks og langsommere verifikation. Hvad angår genoprettelseshastigheden, så vi ikke nogen forskel. Restic tager efterfølgende backups (efter den første) lidt længere, men ikke væsentligt.

Sidst men ikke mindst i valget var fællesskabets størrelse.

Og vi valgte borg.

Et par ord om kompression

Borg har en fremragende ny komprimeringsalgoritme i sit arsenal - zstd. Kompressionskvaliteten er ikke værre end gzip, men meget hurtigere. Og sammenlignelig i hastighed med standard lz4.

For eksempel er en MySQL database dump komprimeret to gange bedre end lz4 ved samme hastighed. Erfaringer med rigtige data viser dog, at der er meget lille forskel i komprimeringsforholdet for Nextcloud-knuden.

Borg har en ret bonus komprimeringstilstand - hvis filen har høj entropi, så anvendes komprimering slet ikke, hvilket øger hastigheden. Aktiveret af mulighed ved oprettelse
-C auto,zstd
for zstd-algoritmen
Så med denne mulighed, i sammenligning med standardkomprimeringen, fik vi
560 Gb og 562 Gb henholdsvis. Dataene fra eksemplet ovenfor, lad mig minde dig om, uden komprimering er resultatet 628 Gb. Resultatet af en forskel på 2 GB overraskede os noget, men vi troede, at vi alligevel ville vælge det. auto,zstd.

Backup-bekræftelsesmetode

Ifølge planlæggeren lanceres den virtuelle maskine direkte fra udbyderen eller fra klienten, hvilket reducerer netværksbelastningen kraftigt. Det er i hvert fald billigere end at hæve det selv og drive trafik.

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/

Ved at bruge samme skema kontrollerer vi filer med et antivirus (efter faktum). Brugere uploader jo forskellige ting til Nextcloud, og ikke alle har et antivirus. At udføre inspektioner på tidspunktet for hældning tager for meget tid og forstyrrer forretningen.

Skalerbarhed opnås ved at køre løbere på forskellige noder med forskellige tags.
Vores overvågning indsamler sikkerhedskopieringsstatusser via GitLab API'et i ét vindue; hvis det er nødvendigt, opdages problemer nemt og lige så let lokaliserede.

Konklusion

Som et resultat ved vi med sikkerhed, at vi laver backups, at vores backups er gyldige, problemer, der opstår med dem, tager kort tid og løses på vagtadministratorniveau. Sikkerhedskopier fylder virkelig lidt sammenlignet med tar.gz eller Bacula.

Kilde: www.habr.com