Boa tarde, Habr !
Meu nome é Natalya. Eu sou o líder da equipe do grupo de administradores de aplicativos da NPO Krista. Somos Operações para um conjunto de projetos da nossa empresa. Temos uma situação bastante peculiar: instalamos e mantemos o nosso software tanto nos servidores da nossa empresa como nos servidores localizados nas instalações dos clientes. Nesse caso, não há necessidade de fazer backup de todo o servidor. Apenas os "dados essenciais" são importantes: o DBMS e os diretórios individuais do sistema de arquivos. Obviamente, os clientes têm (ou não têm) seus próprios regulamentos de backup e geralmente fornecem algum tipo de armazenamento externo para armazenar backups lá. Neste caso, após a criação de um backup, disponibilizamos o envio para armazenamento externo.
Por um tempo, para fins de backup, sobrevivemos com um script bash, mas à medida que as opções aumentavam, a complexidade desse script aumentava proporcionalmente e, em um ponto, chegamos à necessidade de "destruí-lo por completo e então ...".
As soluções prontas não funcionavam por vários motivos: pela necessidade de descentralizar os backups, a obrigação de armazenar os backups localmente no cliente, a complexidade da configuração, a substituição de importações e as restrições de acesso.
Pareceu-nos que era mais fácil escrever algo nosso. Ao mesmo tempo, queria obter algo que fosse suficiente para a nossa situação pelos próximos N anos, mas com a possibilidade de uma potencial expansão do escopo.
As condições do problema eram as seguintes:
- a instância de backup básica é autônoma, funciona localmente
- armazenamento de backups e logs sempre dentro da rede do cliente
- – «»
- Linux, ,
- ssh,
- ( ) ,
Você pode ver o que temos aqui: github.com/javister/krista-backup O
software é escrito em python3; funciona em Debian, Ubuntu, CentOS, AstraLinux 1.6.
A documentação está disponível no diretório docs do repositório.
Conceitos básicos usados pelo sistema:
ação - uma ação que implementa uma operação atômica (backup do banco de dados, backup do diretório, transferência do diretório A para o diretório B, etc.). As ações existentes estão no diretório core / actions
task - uma tarefa, um conjunto de ações que descreve uma
programação de "tarefa de backup" lógica - uma programação, uma tarefa definida com um tempo de execução de tarefa opcional. A
configuração de backup é armazenada em um arquivo yaml; estrutura geral de configuração:
- Configurações Gerais
- seção ações: descrição das ações usadas neste servidor
- a seção de programação: uma descrição de todas as tarefas (conjuntos de ações) e a programação para seu lançamento pela coroa, se tal lançamento for necessário
Um exemplo de configuração pode ser encontrado aqui
O que o aplicativo pode fazer no momento:
- as principais operações para nós são suportadas: backup PostgreSQL via pg_dump, backup do diretório do sistema de arquivos via tar; operações com armazenamento externo; rsync entre diretórios; rotação de backups (exclusão de cópias antigas)
- chamar script externo
- execução manual de uma única tarefa
/opt/KristaBackup/KristaBackup.py run make_full_dump - você pode adicionar (ou remover) uma tarefa separada ou toda a programação no crontab
/opt/KristaBackup/KristaBackup.py enable all - gerar um arquivo de gatilho com base nos resultados do backup. Este recurso é útil em conjunto com o Zabbix para monitorar backups
- pode funcionar em segundo plano no modo webapi ou web
/opt/KristaBackup/KristaBackup.py web start [--api]
A diferença entre os modos: o webapi não possui uma interface web adequada, mas o aplicativo responde às solicitações de outra instância. Para o modo web, você precisa instalar o flask e vários pacotes adicionais, e isso não é aceitável em todos os lugares, por exemplo, em um AstraLinux SE certificado.
Através da interface web é possível visualizar o status e os logs dos backups dos servidores conectados: a "instância web" solicita dados das "instâncias backup" via API. O acesso à web requer autorização, o acesso ao webapi não.
Os registros de backups passados incorretamente são marcados em cores: aviso - amarelo, erro - vermelho.
Se o administrador não precisar de uma folha de dicas sobre os parâmetros e os sistemas operacionais do servidor forem homogêneos, você pode compilar o arquivo e distribuir o pacote pronto.
Distribuímos esse utilitário principalmente por meio do Ansible, implementando primeiro em alguns dos servidores menos importantes e, após o teste, em todos os outros.
Como resultado, obtivemos um utilitário de cópia autônomo compacto, passível de automação e adequado para operação mesmo por administradores inexperientes. É conveniente para nós - talvez seja útil para você?