Er zijn veel back-upsystemen, maar wat als de servers die we beheren verspreid zijn over verschillende regio's en klanten en we moeten het stellen met de middelen van het besturingssysteem?
Goedemiddag, Habr!
Mijn naam is Natalia. Ik ben teamleider van de applicatiebeheerdersgroep bij NPO 'Krista'. Wij zijn Ops voor de projectgroep van ons bedrijf. We hebben een vrij specifieke situatie: we installeren en onderhouden onze software zowel op de servers van ons bedrijf als op de servers die bij klanten zijn ondergebracht. Bovendien is het niet nodig om de server volledig te back-uppen. Slechts de 'essentiƫle gegevens' zijn belangrijk: de database en specifieke mappen van het bestandssysteem. Uiteraard hebben klanten (of hebben ze niet) hun eigen back-upreglementen en bieden ze vaak een extern opslagmediatype aan voor het opslaan van de back-ups. In dat geval zorgen we ervoor dat de back-up naar het externe opslagmedium wordt gestuurd na creatie.
Een tijdlang gebruikten we een bash-script voor back-updoeleinden, maar naarmate de opties voor configuratie groeiden, werd dit script complexer en op een bepaald moment kwamen we tot de noodzaak om het 'tot de grond af te breken en dan....'.
Kant-en-klare oplossingen zijn om verschillende redenen niet geschikt: vanwege de noodzaak van gedecentraliseerde back-ups, de verplichting om back-ups lokaal bij de klant te bewaren, de complexiteit van configuratie, vervangingen door nationale productie en toegang beperkingen.
We dachten dat het makkelijker zou zijn om iets voor onszelf te schrijven. We wilden iets creƫren dat voldoende zou zijn voor onze situatie voor de komende N jaren, maar met de mogelijkheid van potentiƫle uitbreiding.
De voorwaarden van de taak waren als volgt:
- de basis instantie van de back-up is autonoom en werkt lokaal
- opslag van back-ups en logs is altijd binnen het netwerk van de klant
- de instantie bestaat uit modules - een soort 'bouwpakket'
- compatibiliteit met de gebruikte Linux-distributies is noodzakelijk, inclusief verouderde, potentieel cross-platform is wenselijk
- voor het werken met de instantie is voldoende toegang via ssh, het openen van extra poorten is niet vereist
- maximale eenvoud van configuratie en exploitatie
- het is mogelijk (maar niet verplicht) om een aparte instantie te hebben waarmee centraal de status van back-ups van verschillende servers kan worden bekeken
Wat we hebben gemaakt, kan hier worden bekeken:
De software is geschreven in python3; het werkt op Debian, Ubuntu, CentOS, AstraLinux 1.6.
De documentatie is beschikbaar in de docs-map van de repository.
Basisconcepten waar het systeem mee werkt:
actie ā een handeling die Ć©Ć©n atomische operatie uitvoert (database backup, directory backup, overdracht van directory A naar directory B, etc.). De beschikbare acties bevinden zich in de core/actions-map.
taak ā een opdracht, een reeks acties die Ć©Ć©n logische 'backup-taak' beschrijft.
schema ā een schema, een set van taken met optionele tijdsaanduiding voor het uitvoeren van de taak.
De backupconfiguratie wordt opgeslagen in een yaml-bestand; de algemene structuur van de configuratie:
- gemeenschappelijke instellingen
- sectie acties: beschrijving van de handelingen die op deze server worden gebruikt.
- sectie schema: beschrijving van alle taken (sets van acties) en het schema voor hun uitvoering via cron, indien een dergelijke uitvoering vereist is.
Wat de applicatie momenteel kan:
- de belangrijkste operaties die voor ons belangrijk zijn: backup van PostgreSQL via pg_dump, backup van een directory van het bestandssysteem via tar; operaties met externe opslag; rsync tussen directories; rotatie van backups (verwijdering van oude kopieƫn).
- oproep van een extern script.
- handmatige uitvoering van een afzonderlijke taak.
/opt/KristaBackup/KristaBackup.py run make_full_dump - het is mogelijk om een afzonderlijke taak of het hele schema toe te voegen (of te verwijderen) in de crontab.
/opt/KristaBackup/KristaBackup.py enable all - generatie van een trigger-bestand op basis van de resultaten van de backup. Deze functie is nuttig in combinatie met Zabbix voor het monitoren van backups.
- kan op de achtergrond werken in de webapi- of webmodus.
/opt/KristaBackup/KristaBackup.py web start [--api]
Het verschil tussen de modi: in webapi is er geen eigen webinterface, maar de applicatie reageert op verzoeken van een andere instantie. Voor de webmodus moeten flask en enkele extra pakketten worden geĆÆnstalleerd, wat niet overal acceptabel is, bijvoorbeeld in het gecertificeerde AstraLinux SE.
Via de webinterface kan de status en de logs van de backups van aangesloten servers worden bekeken: de 'web-instantie' vraagt gegevens op bij de 'backup-instanties' via de API. Toegang tot het web vereist autorizatie, toegang tot webapi ā niet.
Logs van onjuist verlopen backups worden gemarkeerd met kleur: warning ā geel, error ā rood.
Als de administrator geen spiekbriefje nodig heeft met parameters en de serverbesturingssystemen homogeen zijn, kan er een bestand worden gecompileerd en al een kant-en-klaar pakket worden verspreid.
We verspreiden deze tool voornamelijk via Ansible, door het eerst op een deel van de minst belangrijke servers te implementeren en na tests op alle andere.
Uiteindelijk hebben we een compacte autonome kopieertoepassing ontwikkeld die geautomatiseerd kan worden en zelfs door minder ervaren beheerders te gebruiken is. Het is handig voor ons ā misschien is het ook nuttig voor jou?
Bron: habr.com
