Hi ha molts sistemes de còpia de seguretat, però què fer si els servidors servits estan escampats per diferents regions i clients i cal conformar-se amb el sistema operatiu?
Bona tarda, Carpe!
Em dic Natalya. Sóc el líder de l'equip del grup d'administradors d'aplicacions a NPO Krista. Som Ops per al grup de projectes de la nostra empresa. Tenim una situació força singular: instal·lem i mantenim el nostre programari tant als servidors de la nostra empresa com als servidors ubicats als llocs dels clients. En aquest cas, no cal fer una còpia de seguretat de tot el servidor. Només les "dades essencials" són importants: el DBMS i els directoris individuals del sistema de fitxers. Per descomptat, els clients tenen (o no tenen) les seves pròpies normes de còpia de seguretat i sovint proporcionen algun tipus d'emmagatzematge extern per emmagatzemar-hi còpies de seguretat. En aquest cas, després de crear una còpia de seguretat, ens assegurem l'enviament a l'emmagatzematge extern.
Durant algun temps, amb finalitats de còpia de seguretat, ens vam conformar amb un script bash, però a mesura que les opcions de configuració van créixer, la complexitat d'aquest script va créixer proporcionalment i, en un moment donat, vam arribar a la necessitat de "destruir-lo a terra i després ...”.
Les solucions preparades no eren adequades per diversos motius: a causa de la necessitat de descentralitzar les còpies de seguretat, el requisit d'emmagatzemar còpies de seguretat localment al client, la complexitat de la configuració, la substitució d'importacions, les restriccions d'accés.
Ens va semblar que era més fàcil escriure alguna cosa pròpia. Al mateix temps, volia aconseguir alguna cosa que fos suficient per a la nostra situació durant els propers N anys, però amb la possibilitat d'ampliar-ne l'abast.
Les condicions de la tasca eren les següents:
- la instància de còpia de seguretat bàsica és autònoma i s'executa localment
- L'emmagatzematge de còpies de seguretat i registres sempre es troba a la xarxa del client
- una instància consta de mòduls: una mena de "constructor"
- Es requereix compatibilitat amb les distribucions de Linux actuals, incloses les obsoletes, és desitjable possible multiplataforma
- Per treballar amb la instància, l'accés mitjançant ssh és suficient; no cal obrir ports addicionals
- màxima facilitat de configuració i funcionament
- és possible (però no és necessari) tenir una instància separada que us permeti veure de manera centralitzada l'estat de les còpies de seguretat de diferents servidors
Podeu veure el que ens va ocórrer aquí:
El programari està escrit en python3; funciona a Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentació es publica al directori docs del repositori.
Conceptes bàsics que opera el sistema:
acció: una acció que implementa una operació atòmica (còpia de seguretat de la base de dades, còpia de seguretat del directori, transferència del directori A al directori B, etc.). Les accions existents es troben al directori core/actions
tasca: tasca, un conjunt d'accions que descriuen una "tasca de còpia de seguretat" lògica
calendari: programació, un conjunt de tasques amb una indicació opcional del temps d'execució de la tasca
La configuració de còpia de seguretat s'emmagatzema en un fitxer yaml; estructura general de configuració:
- Configuració general
- secció d'accions: descripció de les accions utilitzades en aquest servidor
- secció de programació: descripció de totes les tasques (conjunts d'accions) i programació per al seu llançament per cron, si es requereix aquest llançament
Què pot fer l'aplicació actualment:
- Les operacions principals per a nosaltres són compatibles: còpia de seguretat de PostgreSQL mitjançant pg_dump, còpia de seguretat del directori del sistema de fitxers mitjançant tar; operacions amb emmagatzematge extern; rsync entre directoris; rotació de còpies de seguretat (eliminació de còpies antigues)
- crida a un script extern
- execució manual d'una tasca independent
/opt/KristaBackup/KristaBackup.py run make_full_dump - podeu afegir (o eliminar) una única tasca o tota la programació al crontab
/opt/KristaBackup/KristaBackup.py enable all - generant un fitxer disparador basat en els resultats de la còpia de seguretat. Aquesta funció és útil juntament amb Zabbix per supervisar les còpies de seguretat
- pot funcionar en segon pla en mode webapi o web
/opt/KristaBackup/KristaBackup.py web start [--api]
La diferència entre els modes: webapi no té una interfície web en si, però l'aplicació respon a les peticions d'una altra instància. Per al mode web, heu d'instal·lar flask i diversos paquets addicionals, i això no és acceptable a tot arreu, per exemple en AstraLinux SE certificat.
A través de la interfície web, podeu veure l'estat i els registres de les còpies de seguretat dels servidors connectats: la "instància web" sol·licita dades de les "instàncies de còpia de seguretat" mitjançant l'API. L'accés a la web requereix autorització, l'accés a webapi no.
Els registres de còpies de seguretat incorrectes estan marcats en color: advertència - groc, error - vermell.
Si l'administrador no necessita un full de trucs sobre els paràmetres i els sistemes operatius del servidor són homogenis, podeu compilar el fitxer i distribuir el paquet preparat.
Distribuïm aquesta utilitat principalment a través d'Ansible, llançant-la primer a alguns dels servidors menys importants i després de provar-la a la resta.
Com a resultat, vam rebre una utilitat de còpia compacta i autònoma que es pot automatitzar i que la poden utilitzar fins i tot administradors sense experiència. És convenient per a nosaltres, potser també us serà útil?
Font: www.habr.com