Endnu en backup - mere end et script, enklere end et system

Der er mange backup-systemer, men hvad skal man gøre, hvis de serverede servere er spredt ud over forskellige regioner og klienter, og du skal nøjes med operativsystemet?

Endnu en backup - mere end et script, enklere end et system

God dag, Habr!
Mit navn er Natalya. Jeg er teamleder for applikationsadministratorgruppen hos NPO Krista. Vi er Ops for vores virksomheds projektgruppe. Vi har en ret unik situation: Vi installerer og vedligeholder vores software både på vores virksomheds servere og på servere placeret på kundernes websteder. I dette tilfælde er det ikke nødvendigt at tage backup af hele serveren. Kun de "essentielle data" er vigtige: DBMS og individuelle filsystemmapper. Selvfølgelig har klienter (eller har ikke) deres egne sikkerhedskopieringsbestemmelser og giver ofte en form for eksternt lager til lagring af sikkerhedskopier der. I dette tilfælde, efter at have oprettet en sikkerhedskopi, sikrer vi afsendelse til eksternt lager.

I nogen tid nøjedes vi med et bash-script, men efterhånden som konfigurationsmulighederne voksede, voksede kompleksiteten af ​​dette script proportionalt, og på et tidspunkt kom vi til behovet for at "ødelægge det til jorden, og derefter ...”.

Færdige løsninger var ikke egnede af forskellige årsager: på grund af behovet for at decentralisere backups, kravet om at gemme backups lokalt hos klienten, kompleksiteten af ​​opsætningen, importsubstitution, adgangsbegrænsninger.

Det forekom os, at det var nemmere at skrive noget af vores eget. Samtidig ønskede jeg at få noget, der ville være nok til vores situation de næste N år, men med mulighed for potentielt at udvide omfanget.

Betingelserne for opgaven var som følger:

  1. den grundlæggende backup-instans er autonom og kører lokalt
  2. opbevaring af sikkerhedskopier og logfiler er altid inden for klientens netværk
  3. en instans består af moduler - en slags "konstruktør"
  4. kompatibilitet med nuværende Linux-distributioner er påkrævet, inklusive forældede, potentiel tværplatform er ønskelig
  5. For at arbejde med instansen er adgang via ssh tilstrækkelig; åbning af yderligere porte er ikke nødvendig
  6. maksimal nem opsætning og betjening
  7. det er muligt (men ikke nødvendigt) at have en separat instans, der giver dig mulighed for centralt at se status for backups fra forskellige servere

Du kan se, hvad vi fandt på her: github.com/javister/krista-backup
Softwaren er skrevet i python3; virker på Debian, Ubuntu, CentOS, AstraLinux 1.6.

Dokumentationen placeres i arkivets docs-mappe.

Grundlæggende begreber, som systemet fungerer:
handling – en handling, der implementerer én atomoperation (database backup, mappe backup, overførsel fra mappe A til mappe B osv.). Eksisterende handlinger er placeret i mappen kerne/handlinger
opgave – opgave, et sæt handlinger, der beskriver en logisk "backup-opgave"
tidsplan – tidsplan, et sæt opgaver med en valgfri indikation af opgavens udførelsestid

Sikkerhedskopieringskonfigurationen er gemt i en yaml-fil; generel konfigurationsstruktur:

  • Generelle indstillinger
  • handlingssektion: beskrivelse af handlinger brugt på denne server
  • tidsplan sektion: beskrivelse af alle opgaver (sæt af handlinger) og tidsplan for deres lancering af cron, hvis en sådan lancering er påkrævet

Et eksempel på konfiguration kan findes her

Hvad applikationen kan i øjeblikket:

  • De vigtigste operationer for os understøttes: PostgreSQL backup via pg_dump, backup af filsystembibliotek via tar; operationer med eksternt lager; rsync mellem mapper; backup rotation (sletning af gamle kopier)
  • kalder et eksternt script
  • manuel udførelse af en separat opgave
    /opt/KristaBackup/KristaBackup.py run make_full_dump
  • du kan tilføje (eller fjerne) en enkelt opgave eller hele tidsplanen til crontab
    /opt/KristaBackup/KristaBackup.py enable all
  • generere en trigger-fil baseret på backup-resultater. Denne funktion er nyttig i forbindelse med Zabbix til overvågning af sikkerhedskopier
  • kan arbejde i baggrunden i webapi eller web-tilstand
    /opt/KristaBackup/KristaBackup.py web start [--api]

Forskellen mellem tilstandene: webapi har ikke selv en webgrænseflade, men applikationen reagerer på anmodninger fra en anden instans. Til web-tilstand skal du installere kolbe og flere ekstra pakker, og det er ikke acceptabelt alle steder, for eksempel i certificeret AstraLinux SE.

Via webgrænsefladen kan du se status og logfiler for backups af tilsluttede servere: "webinstansen" anmoder om data fra "backup-instanserne" via API'en. Adgang til nettet kræver autorisation, adgang til webapi gør det ikke.

Endnu en backup - mere end et script, enklere end et system

Logfiler over forkerte sikkerhedskopier er markeret med farve: advarsel – gul, fejl – rød.

Endnu en backup - mere end et script, enklere end et system

Endnu en backup - mere end et script, enklere end et system

Hvis administratoren ikke har brug for et snydeark på parametrene, og serveroperativsystemerne er homogene, kan du kompilere filen og distribuere den færdige pakke.

Vi distribuerer dette værktøj hovedsageligt gennem Ansible, ruller det ud først til nogle af de mindst vigtige servere og efter test til alle de andre.

Som et resultat modtog vi et kompakt, selvstændigt kopiværktøj, der kan automatiseres og kan bruges selv af uerfarne administratorer. Det er praktisk for os - måske vil det også være nyttigt for dig?

Kilde: www.habr.com

Tilføj en kommentar