Este artigo encerra o ciclo sobre backup. Ele aborda a organização lógica de um servidor dedicado (ou VPS) que é conveniente para backup, além de apresentar uma opção para recuperação rápida do servidor a partir do backup, sem grandes períodos de inatividade em caso de falha.
Dados de origem
Um servidor dedicado geralmente possui pelo menos dois discos rígidos, que são utilizados para organizar um array RAID de nível um (mirror). Isso é necessário para continuar as operações do servidor caso um disco falhe. Se for um servidor dedicado comum, pode haver um controlador RAID de hardware separado, com tecnologia de caching ativa em SSD, permitindo que um ou mais SSDs sejam conectados além dos discos rígidos normais. Às vezes, são oferecidos servidores dedicados que têm apenas SATADOMs (discos pequenos, estruturalmente semelhantes a um pen drive, conectados a uma porta SATA), ou até mesmo um pen drive pequeno (8-16 GB) conectado a uma porta interna especial, sendo que os dados são obtidos de uma SAN (Storage Area Network) conectada através de uma rede de armazenamento dedicada (Ethernet 10G, FC, etc.). Existem também servidores dedicados que fazem boot diretamente da SAN. Não irei abordar essas opções, pois nestes casos a responsabilidade pelo backup do servidor geralmente recai sobre o especialista que mantém a SAN, onde frequentemente existem diferentes tecnologias proprietárias para criar snapshots de estado, desduplicação integrada e outras vantagens do administrador de sistemas, discutidas nas partes anteriores deste ciclo. O volume do array de discos de um servidor dedicado pode alcançar várias dezenas de terabytes, dependendo do número e do tamanho dos discos conectados ao servidor. No caso do VPS, os volumes são mais modestos: geralmente não ultrapassam 100 GB (mas podem ser maiores), e as tarifas para esses VPS podem facilmente ser mais altas do que as dos servidores dedicados mais baratos do mesmo provedor. Um VPS geralmente tem um único disco, pois está sob um sistema de armazenamento (ou algo hiperconvergente). Às vezes, os VPS têm vários discos com diferentes características, para diferentes finalidades:
- pequeno sistema — para instalar o sistema operacional;
- grande — para armazenamento de dados do usuário.
Ao reinstalar o sistema usando o painel de controle, o disco com dados do usuário não é apagado, mas o disco do sistema é completamente reescrito. No caso de um VPS, o provedor pode oferecer um botão que faz uma captura do estado do VPS (ou do disco), no entanto, se você instalar seu próprio sistema operacional ou esquecer de ativar o serviço necessário dentro do VPS, parte dos dados pode ainda assim ser perdida. Além do botão, geralmente é oferecido um serviço de armazenamento de dados, muitas vezes bastante limitado. Normalmente, trata-se de uma conta com acesso via protocolo FTP ou SFTP, às vezes junto com SSH, com um shell restrito (como rbash), ou limitações na execução de comandos via authorized_keys (por meio de ForcedCommand).
Um servidor dedicado está conectado à rede por meio de duas portas com velocidade de 1 Gbit/s, às vezes podem ser placas com velocidade de 10 Gbit/s. Em VPS, a interface de rede geralmente é uma só. Na maioria das vezes, os data centers não limitam a velocidade da rede dentro do data center, mas limitam a velocidade de acesso à Internet.
A carga típica de um servidor dedicado ou VPS inclui um servidor web, banco de dados e servidor de aplicativos. Às vezes, podem ser instalados diferentes serviços adicionais, incluindo para o servidor web ou banco de dados: mecanismo de busca, sistema de e-mail, etc.
O espaço para armazenamento de backups é um servidor especialmente configurado, sobre o qual será falado em mais detalhes a seguir.
Organização lógica do sistema de arquivos
Se houver um controlador RAID ou se for um VPS com um único disco e não há preferências específicas para o funcionamento do subsistema de disco (por exemplo, um disco rápido separado para o banco de dados) — todo o espaço livre é dividido assim: é criado um único particionamento, sobre o qual é criada um grupo de volumes LVM, com vários volumes: 2 pequenos do mesmo tamanho, usados como sistema de arquivos raiz (trocados alternadamente durante as atualizações para permitir um retorno rápido, ideia inspirada na distribuição Calculate Linux), outro — para a partição de swap, o restante do espaço livre é dividido em pequenos volumes, utilizados como sistema de arquivos raiz para contêineres completos, discos para máquinas virtuais, sistemas de arquivos para contas em /home (cada conta — seu próprio sistema de arquivos), sistemas de arquivos para contêineres de aplicativos.
Observação importante: os volumes devem ser totalmente autossuficientes, ou seja, não devem depender uns dos outros nem do sistema de arquivos raiz. No caso de máquinas virtuais ou contêineres, esse ponto é cumprido automaticamente. Se forem contêineres de aplicativos ou diretórios pessoais, é prudente considerar a separação dos arquivos de configuração do servidor web e de outros serviços de modo a maximizar a eliminação das dependências entre os volumes. Por exemplo, cada site funciona com seu próprio usuário, os arquivos de configuração do site ficam no diretório pessoal do usuário, nas configurações do servidor web, os arquivos de configuração dos sites não são incluídos através de /etc/nginx/conf.d/.conf, mas, por exemplo, /home//configs/nginx/*.conf
Se houver vários discos — pode-se criar um arranjo RAID por software (e configurá-lo para cache em SSD, se houver necessidade e recursos), sobre o qual montar LVM de acordo com as regras propostas acima. Além disso, nesse caso, pode-se usar ZFS ou BtrFS, mas é necessário pensar cuidadosamente: ambos exigem uma abordagem muito mais rigorosa em relação aos recursos, além disso, o ZFS não vem incluído no núcleo do Linux.
Independentemente do esquema utilizado, é sempre bom estimar a velocidade aproximada de gravação das alterações nos discos e, em seguida, calcular o tamanho do espaço livre que será reservado para a criação de snapshots. Por exemplo, se o nosso servidor estiver gravando dados a uma velocidade de 10 megabytes por segundo, e o tamanho total do array de dados for de 10 terabytes — o tempo de sincronização pode chegar a um dia (22 horas — esse é o tempo que levará para transferir esse volume pela rede de 1 Gbps) — deve-se reservar cerca de 800 GB. Na realidade, o número será menor, podendo-se dividi-lo pelo número de volumes lógicos.
Dispositivo de servidor de armazenamento de backups
A principal diferença do servidor para armazenamento de backups é que ele utiliza discos grandes, baratos e relativamente lentos. Como os HDD modernos já ultrapassaram a marca de 10 TB em um único disco, é imprescindível a aplicação de sistemas de arquivos ou RAID com somas de verificação, pois durante a reestruturação do array ou a recuperação do sistema de arquivos (que pode levar vários dias!) o segundo disco pode falhar devido à carga excessiva. Em discos com capacidade de até 1 TB, isso não era tão sensível. Para simplificar a descrição, suponho que o espaço em disco esteja dividido em duas partes aproximadamente iguais (novamente, por exemplo, usando LVM):
- volumes correspondentes nos servidores, utilizados para armazenar dados dos usuários (neles será desdobrada a última cópia de backup feita para verificação);
- volumes utilizados como repositórios BorgBackup (onde os dados para os backups irão diretamente).
O princípio de funcionamento consiste em criar volumes separados para cada servidor sob os repositórios BorgBackup, onde os dados dos servidores de produção serão armazenados. Os repositórios operam em modo apenas de adição, o que exclui a possibilidade de exclusão intencional de dados, e por meio da deduplicação e limpeza periódica dos repositórios de backups antigos (ficam as cópias anuais, as mensais do último ano, as semanais do último mês, as diárias da última semana, podendo — em casos especiais — ser geradas cópias a cada hora do último dia: no total, 24 + 7 + 4 + 12 + anuais — cerca de 50 cópias para cada servidor).
Nos repositórios do BorgBackup, o modo apenas para adição não é ativado, em vez disso, utiliza-se o ForcedCommand no .ssh/authorized_keys em um formato semelhante a este:
from="endereço do servidor",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/nome_do_servidor/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......No caminho especificado, há um script wrapper sobre o borg, que, além de iniciar o binário com os parâmetros, também inicia o processo de restauração do backup após a conclusão da coleta de dados. Para isso, o script wrapper cria um arquivo indicativo ao lado do repositório correspondente. O último backup feito é automaticamente restaurado na unidade lógica correspondente após a conclusão do processo de upload de dados.
Essa construção permite limpar periodicamente backups desnecessários, além de impedir que servidores de produção excluam qualquer coisa no servidor de armazenamento de backups.
O processo de backup
O iniciador do backup é o próprio servidor dedicado ou VPS, uma vez que esse esquema dá mais controle sobre o processo de backup por parte desse servidor. Primeiramente, é feito um instantâneo do estado do sistema de arquivos raiz ativo, que é montado e enviado com o BorgBackup para o servidor de armazenamento de backups. Após a conclusão da coleta de dados, o instantâneo é desmontado e excluído.
No caso de haver um pequeno banco de dados (até 1 GB para cada site), um dump do banco de dados é feito e salvo na unidade lógica correspondente, lá onde os outros dados desse mesmo site estão localizados, mas de forma que o dump não seja acessível através do servidor web. Se os bancos de dados forem grandes, deve-se configurar a coleta de dados 'quente', por exemplo, usando xtrabackup para MySQL, ou o funcionamento do WAL com archive_command no PostgreSQL. Neste caso, o banco de dados será restaurado separadamente dos dados dos sites.
Se contêineres ou máquinas virtuais forem utilizados, deve-se configurar o qemu-guest-agent, CRIU ou outras tecnologias necessárias. Em outros casos, normalmente não serão necessárias configurações adicionais — simplesmente criamos instantâneos das unidades lógicas, que depois são processados de forma semelhante ao instantâneo do estado do sistema de arquivos raiz. Após a coleta de dados, os instantâneos são excluídos.
O trabalho subsequente é realizado no servidor de armazenamento de backups:
- verificando o último backup realizado em cada repositório,
- verificando a presença de um arquivo de etiqueta, indicando que o processo de extração de dados foi concluído,
- realizando a recuperação de dados no volume local correspondente,
- removendo o arquivo de etiqueta,
Processo de recuperação da funcionalidade do servidor,
Se o servidor principal falhar, um servidor dedicado equivalente será iniciado, que carrega a partir de uma imagem padrão. Provavelmente, o carregamento ocorrerá pela rede, embora o técnico do Data Center que configura o servidor possa imediatamente copiar essa imagem padrão para um dos discos. O carregamento ocorre na memória RAM e, em seguida, inicia-se o processo de recuperação:
- realizando uma solicitação para anexar o dispositivo de bloco via iscsinbd ou outro protocolo similar de volume lógico, contendo o sistema de arquivos raiz do servidor falecido; como o sistema de arquivos raiz deve ser pequeno, essa etapa deve ser concluída em poucos minutos. O carregador de inicialização também é restaurado;
- recriando a estrutura dos volumes lógicos locais, anexando os volumes lógicos do servidor de backup usando o módulo do kernel dm_clone: iniciando a recuperação de dados, e as alterações são escritas imediatamente nos discos locais.
- iniciando um contêiner com todos os discos físicos disponíveis - a funcionalidade do servidor é totalmente restaurada, mas com desempenho reduzido;
- depois que a sincronização de dados é concluída, os volumes lógicos do servidor de backup são desanexados, o contêiner é desligado e o servidor é reiniciado;
Após a reinicialização, o servidor terá todos os dados que estavam no momento da criação do backup, além de incluir todas as alterações feitas durante o processo de recuperação.
Outros artigos do ciclo,
Backup, parte 7: Conclusões
Convido a discutir a proposta nos comentários, obrigado pela atenção!
Fonte: habr.com
