Varundusüsteeme on palju, kuid mida teha, kui hallatavad serverid on erinevates piirkondades ja klientidel ning tuleb piirduda operatsioonisüsteemi vahenditega?
Tere päevast, Habr!
Minu nimi on Natalja. Olen rakenduste administraatorite grupi tiimijuht ettevõttes NPO "Krista". Me oleme opsigrupiks meie ettevõtte projektigruppidele. Meie olukord on üsna spetsiifiline: paigaldame ja toetame meie tarkvara nii meie ettevõtte serverites kui ka klientide serverites. Samuti pole serveri täielik varundamine alati vajalik. Olulised andmed on pärit andmebaasist ja teatud failisüsteemi kataloogidest. Muidugi, klientidel on (või ei ole) oma varundamisreeglid ja sageli pakuvad nad mingit välist salvestusruumi varukoopiate ladustamiseks. Sellisel juhul tagame varukoopia loomise järel saatmise välishoidlasse.
Mõnda aega kasutasime varukoopiate jaoks bash-skripti, kuid seadistuste arvu kasvades kasvas ka selle skripti keerukus ja ühel hetkel jõudsime vajaduseni see "kokku varustada ja siis...".
Valmis lahendus ei sobinud mitmel põhjusel: andmete dekestreerimise vajadus, kohustus hoida varukoopiaid kliendi kohapeal, seadistamise keerukus, asendamine, juurdepääsupiirangud.
Meile tundus lihtsam kirjutada midagi enda loodud. Samas soovisime midagi, mis kataks meie vajadusi järgnevate N aastate jooksul, kuid võimaldaks ka potentsiaalset laienemist.
Ülesande tingimused olid järgmised:
- alustus varukoopia instants on autonoomne, töötab kohapeal
- varukoopiate ja logide säilitamine alati kliendi võrgus
- instants koosneb moodulitest — omamoodi 'ehituskomplekt'
- vajalik on ühilduvus kasutatavate Linuxi jaotustega, sealhulgas aegunud versioonidega, soovitatav on potentsiaalne platvormidevaheline ühilduvus
- instantsi tööks piisab SSH-juurdepääsust, täiendavate sadamate avamine ei ole kohustuslik
- maksimaalne seadistamise ja kasutamise lihtsus
- võimalik (aga mitte kohustuslik) on eraldi instantsi olemasolu, mis võimaldab tsentraalselt vaadata varukoopiate olekut erinevatelt serveritelt
Kuidas me sellega hakkama saime, saab vaadata siit:
Rakendus on kirjutatud python3 keeles; see töötab Debianil, Ubuntu, CentOS-il ja AstraLinux 1.6-l.
Dokumentatsioon on saadaval repozitooriumi docs kataloogis.
Peamised mõisted, millega süsteem töötab:
action – tegevus, mis teostab ühe atomaarse operatsiooni (andmebaasi varundamine, failikatalooge varundamine, failide üleviimine kataloogist A kataloogi B jne). Olemasolevad actions asuvad kataloogis core/actions
task – ülesanne, actions kogum, mis kirjeldab ühte loogilist «varundamise ülesannet»
schedule – ajakava, task'ide kogum, millel on valikuline täitmisaja määramine
Varundamise konfiguratsioon on salvestatud yaml-failis; konfiguratsiooni üldine struktuur:
- üldised seadistused
- actions jaotise: tegevuste kirjeldus, mida sellel serveril kasutatakse
- schedule jaotise: kõigi ülesannete (tegevuste kogumite) kirjeldus ja nende käivitamise ajakava croni järgi, kui selline käivitamine on vajalik
Mida rakendus praegu teha oskab:
- toetatakse meie jaoks peamisi tegevusi: PostgreSQL varundamine pg_dump kaudu, failisüsteemi katalooge varundamine tar'i kaudu; tegevused välise salvestuse jaoks; rsync kataloogide vahel; varunduste rotatsioon (vana kopeerimise eemaldamine)
- välise skripti kutsumine
- üksiku ülesande käsitsi täitmine
/opt/KristaBackup/KristaBackup.py run make_full_dump - saab lisada (või eemaldada) crontabis eraldi ülesanne või kogu ajakava
/opt/KristaBackup/KristaBackup.py enable all - triggerefaili genereerimine varukoopia tulemustest. See funktsioon on kasulik koos Zabbixiga varukoopiate jälgimiseks
- võib töötada taustal režiimis webapi või web
/opt/KristaBackup/KristaBackup.py web start [--api]
Režiimide vahe: webapi režiimis ei ole tegelikult veebiliidest, kuid rakendus vastab teise instantsi päringutele. Web režiimi jaoks tuleb paigaldada flask ja mõned täiendavad paketid, mis ei ole igal pool aktsepteeritavad, näiteks sertifitseeritud AstraLinux SE-s.
Veebiliidese kaudu saab vaadata ühendatud serverite varukoopiate olekut ja logisid: 'veeb-instants' küsib 'varukoopia-instantsidelt' andmeid läbi API. Webi ligipääs nõuab autoriseerimist, webapi ligipääs – ei.
Ebaõnnestunud varukoopiate logid märgistatakse värvidega: warning – kollane, error – punane.
Kui administraator ei vaja parameetrite jaoks abimaterjali ja serveri OS-d on ühtsed, saab faili kompileerida ja jaotada juba valmis paketi.
Levime seda utiliiti peamiselt läbi Ansible, pressides esmalt vähem olulistele serveritele, ja pärast testimist kõikidele teistele.
Kokkuvõttes saime kompaktse iseseisva kopeerimisrakenduse, mida on lihtne automatiseerida ja mis sobib kasutamiseks isegi vähekindlatele administraatoritele. Meie jaoks on see mugav – ehk on kasu ka teile?
Allikas: habr.com
