Ännu en backup — mer än ett skript, enklare än ett system

Det finns många backupsystem, men vad gör man om de servrar som ska underhållas är spridda över olika regioner och kunder och man måste använda operativsystemets verktyg?

God dag, Habr!
Jag heter Natalia. Jag är teamledare för gruppen av applikationsadministratörer på NPO "Krista". Vi är operations för projektgruppen inom vårt företag. Vi har en ganska speciell situation: vi installerar och underhåller vår programvara både på våra företagsservrar och på servrar som finns hos kunder. Att ta backup av hela servern är inte nödvändigt. Endast "väsentliga data" är viktiga: databashanteringssystem och specifika kataloger i filsystemet. Klienterna har naturligtvis (eller inte) sina egna regler för backup och tillhandahåller ofta något externt lagringsutrymme för att lägga backup-filer där. I sådana fall skickar vi backupen till det externa lagret efter att den har skapats.

Under en tid använde vi ett bash-skript för backup, men när antalet konfigurationsalternativ växte, blev skriptet gradvis mer och mer komplicerat, och vid en viss tidpunkt insåg vi behovet av att "störa ner det till grunden, och sedan...".

Färdiga lösningar passade inte av olika skäl: på grund av behovet av decentraliserade backuper, krav på lokal lagring av backuper hos kunden, svårigheterna med inställning, importsubstitution och begränsad åtkomst.

Vi insåg att det var enklare att skriva något eget. Samtidigt ville vi ha något som skulle räcka för vår situation de kommande N åren, men med möjlighet till potentiell expansion av tillämpningsområdet.

Villkoren för uppgiften var följande:

1. den grundläggande backupinstansen är autonom, fungerar lokalt
2. backup och loggar lagras alltid inom kundens nätverk
3. instansen består av moduler – en slags "byggsats"
4. kompatibilitet med använda Linux-distributioner, inklusive föråldrade, önskvärt med potentiell plattformsoberoende
5. det räcker med ssh-åtkomst för att arbeta med instansen, det är inte nödvändigt att öppna ytterligare portar
6. maximal enkelhet i inställning och drift
7. det är möjligt (men inte nödvändigt) att ha en separat instans som gör det möjligt att centralt se statusen för backuper från olika servrar

Det vi har åstadkommit kan ses här: github.com/javister/krista-backup
Programmet är skrivet i python3; fungerar på Debian, Ubuntu, CentOS, AstraLinux 1.6.

Dokumentationen är lagrad i mappen docs i arkivet.

Grundläggande begrepp som systemet använder:
action – en åtgärd som utför en atomär operation (backup av databas, backup av katalog, flytt från katalog A till katalog B, etc.). Befintliga actions finns i mappen core/actions.
task – en uppgift, en uppsättning actions som beskriver en logisk "backup-uppgift".
schedule – schema, en uppsättning task med valfri anger tid för att utföra uppgiften.

Backupkonfigurationen lagras i en yaml-fil; den allmänna strukturen för config:

• gemensamma inställningar
• avsnittet actions: beskrivning av åtgärder som används på denna server.
• avsnittet schedule: beskrivning av alla uppgifter (uppsättningar av åtgärder) och schemat för deras körning via cron, om sådan körning krävs.

Ett exempel på config kan ses här.

Vad applikationen kan göra just nu:

• de viktigaste operationerna stöds: backup av PostgreSQL genom pg_dump, backup av katalog i filsystemet genom tar; operationer med extern lagring; rsync mellan kataloger; rotation av backuper (borttagning av gamla kopior).
• anrop av extern skript.
• manuell körning av enskild uppgift.

  /opt/KristaBackup/KristaBackup.py run make_full_dump

• det går att lägga till (eller ta bort) enskilda uppgifter eller hela schemat i crontab.

  /opt/KristaBackup/KristaBackup.py enable all

• generering av trigger-filer baserat på backupresultat. Denna funktion är användbar i samband med Zabbix för att övervaka backuper.
• kan köras i bakgrunden i webapi- eller webbläge.

  /opt/KristaBackup/KristaBackup.py web start [--api]

Skillnaden mellan lägena: i webapi finns det ingen egen webbgränssnitt, men applikationen svarar på förfrågningar från en annan instans. För webbläget behövs flask och några ytterligare paket, vilket inte alltid är acceptabelt, till exempel i den certifierade AstraLinux SE.

Genom webbgränssnittet kan man se status och loggar för backuper på anslutna servrar: "webb-instansen" begär data från "backup-instanser" via API. Åtkomst till web kräver autentisering, åtkomst till webapi gör inte det.

Loggar för felaktigt genomförda backuper är markerade med färg: warning – gult, error – rött.

Om administratören inte behöver en snabbguide för parametrar och serveroperativsystemen är homogena, kan man kompilera filen och distribuera ett färdigt paket.

Vi distribuerar denna nytta huvudsakligen via Ansible, för att först rulla ut det till en del av de minst viktiga servrarna, och efter testning till alla andra.

Resultatet blev att vi fick ett kompakt, fristående kopieringsverktyg som kan automatiseras och som även nybörjare kan använda. Det är bekvämt för oss – kanske det kan vara till nytta för er också?

Källa: habr.com