Obstaja veliko sistemov za varnostno kopiranje, a kaj, če so servisirani strežniki razpršeni po različnih regijah in odjemalcih in morate upravljati z orodji operacijskega sistema?
Dober dan, Habr!
Moje ime je Natalya. Sem vodja skupine skrbnikov aplikacij v NPO Krista. Skrbimo za projektno skupino našega podjetja. Imamo precej nenavadno situacijo: svojo programsko opremo nameščamo in vzdržujemo tako na strežnikih našega podjetja kot na strežnikih, ki se nahajajo na mestih strank. V tem primeru ni treba varnostno kopirati celotnega strežnika. Pomembni so le »bistveni podatki«: DBMS in posamezni imeniki datotečnega sistema. Seveda imajo odjemalci (ali nimajo) lastne pravilnike o varnostnem kopiranju in pogosto zagotovijo nekakšen zunanji pomnilnik za shranjevanje varnostnih kopij. V tem primeru po izdelavi varnostne kopije zagotovimo, da se pošlje v zunanji pomnilnik.
Nekaj časa smo za namene varnostnega kopiranja upravljali s skriptom bash, toda ko so možnosti za nastavitve rasle, je sorazmerno rasla tudi kompleksnost te skripte in v nekem lepem trenutku smo prišli do potrebe, da jo »uničimo do tal in potem ....«.
Pripravljene rešitve niso ustrezale iz različnih razlogov: zaradi potrebe po decentralizaciji varnostnih kopij, obveznosti lokalnega shranjevanja varnostnih kopij pri odjemalcu, zapletenosti nastavitev, uvozne zamenjave in omejitev dostopa.
Zdelo se nama je, da je lažje napisati nekaj svojega. Hkrati smo želeli dobiti nekaj, kar bi za naše razmere zadostovalo za naslednjih N let, a z možnostjo potencialne širitve obsega.
Pogoji naloge so bili naslednji:
- osnovni primerek varnostne kopije je brez povezave in se izvaja lokalno
- shranjevanje varnostnih kopij in dnevnikov vedno znotraj odjemalčevega omrežja
- primerek je sestavljen iz modulov - neke vrste "konstruktor"
- združljivost z uporabljenimi distribucijami Linuxa, vključno z zastarelimi, zaželena je morebitna večplatformnost
- dostop ssh zadostuje za delo s primerkom, odpiranje dodatnih vrat ni obvezno
- največja enostavnost nastavitve in delovanja
- možno je (vendar ni nujno) imeti ločen primerek, ki vam omogoča centralni pregled stanja varnostnih kopij iz različnih strežnikov
Kaj imamo si lahko ogledate tukaj:
Programska oprema je napisana v python3; deluje na Debian, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentacija je objavljena v imeniku dokumentov repozitorija.
Glavni koncepti, na katerih sistem deluje:
dejanje - dejanje, ki izvaja eno atomarno operacijo (varnostno kopiranje baze podatkov, varnostno kopiranje imenika, prenos iz imenika A v imenik B itd.). Obstoječa dejanja so v imeniku core/actions
opravilo - opravilo, nabor dejanj, ki opisuje eno logično "varnostno opravilo"
urnik – urnik, nabor nalog z neobvezno navedbo časa izvedbe naloge
Konfiguracija varnostne kopije je shranjena v datoteki yaml; splošna konfiguracijska struktura:
- Splošne nastavitve
- razdelek z dejanji: opis dejanj, uporabljenih na tem strežniku
- razdelek razporeda: opis vseh nalog (naborov dejanj) in urnik za njihov zagon po cronu, če je takšen zagon potreben
Kaj aplikacija trenutno zmore:
- podprte so glavne operacije za nas: varnostno kopiranje PostgreSQL prek pg_dump, varnostno kopiranje imenika datotečnega sistema prek tar; operacije z zunanjim pomnilnikom; rsync med imeniki; rotacija varnostne kopije (brisanje starih kopij)
- klic zunanjega skripta
- ročno izvajanje posamezne naloge
/opt/KristaBackup/KristaBackup.py run make_full_dump - v crontab lahko dodate (ali odstranite) posamezno opravilo ali celoten urnik
/opt/KristaBackup/KristaBackup.py enable all - sproži ustvarjanje datoteke na podlagi rezultatov varnostnega kopiranja. Ta funkcija je uporabna v povezavi z Zabbixom za spremljanje varnostnih kopij.
- lahko deluje v ozadju v webapi ali spletnem načinu
/opt/KristaBackup/KristaBackup.py web start [--api]
Razlika med načinoma je v tem, da webapi nima pravega spletnega vmesnika, ampak se aplikacija odziva na zahteve druge instance. Za spletni način morate namestiti flask in nekaj dodatnih paketov, kar ni sprejemljivo povsod, na primer v certificiranem AstraLinux SE.
Prek spletnega vmesnika si lahko ogledate status in dnevnike varnostnih kopij povezanih strežnikov: »spletna instanca« prek API-ja zahteva podatke od »varnostne instance«. Spletni dostop zahteva avtorizacijo, dostop webapi pa ne.
Dnevniki nepravilno preteklih varnostnih kopij so označeni z barvo: opozorilo - rumena, napaka - rdeča.
Če skrbnik ne potrebuje goljufanja o parametrih in so strežniški operacijski sistemi homogeni, lahko prevedete datoteko in razdelite končni paket.
Ta pripomoček distribuiramo predvsem prek Ansiblea, najprej ga uvedemo na nekatere najmanj pomembne strežnike in po testiranju na vse ostale.
Končni rezultat je kompakten samostojen pripomoček za kopiranje, ki ga je mogoče avtomatizirati in ga lahko uporabljajo tudi neizkušeni skrbniki. Za nas je priročno - morda bo koristno tudi za vas?
Vir: www.habr.com