Hvordan GitLab hjelper deg med å sikkerhetskopiere store NextCloud-lagringer

Hei Habr!

I dag vil jeg snakke om vår erfaring med å automatisere sikkerhetskopiering av store data fra Nextcloud-lagringer i forskjellige konfigurasjoner. Jeg jobber som servicestasjon på Molniya AK, hvor vi utfører konfigurasjonsstyring av IT-systemer; Nextcloud brukes til datalagring. Inkludert, med en distribuert struktur, med redundans.

Problemene som oppstår fra funksjonene til installasjonene er at det er mye data. Versjonsbehandling levert av Nextcloud, redundans, subjektive grunner og mer skaper mange duplikater.

forhistorie

Når du administrerer Nextcloud, oppstår problemet med å organisere en effektiv sikkerhetskopi, som må krypteres, siden dataene er verdifulle.

Vi tilbyr muligheter for å lagre sikkerhetskopier hos oss eller hos kunden på separate maskiner fra Nextcloud, noe som krever en fleksibel automatisert tilnærming til administrasjon.

Det er mange klienter, alle med forskjellige konfigurasjoner, og alle på sine egne sider og med sine egne egenskaper. Dette er en standardteknikk når hele nettstedet tilhører deg, og sikkerhetskopier er laget av kroner; det passer dårlig.

La oss først se på inndataene. Vi trenger:

• Skalerbarhet i form av en node eller flere. For store installasjoner bruker vi minio som oppbevaring.
• Finn ut om problemer med å utføre sikkerhetskopiering.
• Du må ha en sikkerhetskopi med kundene dine og/eller hos oss.
• Håndter problemer raskt og enkelt.
• Klienter og installasjoner er svært forskjellige fra hverandre - enhetlighet kan ikke oppnås.
• Gjenopprettingshastigheten skal være minimal i to scenarier: full gjenoppretting (katastrofe), én mappe slettet ved en feiltakelse.
• Dedupliseringsfunksjon er nødvendig.

For å løse problemet med å administrere sikkerhetskopier, installerte vi GitLab. Flere detaljer etter takling.

Selvfølgelig er vi ikke de første som løser et slikt problem, men det ser ut til at vår praktiske, hardt opptjente erfaring kan være interessant, og vi er klare til å dele den.

Siden selskapet vårt har en åpen kildekode-policy, var vi på utkikk etter en åpen kildekode-løsning. På sin side deler vi utviklingen vår og legger dem ut. For eksempel, på GitHub er det vår plugin for Nextcloud, som vi gir til kunder, og forbedrer datasikkerheten i tilfelle utilsiktet eller forsettlig sletting.

Sikkerhetskopieringsverktøy

Vi begynte vårt søk etter løsningsmetoder ved å velge et sikkerhetskopieringsverktøy.

Vanlig tar + gzip fungerer ikke bra - dataene er duplisert. Et inkrement inneholder ofte svært få faktiske endringer, og mye av dataene i en enkelt fil gjentas.
Det er et annet problem - redundans av distribuert datalagring. Vi bruker minio og dataene er i utgangspunktet overflødige. Eller du måtte ta en sikkerhetskopi gjennom minio selv - last den og bruk alle avstandene mellom filsystemet, og, ikke mindre viktig, er det en risiko for å glemme noen av bøttene og metainformasjonen. Eller bruk deduplisering.

Sikkerhetskopieringsverktøy med duplisering er tilgjengelig i åpen kildekode (på Habré var det artikler på dette emnet) og finalistene våre var Borg и Restic. Vår sammenligning av de to søknadene er nedenfor, men foreløpig vil vi fortelle deg hvordan vi organiserte hele opplegget.

Håndtering av sikkerhetskopier

Borg og Restic er bra, men ingen av produktene har en sentralisert kontrollmekanisme. For formålet med styring og kontroll valgte vi et verktøy som vi allerede har implementert, uten hvilket vi ikke kan forestille oss arbeidet vårt, inkludert automatisering - dette er den velkjente CI/CD - GitLab.

Ideen er som følger: gitlab-runner er installert på hver node som lagrer Nextcloud-data. Løperen kjører et skript etter en tidsplan som overvåker sikkerhetskopieringsprosessen, og den starter Borg eller Restic.

Hva fikk vi? Tilbakemelding fra utførelse, praktisk kontroll over endringer, detaljer i tilfelle feil.

Her her på GitHub vi la ut eksempler på skriptet for ulike oppgaver, og vi endte opp med å legge det ved sikkerhetskopien av ikke bare Nextcloud, men også mange andre tjenester. Det er også en planlegger der hvis du ikke vil konfigurere den manuelt (og vi ikke vil) og .gitlab-ci.yml

Det er ingen måte å endre CI/CD-tidsavbrudd i Gitlab API ennå, men den er liten. Det må økes, si til 1d.

GitLab kan heldigvis lanseres ikke bare i henhold til en forpliktelse, men bare i henhold til en tidsplan, dette er akkurat det vi trenger.

Nå om innpakningsmanuset.

Vi setter følgende betingelser for dette skriptet:

• Den skal startes både av løperen og for hånd fra konsollen med samme funksjonalitet.
• Det må være feilbehandlere:
• returkode.
• søk etter en streng i loggen. For oss kan for eksempel en feil være en melding som programmet ikke anser som dødelig.
• Behandlingstidsavbrudd. Ledetiden må være rimelig.
• Vi trenger en veldig detaljert logg. Men bare ved feil.
• Det gjennomføres også en rekke tester før start.
• Små bonuser for enkelhets skyld som vi fant nyttige under støtteprosessen:
• Starten og slutten registreres i sysloggen til den lokale maskinen. Dette hjelper til med å koble sammen systemfeil og sikkerhetskopiering.
• En del av feilloggen, hvis noen, sendes ut til stdout, hele loggen skrives til en egen fil. Det er praktisk å umiddelbart se på CI og vurdere feilen hvis den er triviell.
• Feilsøkingsmoduser.

Den fullstendige loggen lagres som en artefakt i GitLab; hvis det ikke er noen feil, blir loggen slettet. Vi skriver manuset i bash.

Vi vil gjerne vurdere eventuelle forslag og kommentarer angående åpen kildekode - velkommen.

Hvordan fungerer det

En løper med en Bash-utfører startes på backup-noden. Ifølge planleggeren lanseres jobb CI/CD i en spesiell kålrot. Løperen lanserer et universal wrapper-skript for slike oppgaver, det sjekker gyldigheten av backup-depotet, monteringspunkter og alt vi ønsker, og sikkerhetskopierer og rydder opp i det gamle. Selve den ferdige sikkerhetskopien sendes til S3.

Vi jobber i henhold til denne ordningen - det er en ekstern AWS-leverandør eller en tilsvarende russisk (det er raskere og dataene forlater ikke den russiske føderasjonen). Eller vi installerer en egen minioklynge for klienten på siden hans for disse formålene. Dette gjør vi vanligvis av sikkerhetsgrunner, når klienten ikke ønsker at dataene skal forlate kretsen i det hele tatt.

Vi brukte ikke funksjonen for å sende sikkerhetskopi via ssh. Dette gir ikke sikkerhet, og nettverksmulighetene til S3-leverandøren er mye høyere enn vår ene ssh-maskin.

For å beskytte din lokale maskin mot en hacker, siden han kan slette data på S3, må du aktivere versjonskontroll.
Sikkerhetskopien krypterer alltid sikkerhetskopien.

Borg har en ukryptert modus none, men vi anbefaler på det sterkeste ikke å slå den på. I denne modusen vil det ikke bare være noen kryptering, men kontrollsummen av det som skrives blir ikke beregnet, noe som betyr at integriteten kun kan kontrolleres indirekte ved hjelp av indekser.

En separat planlegger sjekker sikkerhetskopier for integriteten til indekser og innhold. Sjekken er treg og lang, så vi kjører den separat en gang i måneden. Det kan ta flere dager.

Les meg på russisk

Hovedfunksjoner

• prepare trening
• testcheck beredskapssjekk
• maincommand kjerneteam
• forcepostscript en funksjon som utføres til slutt eller ved en feil. Vi bruker den til å demontere partisjonen.

Tjenestefunksjoner

• cleanup Vi registrerer feil eller sletter loggfilen.
• checklog analysere loggen for forekomsten av en linje med en feil.
• ret utgangshåndterer.
• checktimeout sjekk for timeout.

Miljø

• VERBOSE=1 Vi viser feil på skjermen umiddelbart (stdout).
• SAVELOGSONSUCCES=1 lagre loggen ved suksess.
• INIT_REPO_IF_NOT_EXIST=1 Opprett et depot hvis det ikke eksisterer. Deaktivert som standard.
• TIMEOUT maksimal tid for hovedoperasjonen. Du kan angi den som 'm', 'h' eller 'd' på slutten.

Lagringsmodus for gamle kopier. Misligholde:

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

Variabler inne i skriptet

• ERROR_STRING — streng for innsjekkingsloggen for feil.
• EXTRACT_ERROR_STRING — uttrykk for vis streng hvis feil.
• KILL_TIMEOUT_SIGNAL — signal for drap hvis timeout.
• TAIL — hvor mange strenger med feil på skjermen.
• COLORMSG — farge på melding (standard gul).

Det skriptet, som kalles wordpress, har et betinget navn, trikset er at det også sikkerhetskopierer mysql-databasen. Dette betyr at den kan brukes til enkel-node Nexcloud-installasjoner, hvor du også kan sikkerhetskopiere databasen. Bekvemmeligheten er ikke bare at alt er på ett sted, men også innholdet i databasen er nært innholdet i filene, siden tidsforskjellen er minimal.

Restic vs Borg

Det er også sammenligninger mellom Borg og Restic her på Habré, og vi hadde ikke oppgaven med å lage bare en annen, men vår egen. Det var viktig for oss hvordan det ville se ut på dataene våre, med våre spesifikasjoner. Vi bringer dem.

Våre utvalgskriterier, i tillegg til de som allerede er nevnt (deduplisering, rask gjenoppretting, etc.):

• Motstand mot uferdig arbeid. Se etter kill -9.
• Størrelse på disk.
• Krav til ressurser (CPU, minne).
• Størrelse på lagrede blobs.
• Jobber med S3.
• Integritetssjekk.

For testing tok vi en klient med ekte data og en total størrelse på 1,6 TB.
Forhold.

Borg vet ikke hvordan man jobber direkte med S3, og vi monterte disken som en sikring, via langbein. Restic sendte den til S3 selv.

Langbein fungerer veldig raskt og bra, og det er det diskbuffermodul, noe som setter fart på arbeidet enda mer. Den er i betastadiet, og ærlig talt krasjet den med tap av data på tester (andre). Men bekvemmeligheten er at selve backupprosedyren ikke krever mye lesing, men mest skriving, så vi bruker cachen kun under integritetssjekker.

For å redusere påvirkningen av nettverket brukte vi en lokal leverandør - Yandex Cloud.

Sammenligning av testresultater.

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

Backuper
Størrelse

Borg
562Gb

Restic
628Gb

• Med CPU
  Borg selv bruker lite, med standardkomprimering, men det må evalueres sammen med goofys-prosessen. Totalt er de sammenlignbare og bruker omtrent 1,2 kjerner på samme virtuelle testmaskin.
• Hukommelse. Restic er omtrent 0,5 GB, Borg er omtrent 200 MB. Men alt dette er ubetydelig sammenlignet med systemfilbufferen. Så det er tilrådelig å tildele mer minne.
• Forskjellen i klettstørrelse var slående.

Backuper
Størrelse

Borg
ca 500MB

Restic
ca 5MB

• Restic sin S3-opplevelse er utmerket. Å jobbe med Borg gjennom goofys reiser ingen spørsmål, men det har blitt lagt merke til at det er tilrådelig å gjøre umount etter at sikkerhetskopieringen er fullført for å tilbakestille cachen fullstendig. Det særegne med S3 er at underpumpede biter aldri vil bli sendt til bøtta, noe som betyr at ufullstendig fylte data fører til store skader.
• Integritetskontrollen fungerer bra i begge tilfeller, men hastigheten varierer betydelig.
  Restic 3,5 timer.
  Borg, med en 100 GB SSD-filbuffer – 5 timer.Omtrent samme hastighet resultat hvis dataene er på en lokal disk.
  Borg leser direkte fra S3 uten cache 33 timer. Uhyrlig lang.

Poenget er at Borg kan komprimere og har større blobs – noe som gjør lagring og GET/PUT-operasjoner i S3 billigere. Men dette kommer på bekostning av mer kompleks og langsommere verifisering. Når det gjelder gjenopprettingshastigheten, merket vi ingen forskjell. Restic tar påfølgende sikkerhetskopier (etter den første) litt lenger, men ikke nevneverdig.

Sist men ikke minst i valget var størrelsen på fellesskapet.

Og vi valgte borg.

Noen få ord om komprimering

Borg har en utmerket ny komprimeringsalgoritme i sitt arsenal - zstd. Kompresjonskvaliteten er ikke dårligere enn gzip, men mye raskere. Og sammenlignbar i hastighet med standard lz4.

For eksempel er en MySQL-databasedump komprimert to ganger bedre enn lz4 med samme hastighet. Erfaring med ekte data viser imidlertid at det er svært liten forskjell i komprimeringsforholdet til Nextcloud-noden.

Borg har en ganske bonus komprimeringsmodus - hvis filen har høy entropi, brukes ikke komprimering i det hele tatt, noe som øker hastigheten. Aktivert av alternativet når du oppretter
-C auto,zstd
for zstd-algoritmen
Så med dette alternativet, sammenlignet med standardkomprimeringen, fikk vi
henholdsvis 560 Gb og 562 Gb. La meg minne deg på dataene fra eksemplet ovenfor, uten komprimering er resultatet 628 Gb. Resultatet av en forskjell på 2 GB overrasket oss noe, men vi trodde at vi tross alt ville velge det. auto,zstd.

Metode for sikkerhetskopiering

I følge planleggeren lanseres den virtuelle maskinen direkte fra leverandøren eller fra klienten, noe som reduserer nettverksbelastningen betraktelig. Det er i det minste billigere enn å heve det selv og drive trafikk.

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 å bruke samme opplegg sjekker vi filer med et antivirus (etter faktum). Tross alt laster brukere opp forskjellige ting til Nextcloud, og ikke alle har antivirus. Å gjennomføre inspeksjoner ved skjenking tar for mye tid og forstyrrer virksomheten.

Skalerbarhet oppnås ved å kjøre løpere på forskjellige noder med forskjellige tagger.
Vår overvåking samler sikkerhetskopieringsstatuser via GitLab API i ett vindu; om nødvendig blir problemer lett lagt merke til og like lett lokalisert.

Konklusjon

Som et resultat vet vi med sikkerhet at vi tar sikkerhetskopier, at sikkerhetskopiene våre er gyldige, problemer som oppstår med dem tar kort tid og løses på vaktadministratornivå. Sikkerhetskopier tar veldig lite plass sammenlignet med tar.gz eller Bacula.

Kilde: www.habr.com