Esta nota completa o ciclo sobre backup. Ele discutirá a organização lógica de um servidor dedicado (ou VPS), conveniente para backup, e também oferecerá uma opção para restaurar rapidamente um servidor a partir de um backup sem muito tempo de inatividade em caso de desastre.
Dados iniciais
Um servidor dedicado geralmente possui pelo menos dois discos rígidos que servem para organizar uma matriz RAID de primeiro nível (espelho). Isto é necessário para poder continuar a operar o servidor se um disco falhar. Se este for um servidor dedicado regular, pode haver um controlador RAID de hardware separado com tecnologia de cache ativo no SSD, para que, além dos discos rígidos normais, um ou mais SSDs possam ser conectados. Às vezes, são oferecidos servidores dedicados, nos quais os discos locais contêm apenas SATADOM (discos pequenos, estruturalmente uma unidade flash conectada a uma porta SATA), ou mesmo uma unidade flash pequena comum (8-16 GB) conectada a uma porta interna especial, e o os dados são retirados do sistema de armazenamento, conectados através de uma rede de armazenamento dedicada (Ethernet 10G, FC, etc.), e existem servidores dedicados que são carregados diretamente do sistema de armazenamento. Não considerarei tais opções, pois nesses casos a tarefa de fazer backup do servidor passa sem problemas para o especialista que mantém o sistema de armazenamento; geralmente existem várias tecnologias proprietárias para criação de snapshots, desduplicação integrada e outras alegrias do administrador do sistema , discutido nas partes anteriores desta série. O volume da matriz de discos de um servidor dedicado pode atingir várias dezenas de terabytes, dependendo do número e tamanho dos discos conectados ao servidor. No caso do VPS, os volumes são mais modestos: geralmente não passam de 100 GB (mas também há mais), e as tarifas desse VPS podem facilmente ser mais caras do que os servidores dedicados mais baratos do mesmo hoster. Um VPS geralmente possui um disco, porque haverá um sistema de armazenamento (ou algo hiperconvergente) abaixo dele. Às vezes um VPS possui vários discos com características diferentes, para finalidades diferentes:
- sistema pequeno - para instalação do sistema operacional;
- grande - armazenando dados do usuário.
Ao reinstalar o sistema usando o painel de controle, o disco com os dados do usuário não é sobrescrito, mas o disco do sistema é completamente recarregado. Além disso, no caso de um VPS, o hoster pode oferecer um botão que tira um instantâneo do estado do VPS (ou disco), mas se você instalar seu próprio sistema operacional ou esquecer de ativar o serviço desejado dentro do VPS, alguns dos dados ainda podem ser perdidos. Além do botão, geralmente é oferecido um serviço de armazenamento de dados, na maioria das vezes muito limitado. Normalmente, esta é uma conta com acesso via FTP ou SFTP, às vezes junto com SSH, com um shell simplificado (por exemplo, rbash) ou uma restrição na execução de comandos por meio de chaves_autorizadas (via ForcedCommand).
Um servidor dedicado é conectado à rede por duas portas com velocidade de 1 Gbps, às vezes podem ser placas com velocidade de 10 Gbps. O VPS geralmente possui uma interface de rede. 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 é um servidor web, um banco de dados e um servidor de aplicativos. Às vezes, vários serviços auxiliares adicionais podem ser instalados, inclusive para um servidor web ou banco de dados: mecanismo de pesquisa, sistema de correio, etc.
Um servidor especialmente preparado funciona como um espaço para armazenar cópias de backup; escreveremos sobre isso com mais detalhes posteriormente.
Organização lógica do sistema de disco
Se você tiver um controlador RAID ou um VPS com um disco e não houver preferências especiais para a operação do subsistema de disco (por exemplo, um disco rápido separado para o banco de dados), todo o espaço livre será dividido da seguinte forma: uma partição é criado, e um grupo de volumes LVM é criado em cima dele, vários volumes são criados nele: 2 pequenos do mesmo tamanho, usados como sistema de arquivos raiz (alterados um por um durante as atualizações para a possibilidade de reversão rápida, a ideia foi tirada da distribuição Calcular Linux), outra é para a partição swap, o restante do espaço livre é dividido em pequenos volumes , usado como sistema de arquivos raiz para contêineres completos, discos para máquinas virtuais, arquivos sistemas para contas em /home (cada conta tem seu próprio sistema de arquivos), sistemas de arquivos para contêineres de aplicativos.
Nota importante: os volumes devem ser completamente independentes, ou seja, não devem depender um do outro ou do sistema de arquivos raiz. No caso de máquinas virtuais ou containers, este ponto é observado automaticamente. Se forem contêineres de aplicativos ou diretórios iniciais, você deve pensar em separar os arquivos de configuração do servidor web e outros serviços de forma a eliminar ao máximo as dependências entre os volumes. Por exemplo, cada site é executado por seu próprio usuário, os arquivos de configuração do site estão no diretório inicial do usuário, nas configurações do servidor web, os arquivos de configuração do site não são incluídos via /etc/nginx/conf.d/.conf e, por exemplo, /home//configs/nginx/*.conf
Se houver vários discos, você pode criar uma matriz RAID de software (e configurar seu cache em um SSD, se houver necessidade e oportunidade), sobre a qual você pode construir o LVM de acordo com as regras propostas acima. Também neste caso, você pode usar ZFS ou BtrFS, mas você deve pensar duas vezes sobre isso: ambos exigem uma abordagem muito mais séria aos recursos e, além disso, o ZFS não está incluído no kernel Linux.
Independentemente do esquema utilizado, vale sempre a pena estimar antecipadamente a velocidade aproximada de gravação das alterações nos discos e, a seguir, calcular a quantidade de espaço livre que será reservado para a criação dos snapshots. Por exemplo, se nosso servidor grava dados a uma velocidade de 10 megabytes por segundo e o tamanho de toda a matriz de dados é de 10 terabytes, o tempo de sincronização pode chegar a um dia (22 horas - é quanto esse volume será transferido pela rede 1 Gbps) - vale a pena reservar cerca de 800 GB . Na realidade, o número será menor, você pode dividi-lo com segurança pelo número de volumes lógicos.
Dispositivo de servidor de armazenamento de backup
A principal diferença entre um servidor para armazenamento de cópias de backup são seus discos grandes, baratos e relativamente lentos. Como os HDDs modernos já ultrapassaram a barra de 10 TB em um disco, é necessário usar sistemas de arquivos ou RAID com somas de verificação, pois durante a reconstrução do array ou a restauração do sistema de arquivos (vários dias!) o segundo disco pode falhar devido ao aumento de carga. Em discos com capacidade de até 1 TB isso não era tão sensível. Para simplificar a descrição, presumo que o espaço em disco seja dividido em duas partes de tamanho aproximadamente igual (novamente, por exemplo, usando LVM):
- volumes correspondentes aos servidores utilizados para armazenar dados dos usuários (o último backup realizado será implantado neles para verificação);
- volumes usados como repositórios BorgBackup (os dados para backups irão diretamente aqui).
O princípio de funcionamento é que para cada servidor sejam criados volumes separados para os repositórios BorgBackup, para onde irão os dados dos servidores de combate. Os repositórios operam no modo somente acréscimo, o que elimina a possibilidade de exclusão intencional de dados, e devido à desduplicação e limpeza periódica dos repositórios de backups antigos (restam cópias anuais, mensalmente para o último ano, semanalmente para o último mês, diariamente para o semana passada, possivelmente em casos especiais - por hora no último dia: total 24 + 7 + 4 + 12 + anual - aproximadamente 50 cópias para cada servidor).
Os repositórios BorgBackup não habilitam o modo somente acréscimo; em vez disso, um ForcedCommand em .ssh/authorized_keys é usado algo como isto:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......O caminho especificado contém um script wrapper sobre borg, que, além de iniciar o binário com parâmetros, inicia adicionalmente o processo de restauração da cópia de backup após a remoção dos dados. Para fazer isso, o script wrapper cria um arquivo de tag próximo ao repositório correspondente. O último backup realizado é restaurado automaticamente no volume lógico correspondente após a conclusão do processo de preenchimento de dados.
Esse design permite limpar periodicamente backups desnecessários e também evita que servidores de combate excluam qualquer coisa do servidor de armazenamento de backup.
Processo de backup
O iniciador do backup é o servidor dedicado ou o próprio VPS, pois este esquema dá mais controle sobre o processo de backup por parte deste servidor. Primeiro, é obtido um instantâneo do estado do sistema de arquivos raiz ativo, que é montado e carregado usando BorgBackup para o servidor de armazenamento de backup. Após a conclusão da captura de dados, o instantâneo é desmontado e excluído.
Se houver um banco de dados pequeno (até 1 GB para cada site), é feito um dump do banco de dados, que é salvo no volume lógico apropriado, onde estão localizados os demais dados do mesmo site, mas para que o dump seja não acessível através do servidor web. Se os bancos de dados forem grandes, você deve configurar a remoção “quente” de dados, por exemplo, usando xtrabackup para MySQL, ou trabalhar com WAL com archive_command no PostgreSQL. Neste caso, o banco de dados será restaurado separadamente dos dados do site.
Se forem usados contêineres ou máquinas virtuais, você deverá configurar qemu-guest-agent, CRIU ou outras tecnologias necessárias. Em outros casos, configurações adicionais geralmente não são necessárias - simplesmente criamos instantâneos de volumes lógicos, que são processados da mesma forma que um instantâneo do estado do sistema de arquivos raiz. Após a captura dos dados, as fotos são excluídas.
Trabalhos adicionais são realizados no servidor de armazenamento de backup:
- o último backup feito em cada repositório é verificado,
- é verificada a presença de um arquivo de marca, indicando que o processo de coleta de dados foi concluído,
- os dados são expandidos para o volume local correspondente,
- o arquivo de tag é excluído
Processo de recuperação do servidor
Se o servidor principal morrer, um servidor dedicado semelhante será iniciado, que inicializará a partir de alguma imagem padrão. Muito provavelmente o download ocorrerá pela rede, mas o técnico do data center que estiver configurando o servidor poderá copiar imediatamente essa imagem padrão para um dos discos. O download ocorre na RAM, após o qual o processo de recuperação é iniciado:
- é feita uma solicitação para anexar um dispositivo de bloco via iscsinbd ou outro protocolo semelhante a um volume lógico contendo o sistema de arquivos raiz do servidor falecido; Como o sistema de arquivos raiz deve ser pequeno, esta etapa deve ser concluída em poucos minutos. O bootloader também é restaurado;
- a estrutura dos volumes lógicos locais é recriada, os volumes lógicos são anexados do servidor de backup usando o módulo do kernel dm_clone: a recuperação dos dados começa e as alterações são gravadas imediatamente nos discos locais
- um contêiner é iniciado com todos os discos físicos disponíveis - a funcionalidade do servidor é totalmente restaurada, mas com desempenho reduzido;
- após a conclusão da sincronização de dados, os volumes lógicos do servidor de backup são desconectados, o contêiner é desligado e o servidor é reinicializado;
Após a reinicialização, o servidor terá todos os dados que estavam lá no momento da criação do backup e também incluirá todas as alterações feitas durante o processo de restauração.
Outros artigos da série
Backup Parte 7: Conclusões
Convido você a discutir a opção proposta nos comentários, obrigado pela atenção!
Fonte: habr.com