Arquitetura do Sistema de Backup: mudanças entre as edições
Sem resumo de edição |
Sem resumo de edição |
||
| (21 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês. |
Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês. |
||
== Visão geral == |
== Visão geral e Objetivo == |
||
O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados. |
O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script. |
||
==Topologia e Arquitetura== |
|||
===Fluxo de Dados=== |
|||
| ⚫ | |||
[[Arquivo:Screenshot 2026-09-28 at 15-44-23 dev2-zabbix Network maps.png|miniaturadaimagem]] |
|||
O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup |
|||
Como não há comando fsck(comando no linux para verificar e reparar inconsistências nos arquivos) para o ZFS, precisamos utilizar o scrub. Esse subcomando é um verificador de consistência dinâmica. Ele roda de plano de fundo em um mounted live filesystem. |
|||
#O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário. |
|||
#O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção. |
|||
#Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente. |
|||
===Camadas de Rede e Protocolos=== |
|||
'''Transporte Local:''' Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda) |
|||
'''Sincronização:''' Rsync da parte do servidor de backup |
|||
'''Gerenciamento:''' Acesso remoto via SSH |
|||
'''Monitoramento:''' Monitoramento dos scripts de backup via Zabbix e Monitoramento do servidor de produção via StatusCake |
|||
==Armazenamento== |
|||
'''Tecnologia:''' ZFS (Zettabyte File System) |
|||
'''Nome da pool:''' "dados" |
|||
'''Topologia:''' Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos. |
|||
==Lógica de Automação== |
|||
A automação de backup ocorre via Shell Script. |
|||
'''Srcipt:''' /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC, tanto com automação zabbix, quanto a versão antiga, sem automação) |
|||
''' |
|||
| ⚫ | |||
É possível encontrar informações relacionadas a como realizar a manutenção do servidor na [[Runbook de Manutenção e Troubleshooting do Servidor de Backup com Zabbix]] |
|||
Sintaxe para conferência da integridade de dados ("dados" é o nome da pool do nosso sistema de backups): |
|||
<pre>$ zpool scrub "nome_da_pool"</pre> |
|||
Edição atual tal como às 18h46min de 28 de setembro de 2026
Esta página visa documentar a arquitetura, componentes, interface e fluxo de dados do *servidor de backup*, de forma a garantir que o sistema atenda os requerimentos especificados. Tal documentação atua como um guia para os desenvolvedores, testers e stakeholder durante todo o ciclo de vida do sistema. É importante destacar que certos termos foram mantidos em inglês devido a dificuldade de achar uma tradução adequada, bem como a maior facilidade de busca por tais conceitos utilizando-se de seus nomes em inglês.
Visão geral e Objetivo[editar]
O laboratório, onde o EAPn se hospeda, abriga um servidor de backup, responsável por garantir a integridade dos dados do servidor de produção. Sua janela de execução ocorre todos os dias às 08:00 da manhã, via script.
Topologia e Arquitetura[editar]
Fluxo de Dados[editar]
O fluxo de dados segue 3 etapas: Servidor de Produção -> Dev2 -> Servidor de Backup
- O servidor de produção faz a extração de seus banco de dados, compacta os arquivos em LZMA e os envia para o servidor intermediário.
- O servidor dev2 atua como zona de transferência, recebendo os arquivos e armazenando temporariamente num diretório compartilhado. Arquitetado dessa forma, o processo de leitura dos backup's não consome poder de processamento do servidor de produção.
- Todo dia, às 8h da manhã, o servidor de backup liga sozinho, conecta-se ao dev2, via mapeamento de rede, utilizando-se do protocolo NFS(/nfs/backup), extraindo os dados para si. Os arquivos são gravados no sistema ZFS, espelhando os dados em 3 discos simultaneamente.
Camadas de Rede e Protocolos[editar]
Transporte Local: Montagem de diretório via rede usando NFS + AutoFS(montagem sob demanda)
Sincronização: Rsync da parte do servidor de backup
Gerenciamento: Acesso remoto via SSH
Monitoramento: Monitoramento dos scripts de backup via Zabbix e Monitoramento do servidor de produção via StatusCake
Armazenamento[editar]
Tecnologia: ZFS (Zettabyte File System)
Nome da pool: "dados"
Topologia: Espelhamento triplo (mirror-0). O ZFS grava o mesmo arquivo simultaneamente em 3 HD's. Se um ou dois discos queimarem, os dados permanecem intactos.
Lógica de Automação[editar]
A automação de backup ocorre via Shell Script.
Srcipt: /home/eapn/syncwithdev2.sh (também disponível na página do códigos UFSC, tanto com automação zabbix, quanto a versão antiga, sem automação)
Comandos Úteis ao Administrador[editar]
É possível encontrar informações relacionadas a como realizar a manutenção do servidor na Runbook de Manutenção e Troubleshooting do Servidor de Backup com Zabbix