Dar viena atsarginė kopija – daugiau nei scenarijus, paprastesnis nei sistema

Yra daug atsarginių sistemų, bet ką daryti, jei aptarnaujami serveriai yra išsibarstę po skirtingus regionus ir klientus ir jums reikia valdyti operacinės sistemos įrankius?

Dar viena atsarginė kopija – daugiau nei scenarijus, paprastesnis nei sistema

Laba diena, Bus!
Mano vardas Natalija. Esu NPO Krista programų administratorių grupės komandos vadovas. Mes dirbame mūsų įmonės projektų grupei. Turime gana savotišką situaciją: savo programinę įrangą diegiame ir prižiūrime tiek savo įmonės, tiek klientų svetainėse esančiuose serveriuose. Tokiu atveju nereikia kurti viso serverio atsarginės kopijos. Svarbūs tik „esminiai duomenys“: DBVS ir atskiri failų sistemos katalogai. Žinoma, klientai turi (arba neturi) savo atsarginių kopijų kūrimo politiką ir dažnai suteikia tam tikrą išorinę saugyklą atsarginėms kopijoms saugoti. Tokiu atveju, sukūrę atsarginę kopiją, užtikriname, kad ji būtų išsiųsta į išorinę saugyklą.

Kurį laiką atsarginės kopijos kūrimo tikslais tvarkėmės su bash scenarijumi, tačiau augant nustatymų galimybėms, šio scenarijaus sudėtingumas proporcingai augo ir vieną gražią akimirką priėjome prie poreikio „sunaikinti jį ant žemės , ir tada ....".

Paruošti sprendimai netiko dėl įvairių priežasčių: poreikio decentralizuoti atsargines kopijas, prievolės saugoti atsargines kopijas lokaliai pas klientą, nustatymų sudėtingumo, importo pakeitimo, prieigos apribojimų.

Mums atrodė, kad lengviau parašyti ką nors savo. Tuo pačiu norėjome gauti tai, ko mūsų situacijai pakaktų ateinantiems N metų, bet su galimybe potencialiai išplėsti apimtį.

Užduoties sąlygos buvo tokios:

  1. pagrindinis atsarginės kopijos egzempliorius yra neprisijungęs, veikia vietoje
  2. atsarginių kopijų ir žurnalų saugojimas visada kliento tinkle
  3. egzempliorius susideda iš modulių – toks „konstruktorius“
  4. suderinamumas su naudojamais Linux platinimais, įskaitant pasenusius, pageidautina potenciali kelių platformų
  5. ssh prieigos pakanka darbui su egzemplioriumi, papildomų prievadų atidarymas yra neprivalomas
  6. maksimalus sąrankos ir veikimo paprastumas
  7. galima (bet nebūtina) turėti atskirą egzempliorių, kuris leistų centralizuotai peržiūrėti atsarginių kopijų iš skirtingų serverių būseną

Ką turime, galite pamatyti čia: github.com/javister/krista-backup
Programinė įranga parašyta python3; veikia Debian, Ubuntu, CentOS, AstraLinux 1.6.

Dokumentacija skelbiama saugyklos dokumentų kataloge.

Pagrindinės sąvokos, pagal kurias veikia sistema:
veiksmas – veiksmas, įgyvendinantis vieną atominę operaciją (duomenų bazės atsarginė kopija, katalogo atsarginė kopija, perkėlimas iš katalogo A į katalogą B ir kt.). Esami veiksmai yra pagrindinių / veiksmų kataloge
užduotis – užduotis, veiksmų rinkinys, apibūdinantis vieną loginę „atsarginę užduotį“
tvarkaraštis – tvarkaraštis, užduočių rinkinys su pasirenkamu užduoties vykdymo laiko nurodymu

Atsarginė konfigūracija saugoma yaml faile; bendra konfigūracijos struktūra:

  • Bendrieji nustatymai
  • veiksmų skyrius: šiame serveryje naudojamų veiksmų aprašymas
  • tvarkaraščio skyrius: visų užduočių (veiksmų rinkinių) aprašymas ir jų paleidimo tvarkaraštis cron, jei toks paleidimas reikalingas

Konfigūracijos pavyzdį galite rasti čia

Ką programa gali padaryti šiuo metu:

  • palaikomos pagrindinės operacijos mums: PostgreSQL atsarginė kopija per pg_dump, failų sistemos katalogo atsarginė kopija per tar; operacijos su išorine saugykla; rsync tarp katalogų; atsarginės kopijos pasukimas (senų kopijų ištrynimas)
  • išorinio scenarijaus iškvietimas
  • vienos užduoties vykdymas rankiniu būdu
    /opt/KristaBackup/KristaBackup.py run make_full_dump
  • galite pridėti (arba pašalinti) atskirą užduotį arba visą tvarkaraštį crontab
    /opt/KristaBackup/KristaBackup.py enable all
  • suaktyvinti failų generavimą pagal atsarginės kopijos rezultatus. Ši funkcija naudinga kartu su „Zabbix“ stebint atsargines kopijas.
  • gali dirbti fone webapi arba žiniatinklio režimu
    /opt/KristaBackup/KristaBackup.py web start [--api]

Skirtumas tarp režimų yra tas, kad webapi neturi tinkamos žiniatinklio sąsajos, tačiau programa reaguoja į kito egzemplioriaus užklausas. Norėdami naudoti žiniatinklio režimą, turite įdiegti kolbą ir keletą papildomų paketų, o tai nėra priimtina visur, pavyzdžiui, sertifikuotame AstraLinux SE.

Naudodami žiniatinklio sąsają galite peržiūrėti prijungtų serverių atsarginių kopijų būseną ir žurnalus: „žiniatinklio egzempliorius“ prašo duomenų iš „atsarginių egzempliorių“ per API. Prieigai prie žiniatinklio reikalingas leidimas, žiniatinklio prieigai – ne.

Dar viena atsarginė kopija – daugiau nei scenarijus, paprastesnis nei sistema

Neteisingai buvusių atsarginių kopijų žurnalai pažymėti spalva: įspėjimas – geltona, klaida – raudona.

Dar viena atsarginė kopija – daugiau nei scenarijus, paprastesnis nei sistema

Dar viena atsarginė kopija – daugiau nei scenarijus, paprastesnis nei sistema

Jei administratoriui nereikia cheat sheet apie parametrus ir serverio operacinės sistemos yra vienalytės, galite sukompiliuoti failą ir platinti gatavą paketą.

Mes platiname šią priemonę daugiausia per Ansible, pirmiausia išleidžiame ją į kai kuriuos nereikšmingiausius serverius, o išbandžius – į visus kitus.

Galutinis rezultatas – kompaktiška atskira kopijavimo programa, kurią gali automatizuoti ir naudoti net nepatyrę administratoriai. Mums patogu – gal pravers ir jums?

Šaltinis: www.habr.com

Добавить комментарий