Există multe soluții de backup, dar ce este de făcut când serverele gestionate sunt dispersate în diferite regiuni și clienți și trebuie să ne bazăm pe resursele sistemului de operare?
Bună ziua, Habr!
Mă numesc Natalia. Sunt liderul echipei de administratori de aplicații la NPO „Crista”. Suntem Ops pentru grupul de proiecte al companiei noastre. Avem o situație destul de specială: instalăm și întreținem software-ul nostru atât pe serverele companiei noastre, cât și pe serverele amplasate la clienți. În acest context, nu este necesar să facem backup complet al serverului. Sunt importante doar „datele esențiale”: bazele de date și anumite directoare din sistemul de fișiere. Desigur, clienții au (sau nu au) reglementările lor de backup și de multe ori oferă un stoc extern pentru a depozita backup-uri. În acest caz, după crearea backup-ului, ne asigurăm că acesta este trimis în stocarea externă.
O perioadă de timp pentru scopurile de backup ne-am descurcat cu un script bash, dar pe măsură ce opțiunile de configurare s-au diversificat, complexitatea acestui script a crescut, și într-o zi minunată am ajuns la necesitatea de a-l "desființa până la temelii, iar apoi....".
Soluțiile gata făcute nu s-au potrivit din diverse motive: din cauza necesității de descentralizare a backup-urilor, obligației de a păstra backup-urile local la client, dificultății în configurare, importului substitutiv, restricțiilor de acces.
Ni s-a părut mai simplu să scriem ceva de sine stătător. În același timp, ne-am dorit să obținem un instrument care să fie suficient pentru situația noastră timp de următorii N ani, dar cu posibilitatea de extindere a ariei de aplicare.
Condițiile problemei au fost următoarele:
- instanța de bază de backup este autonomă, funcționează local
- stocarea backup-urilor și jurnalelor este întotdeauna în interiorul rețelei clientului
- instanța este compusă din module - un fel de "constructor"
- compatibilitate necesară cu distribuțiile de Linux folosite, inclusiv cele învechite, dorim o potențială cross-platform
- pentru a lucra cu instanța este suficient acces SSH, deschiderea unor porturi adiționale nu este necesară
- maxima simplificare a configurării și exploatării
- posibilă (dar nu obligatorie) existența unei instanțe separate, care să permită vizualizarea centralizată a stării backup-urilor de pe diferite servere
Ceea ce am realizat poate fi văzut aici:
Aplicația este scrisă în python3; funcționează pe Debian, Ubuntu, CentOS, AstraLinux 1.6.
Documentația este disponibilă în directorul docs al repository-ului.
Concepturile de bază cu care operează sistemul:
action – acțiune, care realizează o operație atomică (backup bază de date, backup director, transfer din directorul A în directorul B etc.). Acțiunile existente sunt în directorul core/actions
task – o sarcină, set de acțiuni, care descrie o „sarcină de backup” logică
schedule – un program, set de sarcini cu opțiunea de a indica timpul de execuție al sarcinii
Configurația backup-ului este stocată într-un fișier yaml; structura generală a configurației:
- setări generale
- secțiunea actions: descrierea acțiunilor utilizate pe acest server
- secțiunea schedule: descrierea tuturor sarcinilor (seturilor de acțiuni) și programul de execuție prin cron, dacă o astfel de execuție este necesară
Ce poate aplicația în prezent:
- sunt suportate operațiile de bază: backup PostgreSQL prin pg_dump, backup director sistem de fișiere prin tar; operații cu stocare externă; rsync între directoare; rotația backup-urilor (ștergerea copiilor vechi)
- apelarea unui script extern
- executarea manuală a unei sarcini individuale
/opt/KristaBackup/KristaBackup.py run make_full_dump - se poate adăuga (sau elimina) o sarcină individuală sau întregul program în crontab
/opt/KristaBackup/KristaBackup.py enable all - generarea unui fișier trigger pe baza rezultatelor backup-ului. Această funcție este utilă în legătură cu Zabbix pentru monitorizarea backup-urilor
- poate funcționa în fundal în modul webapi sau web
/opt/KristaBackup/KristaBackup.py web start [--api]
Diferența între moduri: în webapi nu există de fapt o interfață web, dar aplicația răspunde la cererile altui instanțe. Pentru modul web trebuie să instalați flask și câteva pachete suplimentare, ceea ce nu este întotdeauna acceptabil, de exemplu, în AstraLinux SE certificat.
Prin intermediul interfeței web se poate vizualiza starea și log-urile backup-urilor serverelor conectate: „instanța web” solicită date de la „instanțele de backup” prin API. Accesul la web necesită autentificare, accesul la webapi – nu.
Log-urile backup-urilor care nu au trecut corect sunt marcate cu culoare: warning – galben, error – roșu.
Dacă administratorul nu are nevoie de o foaie de parcurs cu parametrii și sistemele de operare serverelor sunt omogene, se poate compila un fișier și distribui un pachet deja gata.
Această unealtă o distribuuim în principal prin Ansible, fiind inițial implementată pe o parte din serverele cele mai puțin importante, iar după testare pe toate celelalte.
În cele din urmă, am obținut o utilitate compactă de copiere, care poate fi automatizată și este potrivită pentru utilizare chiar și de către administratori mai puțin experimentați. Este convenabil pentru noi – poate fi util și pentru voi?
Sursa: habr.com
