Er zijn veel back-upsystemen, maar wat moet u doen als de bediende servers verspreid zijn over verschillende regio's en clients en u genoegen moet nemen met het besturingssysteem?
Goede dag, Habra!
Mijn naam is Natalya. Ik ben teamleider van de groep applicatiebeheerders bij NPO Krista. Wij zijn Ops voor de projectgroep van ons bedrijf. We hebben een vrij unieke situatie: we installeren en onderhouden onze software zowel op de servers van ons bedrijf als op servers bij klanten. In dit geval is het niet nodig om een back-up van de hele server te maken. Alleen de “essentiële gegevens” zijn belangrijk: de DBMS en individuele bestandssysteemmappen. Natuurlijk hebben klanten (of hebben ze niet) hun eigen back-upregels en bieden ze vaak een soort externe opslag om daar back-ups op te slaan. In dit geval zorgen wij, na het maken van een back-up, voor verzending naar externe opslag.
Een tijdlang hebben we het voor back-updoeleinden volstaan met een bash-script, maar naarmate de configuratie-opties groeiden, groeide de complexiteit van dit script proportioneel, en op een gegeven moment kwamen we tot de noodzaak om “het op de grond te vernietigen, en dan ...”.
Kant-en-klare oplossingen waren om verschillende redenen niet geschikt: vanwege de noodzaak om back-ups te decentraliseren, de noodzaak om back-ups lokaal bij de klant op te slaan, de complexiteit van de installatie, importvervanging, toegangsbeperkingen.
Het leek ons dat het gemakkelijker was om zelf iets te schrijven. Tegelijkertijd wilde ik iets krijgen dat voldoende zou zijn voor onze situatie voor de komende N jaar, maar met de mogelijkheid om de reikwijdte mogelijk uit te breiden.
De voorwaarden van de taak waren als volgt:
- het basisback-upexemplaar is autonoom en wordt lokaal uitgevoerd
- opslag van back-ups en logs vindt altijd plaats binnen het netwerk van de klant
- een instance bestaat uit modules - een soort “constructor”
- compatibiliteit met de huidige Linux-distributies is vereist, inclusief verouderde, potentiële platformonafhankelijke distributies zijn wenselijk
- Om met de instance te werken is toegang via ssh voldoende; het openen van extra poorten is niet nodig
- maximaal installatie- en bedieningsgemak
- het is mogelijk (maar niet noodzakelijk) om een aparte instance te hebben waarmee u centraal de status van back-ups van verschillende servers kunt bekijken
Wat we bedacht hebben, kun je hier zien:
De software is geschreven in Python3; werkt op Debian, Ubuntu, CentOS, AstraLinux 1.6.
De documentatie wordt in de docs-directory van de repository geplaatst.
Basisconcepten waarmee het systeem werkt:
actie – een actie die één atomaire bewerking implementeert (databaseback-up, mapback-up, overdracht van map A naar map B, enz.). Bestaande acties bevinden zich in de directory core/actions
taak – taak, een reeks acties die één logische ‘back-uptaak’ beschrijven
planning – planning, een reeks taken met een optionele indicatie van de uitvoeringstijd van de taak
De back-upconfiguratie wordt opgeslagen in een yaml-bestand; algemene configuratiestructuur:
- Algemene instellingen
- sectie acties: beschrijving van acties die op deze server worden gebruikt
- planningssectie: beschrijving van alle taken (reeks acties) en planning voor hun lancering door cron, als een dergelijke lancering vereist is
Wat de applicatie momenteel kan doen:
- De belangrijkste bewerkingen worden voor ons ondersteund: PostgreSQL-back-up via pg_dump, back-up van bestandssysteemmap via tar; bewerkingen met externe opslag; rsync tussen mappen; back-uprotatie (oude kopieën verwijderen)
- een extern script aanroepen
- handmatige uitvoering van een afzonderlijke taak
/opt/KristaBackup/KristaBackup.py run make_full_dump - u kunt een enkele taak of het hele schema aan de crontab toevoegen (of verwijderen).
/opt/KristaBackup/KristaBackup.py enable all - het genereren van een triggerbestand op basis van back-upresultaten. Deze functie is handig in combinatie met Zabbix voor het monitoren van back-ups
- kan op de achtergrond werken in webapi of webmodus
/opt/KristaBackup/KristaBackup.py web start [--api]
Het verschil tussen de modi: webapi heeft zelf geen webinterface, maar de applicatie reageert op verzoeken van een andere instantie. Voor de webmodus moet je flask en verschillende extra pakketten installeren, en dit is niet overal acceptabel, bijvoorbeeld in gecertificeerde AstraLinux SE.
Via de webinterface kunt u de status en logs van backups van aangesloten servers bekijken: de ‘web instance’ vraagt via de API gegevens op bij de ‘backup instances’. Voor toegang tot het web is autorisatie vereist, voor toegang tot webapi niet.
Logboeken van onjuiste back-ups zijn in kleur gemarkeerd: waarschuwing – geel, fout – rood.
Als de beheerder geen spiekbriefje over de parameters nodig heeft en de serverbesturingssystemen homogeen zijn, kunt u het bestand compileren en het kant-en-klare pakket distribueren.
We distribueren dit hulpprogramma voornamelijk via Ansible, rollen het eerst uit naar enkele van de minst belangrijke servers en na het testen naar de rest.
Als gevolg hiervan hebben we een compact, zelfstandig kopieerhulpprogramma ontvangen dat kan worden geautomatiseerd en zelfs door onervaren beheerders kan worden gebruikt. Het is handig voor ons - misschien is het ook nuttig voor u?
Bron: www.habr.com