Der er mange backup-systemer, men hvad skal man gøre, hvis de servere, der administreres, er spredt over forskellige regioner og kunder, og man skal klare sig med midlerne fra operativsystemet?
Goddag, Habr!
Mit navn er Natalia. Jeg er teamleder for gruppen af applikationsadministratorer i NPO 'Krista'. Vi er ops-teamet for projektgruppen i vores virksomhed. Vi har en ret usædvanlig situation: vi installerer og vedligeholder vores software både på vores virksomhedens servere og på servere placeret hos kunderne. I den forbindelse er det ikke nødvendigt at tage backup af hele serveren. Det er kun de 'væsentlige data', der er vigtige: databaser og bestemte kataloger i filsystemet. Selvfølgelig har kunderne (eller har ikke) deres egne backup-regler og leverer ofte et eksternt lager til opbevaring af backupfiler. I sådanne tilfælde sikrer vi, at backuppen sendes til det eksterne lager efter oprettelsen.
I et stykke tid klarede vi os med et bash-script til backupformål, men som muligheden for indstillinger voksede, voksede også kompleksiteten af dette script, og på et tidspunkt kom vi til behovet for at 'nedbryde det til grunden, og derefter...'.
Færdige løsninger passede ikke af forskellige grunde: på grund af behovet for decentralisering af backuper, krav om lokal opbevaring af backuper hos kunden, kompleksiteten ved opsætningen, importsubstitution og adgangspunkt.
Vi syntes, det var enklere at skrive noget selv. Samtidig ønskede vi at få noget, der kunne dække vores situation i de næste N år, men med mulighed for potentiel udvidelse af anvendelsesområdet.
Opgavens betingelser var følgende:
- den grundlæggende backup-instance er autonom og kører lokalt
- opbevaring af backups og logs sker altid inden for kundens netværk
- instancen består af moduler – en slags 'byggeklodser'
- der kræves kompatibilitet med de anvendte Linux-distributioner, herunder ældre versioner, og det er ønskeligt med potentiel multiplatformskompatibilitet
- til at arbejde med instancen er det tilstrækkeligt med SSH-adgang, åbning af yderligere porte er ikke nødvendig
- maksimal enkelhed ved opsætning og drift
- det er muligt (men ikke nødvendigt) at have en separat instance, der gør det muligt at se tilstanden af backups centralt fra forskellige servere
Det, vi er endt med, kan ses her:
Programmet er skrevet i python3; fungerer på Debian, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentationen er tilgængelig i docs-mappen i repository'et.
De grundlæggende begreber, som systemet arbejder med:
action – en handling, der udfører én atomær operation (backup af DB, backup af mappe, flytning fra mappe A til mappe B osv.). Eksisterende actions findes i mappen core/actions
task – en opgave, et sæt actions, der beskriver én logisk "backup-opgave"
schedule – en tidsplan, et sæt task med valgfri angivelse af tidspunkt for opgaveudførelse
Backup-konfigurationen gemmes i en yaml-fil; den overordnede struktur af konfigurationen:
- generelle indstillinger
- afsnit actions: beskrivelse af handlinger, der anvendes på denne server
- afsnit schedule: beskrivelse af alle opgaver (sæt af handlinger) og tidsplan for deres kørsel via cron, hvis sådan kørsel er nødvendig
Hvad applikationen kan i øjeblikket:
- de grundlæggende operationer, vi har brug for: backup af PostgreSQL via pg_dump, backup af mapper i filsystemet via tar; operationer med ekstern lagring; rsync mellem mapper; rotation af backups (sletning af gamle kopier)
- kald af ekstern script
- manuelt udføre en enkelt opgave
/opt/KristaBackup/KristaBackup.py run make_full_dump - kan tilføje (eller fjerne) en enkelt opgave eller hele tidsplanen i crontab
/opt/KristaBackup/KristaBackup.py enable all - generering af trigger-fil baseret på resultaterne af backupen. Denne funktion er nyttig sammen med Zabbix til overvågning af backups
- kan fungere i baggrunden i webapi- eller web-tilstand
/opt/KristaBackup/KristaBackup.py web start [--api]
Forskellen mellem tilstandene: i webapi er der ikke noget egentligt webinterface, men applikationen svarer på forespørgsler fra en anden instans. For web-tilstand skal flask og flere yderligere pakker installeres, hvilket ikke er acceptabelt overalt, for eksempel i den certificerede AstraLinux SE.
Gennem webinterfacet kan man se status og logs for backups af tilsluttede servere: "web-instans" anmoder om data fra "backup-instans" via API. Adgang til web kræver autentificering, adgang til webapi – gør ikke.
Logs for backups, der ikke er gennemført korrekt, markeres med farve: warning – gul, error – rød.
Hvis administratoren ikke har brug for en huskeliste over parametre, og server-OS'erne er ensartede, kan man kompilere filen og distribuere en allerede klar pakke.
Vi distribuerer denne utility primært via Ansible, først på nogle af de mindre vigtige servere, og efter testning på alle de andre.
Resultatet er, at vi har fået et kompakt, selvstændigt kopi-værktøj, der kan automatiseres og er nemt at bruge, selv for uerfarne administratorer. Hvis det er praktisk for os, kan det være nyttigt for dig også?
Kilde: habr.com
