Backup Parte 7: Conclusões

Esta nota completa o ciclo de backup. Ele falará sobre a organização lógica de um servidor dedicado (ou VPS), conveniente para backup, e também oferecerá a opção de restaurar rapidamente o servidor a partir de um backup, sem tempo de inatividade em caso de acidente.

Dados de origem

Um servidor dedicado geralmente possui pelo menos dois discos rígidos usados ​​para organizar uma matriz RAID do primeiro nível (espelho). Isso é necessário para poder continuar o servidor se uma unidade falhar. Se for um servidor dedicado comum, pode haver um controlador RAID de hardware separado com tecnologia de cache ativa nos SSDs, para que, além dos discos rígidos comuns, um ou mais SSDs possam ser conectados. Às vezes, servidores dedicados são oferecidos, nos quais apenas o SATADOM está presente em discos locais (discos pequenos, estruturalmente - uma unidade flash USB conectada à porta SATA) ou até mesmo uma unidade flash USB pequena comum (8-16GB) conectada a uma porta interna especial e os dados são retirados do sistema de armazenamento conectados por meio de uma rede de armazenamento dedicada (Ethernet 10G, FC etc.) e existem servidores dedicados carregados diretamente do sistema de armazenamento. Não considerarei essas opções, pois, nesses casos, a tarefa de fazer backup do servidor passa suavemente para o especialista que está atendendo o sistema de armazenamento, geralmente existem várias tecnologias proprietárias para criar instantâneos de estado, desduplicação incorporada e outras alegrias do administrador do sistema discutidas 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 do volume de discos conectados ao servidor. No caso do VPS, os volumes são mais modestos: geralmente não mais que 100 GB (mas existem mais), e as tarifas para esse VPS podem ser facilmente mais caras que os servidores dedicados mais baratos do mesmo host. O VPS geralmente tem uma unidade, porque nela estará o armazenamento (ou algo hiperconvergente). Às vezes, o VPS possui vários discos com características diferentes, para diferentes propósitos:

• sistema pequeno - para instalar o sistema operacional;
• grande - armazenamento de dados do usuário.

Ao reinstalar o sistema usando o painel de controle, o disco com dados do usuário não é substituído, mas o sistema é completamente recarregado. Além disso, no caso do VPS, o host pode oferecer um botão que captura instantaneamente o status do VPS (ou disco); no entanto, se você instalar o sistema operacional ou esquecer de ativar o serviço desejado dentro do VPS, alguns dados ainda poderão ser perdidos. Além do botão, geralmente é oferecido um serviço de armazenamento de dados, geralmente muito limitado. Geralmente, essa é uma conta com acesso FTP ou SFTP, às vezes junto com SSH, com um shell truncado (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 Gbit / s; às vezes, pode ser cartões com velocidade de 10 Gbit / s. 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 do acesso à Internet.

Uma carga típica de um servidor ou VPS dedicado é um servidor da Web, banco de dados, servidor de aplicativos. Às vezes, vários serviços de suporte adicionais podem ser instalados, inclusive para um servidor da Web ou banco de dados: mecanismo de pesquisa, sistema de correio etc.

Um servidor especialmente preparado atua como um espaço para armazenar cópias de segurança, e será descrito em mais detalhes abaixo.

Organização do disco lógico

Se houver um controlador RAID ou um VPS com um disco e também não houver preferências particulares para o subsistema de disco (por exemplo, um disco rápido separado para o banco de dados) - todo o espaço livre é dividido da seguinte forma: uma partição é criada, um grupo de volumes LVM é criado sobre ele , cria vários volumes: 2 pequenos do mesmo tamanho que são usados ​​como sistema de arquivos raiz (eles são alterados alternadamente com atualizações para permitir reversão rápida, a ideia foi espionada na distribuição Calcular Linux), outro é para a partição swap, o restante é gratuito esse espaço é dividido em pequenos volumes usados ​​como sistema de arquivos raiz para contêineres cheios, discos para máquinas virtuais, sistemas de arquivos para contas em / home (cada conta possui seu próprio sistema de arquivos), sistemas de arquivos para contêineres de aplicativos.

Nota importante: os volumes devem ser completamente auto-suficientes, ou seja, não deve depender um do outro e do sistema de arquivos raiz. No caso de máquinas virtuais ou contêineres, esse ponto é observado automaticamente. Se forem contêineres de aplicativos ou diretórios pessoais, pense em separar os arquivos de configuração do servidor da web e outros serviços de forma a remover ao máximo as dependências dos volumes entre si. 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 da Web, os arquivos de configuração do site não são incluídos em /etc/nginx/conf.d/ .conf, mas, por exemplo, / home / /configs/nginx/*.conf

Se houver vários discos, você poderá criar um RAID de software (e configurar seu cache no SSD, se houver necessidade e oportunidade), além do qual montar o LVM de acordo com as regras sugeridas acima. Também neste caso, você pode usar o ZFS ou o BtrFS, mas vale a pena considerar algumas vezes: ambos exigem uma abordagem muito mais séria dos recursos; além disso, o ZFS não vem com o kernel do Linux.

Independentemente do esquema usado, sempre vale a pena estimar a velocidade aproximada da gravação de alterações em discos com antecedência e calcular o tamanho do espaço livre que será reservado para a criação de capturas instantâneas. Por exemplo, se nosso servidor gravar dados a uma velocidade de 10 megabytes por segundo e o tamanho de toda a matriz de dados for de 10 terabytes - o tempo de sincronização pode ser de até um dia (22 horas - esse valor será transferido pela rede de 1 gbit / s) - 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 o servidor para armazenar backups é grande, barato e discos relativamente lentos. Como os HDDs modernos já ultrapassaram a barra de 10 TB em uma unidade, é necessário usar sistemas de arquivos ou RAID com somas de verificação, porque durante a reconstrução da matriz ou a restauração do sistema de arquivos (vários dias!), O segundo disco pode falhar devido ao aumento da 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 aproximadamente do mesmo tamanho (novamente, por exemplo, usando LVM):

• volumes correspondentes aos servidores usados ​​para armazenar dados do usuário (o último backup feito para verificação será implantado neles);
• volumes usados ​​como repositórios do BorgBackup (os dados para backups chegarão diretamente aqui).

O princípio da operação é que volumes separados sejam criados para cada servidor no repositório BorgBackup, para onde os dados dos servidores de batalha irão. Os repositórios operam no modo somente de adição, o que elimina a possibilidade de exclusão intencional de dados e devido à desduplicação e limpeza periódica de repositórios de backups antigos (há cópias anuais, mensalmente no último ano, semanalmente no último mês, diariamente na última mês, diariamente na última semana, possivelmente em especial) casos - de hora em hora para o último dia: total de 24 + 7 + 4 + 12 + anual - aproximadamente 50 cópias para cada servidor).
Nos repositórios do BorgBackup, apenas o modo de adição não é ativado; em vez disso, o ForcedCommand é usado em .ssh / allowed_keys aproximadamente do seguinte plano:

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....... 

Um wrapper de script é colocado no topo do caminho especificado no topo do borg, que, além de iniciar o binário com os parâmetros, inicia adicionalmente o processo de restauração do backup após a remoção dos dados. Para fazer isso, o script do wrapper cria um arquivo de tag ao lado do repositório correspondente. O último backup feito após o processo de upload de dados é restaurado automaticamente no volume lógico correspondente.

Esse design permite limpar periodicamente backups desnecessários e também não permite que os servidores de batalha excluam nada no servidor de armazenamento de backup.

Processo de backup

O iniciador do backup é o próprio servidor dedicado ou VPS, pois esse esquema fornece mais controle sobre o processo de backup desse servidor. Primeiro, é feita uma captura instantânea do estado do sistema de arquivos raiz ativo, que é montado e carregado usando o BorgBackup no servidor de armazenamento de backup. Depois de concluir a captura de dados, a imagem é desmontada e excluída.

Se houver um banco de dados pequeno (até 1 GB para cada site), é feito um despejo de banco de dados, que é salvo no volume lógico correspondente, em que o restante dos dados do mesmo site está localizado, mas para que o despejo não seja acessível pelo servidor da web. Se os bancos de dados forem grandes, você deverá configurar uma mineração de dados "quente", por exemplo, usando xtrabackup para MySQL ou WAL com archive_command no PostgreSQL. Nesse caso, o banco de dados será restaurado separadamente desses sites.

Se contêineres ou máquinas virtuais forem usadas, 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 - basta criar instantâneos de volumes lógicos, que são processados ​​de maneira semelhante a um instantâneo do estado do sistema de arquivos raiz. Depois de tirar os dados, as fotos são excluídas.

Trabalho adicional é feito no servidor de armazenamento de backup:

• O último backup feito em cada repositório é verificado.
• verifica se há um arquivo de tags indicando que o processo de captura de dados está completo,
• os dados estão sendo expandidos para o volume local correspondente,
• arquivo de tag é excluído

Processo de recuperação do servidor

Se o servidor principal morrer, um servidor dedicado semelhante será iniciado, carregado a partir de alguma imagem padrão. Provavelmente, o download ocorrerá na rede; no entanto, o técnico do datacenter que estiver executando a configuração do 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 conectar o dispositivo de bloco via iscsi \ nbd ou outro protocolo semelhante do volume lógico que contém o sistema de arquivos raiz do servidor morto; como o sistema de arquivos raiz deve ser pequeno - essa etapa deve ser concluída em alguns minutos. Também é realizada a recuperação do carregador de inicialização;
• 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 é iniciada e as alterações são gravadas imediatamente nos discos locais
• um contêiner é iniciado com todos os discos físicos disponíveis - o servidor é totalmente restaurado, 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 é reiniciado;

Após a reinicialização, o servidor terá todos os dados que estavam no momento do backup e também incluirá todas as alterações feitas durante o processo de recuperação.

Convido você a discutir a opção proposta nos comentários, obrigado por sua atenção!