Hai moitos sistemas de copia de seguridade, pero que facer se os servidores servidos están espallados por diferentes rexións e clientes e necesitas conformarte co sistema operativo?
Boa tarde, Habr!
Chámome Natalya. Son o líder do equipo do grupo de administradores de aplicacións en NPO Krista. Somos Ops para o grupo de proxectos da nosa empresa. Temos unha situación bastante singular: instalamos e mantenemos o noso software tanto nos servidores da nosa empresa como nos servidores situados nos sitios dos clientes. Neste caso, non é necesario facer unha copia de seguridade de todo o servidor. Só os "datos esenciais" son importantes: o DBMS e os directorios individuais do sistema de ficheiros. Por suposto, os clientes teñen (ou non teñen) as súas propias normas de copia de seguridade e moitas veces proporcionan algún tipo de almacenamento externo para almacenar as copias de seguridade alí. Neste caso, despois de crear unha copia de seguridade, aseguramos o envío a un almacenamento externo.
Durante algún tempo, para propósitos de copia de seguridade, conformámonos cun script bash, pero a medida que crecían as opcións de configuración, a complexidade deste script creceu proporcionalmente e, nun momento dado, chegamos á necesidade de "destruílo ata o chan e despois ...”.
As solucións preparadas non eran adecuadas por varios motivos: debido á necesidade de descentralizar as copias de seguridade, á necesidade de almacenar copias de seguridade localmente no cliente, á complexidade da configuración, á substitución de importacións e ás restricións de acceso.
Pareceunos que era máis doado escribir algo propio. Ao mesmo tempo, quería conseguir algo que fose suficiente para a nosa situación para os próximos N anos, pero con posibilidade de ampliar potencialmente o alcance.
As condicións da tarefa foron as seguintes:
- a instancia de copia de seguridade básica é autónoma e execútase localmente
- o almacenamento de copias de seguridade e rexistros sempre está dentro da rede do cliente
- unha instancia consta de módulos, unha especie de "construtor"
- Requírese compatibilidade coas distribucións actuais de Linux, incluídas as desactualizadas, é desexable posible multiplataforma
- Para traballar coa instancia, o acceso a través de ssh é suficiente; non é necesario abrir portos adicionais
- máxima facilidade de configuración e operación
- é posible (pero non é necesario) ter unha instancia separada que che permita ver de forma centralizada o estado das copias de seguridade de diferentes servidores
Podes ver o que nos ocorreu aquí:
O software está escrito en python3; funciona en Debian, Ubuntu, CentOS, AstraLinux 1.6.
A documentación está publicada no directorio docs do repositorio.
Conceptos básicos que opera o sistema:
acción: unha acción que implementa unha operación atómica (copia de seguridade da base de datos, copia de seguridade do directorio, transferencia do directorio A ao directorio B, etc.). As accións existentes atópanse no directorio core/actions
tarefa: tarefa, un conxunto de accións que describen unha "tarefa de copia de seguranza" lóxica
schedule: programación, un conxunto de tarefas cunha indicación opcional do tempo de execución da tarefa
A configuración de copia de seguridade gárdase nun ficheiro yaml; estrutura xeral de configuración:
- Configuración xeral
- sección de accións: descrición das accións utilizadas neste servidor
- sección de programación: descrición de todas as tarefas (conxuntos de accións) e calendario para o seu lanzamento por cron, se é necesario.
Que pode facer a aplicación actualmente:
- As principais operacións para nós son compatibles: copia de seguridade de PostgreSQL mediante pg_dump, copia de seguridade do directorio do sistema de ficheiros mediante tar; operacións con almacenamento externo; rsync entre directorios; rotación de copia de seguridade (eliminando copias antigas)
- chamando a un script externo
- execución manual dunha tarefa separada
/opt/KristaBackup/KristaBackup.py run make_full_dump - pode engadir (ou eliminar) unha única tarefa ou a programación completa ao crontab
/opt/KristaBackup/KristaBackup.py enable all - xerando un ficheiro de activación baseado nos resultados da copia de seguridade. Esta función é útil xunto con Zabbix para supervisar as copias de seguridade
- pode funcionar en segundo plano en modo webapi ou web
/opt/KristaBackup/KristaBackup.py web start [--api]
A diferenza entre os modos: webapi non ten unha interface web en si, pero a aplicación responde ás solicitudes doutra instancia. Para o modo web, cómpre instalar flask e varios paquetes adicionais, e isto non é aceptable en todas partes, por exemplo en AstraLinux SE certificado.
A través da interface web, pode ver o estado e os rexistros das copias de seguridade dos servidores conectados: a "instancia web" solicita datos das "instancias de copia de seguranza" a través da API. O acceso á web require autorización, o acceso a webapi non.
Os rexistros de copias de seguridade incorrectas están marcados en cor: aviso - amarelo, erro - vermello.
Se o administrador non necesita unha folla de trucos sobre os parámetros e os sistemas operativos do servidor son homoxéneos, pode compilar o ficheiro e distribuír o paquete preparado.
Distribuímos esta utilidade principalmente a través de Ansible, lanzándoa primeiro a algúns dos servidores menos importantes e despois de probala a todo o resto.
Como resultado, recibimos unha utilidade de copia compacta e autónoma que se pode automatizar e que pode ser utilizada mesmo por administradores sen experiencia. É conveniente para nós; quizais tamén che sexa útil?
Fonte: www.habr.com