Hoje, tenho o prazer de apresentar-lhe bons conselhos da minha colega Evgeny Ivanov, líder da equipe de suporte técnico da Veeam. Dessa vez, Zhenya compartilhou recomendações para trabalhar com backups e réplicas. Espero que eles o ajudem a evitar erros comuns, e suas réplicas e backups nunca serão um "elo fraco" no processo de recuperação, se necessário.

Bem-vindo ao gato.



No meu artigo anterior , descobrimos como otimizar a carga nos componentes da infraestrutura de backup e examinamos os erros de configuração típicos. Passamos a outro tópico importante - a preparação e implementação competentes de recuperação. Também iremos analisá-lo com exemplos reais com os quais a equipe de suporte técnico trabalhou.

Backup sem restaurante - dinheiro pelo ralo

Somos contatados regularmente por usuários que se encontram em situações difíceis semelhantes: é necessário executar uma recuperação do backup, mas quando tentam fazer isso, as pessoas encontram um problema insolúvel para eles. E esse problema não é a falta de um backup, a atividade do CryptoLocker ou algo assim. Isso é "apenas" uma falta de atenção na verificação de backups e réplicas para recuperação. Muitas vezes, concentram-se apenas no processo de backup, esquecendo que simplesmente ter um backup não é uma panacéia para possíveis problemas. Você precisa entender que a recuperação é um processo completamente diferente, com características próprias e que deve ser monitorado e testado antes de iniciar a produção. Aqui estão alguns exemplos ilustrativos:

1. O usuário teve uma falha na operação de uma máquina virtual crítica de tamanho 20 TB. O tempo de inatividade, é claro, é inaceitável e o administrador inicia o processo de recuperação instantânea (recuperação instantânea da VM) - após 5 minutos, a máquina está pronta. Mas lembramos que esse estado da máquina só pode ser usado temporariamente - ele deve ser migrado para o armazenamento de dados de produção. E neste exemplo, como se viu, os recursos de infraestrutura não permitiram copiar 20 TB de dados em um tempo razoável. Nas configurações do processo de recuperação instantânea, foi escolhido para salvar as alterações na unidade C: do servidor Veeam Backup & Replication (diferente do instantâneo do vSphere) - como resultado, é claro, o espaço livre no disco rapidamente ficou cheio. Quando o usuário entrou em contato com o suporte, a VM tinha alterações que não podiam ser ignoradas. Ou seja, temos uma situação em que é impossível finalizar rapidamente o processo de recuperação instantânea de uma máquina crítica - como você pode salvar dados?
   
   Devo admitir que nos últimos anos não vou mencionar todos os detalhes do final, mas lembro que, no final, nunca tivemos nada brilhante. Os clientes do lado deles, pelo menos, resolveram esse problema expandindo a unidade C: das reservas, copiaram os arquivos mais importantes, desligaram as VMs e migraram. Em geral, um milagre não aconteceu.
2. O usuário tinha um controlador de domínio na infraestrutura e todos os componentes do Veeam Backup & Replication foram configurados usando DNS. Sim, está certo, você ouviu direito. Havia centenas de opções para eventos, nada menos, mas a realidade era a seguinte: as pessoas planejavam a manutenção e decidiram mudar para uma réplica de seu controlador de domínio. Eles envolveram a troca planejada, o que, em geral, é recomendado para ser feito nessas situações. No primeiro estágio, tudo correu bem e, no segundo, a VM original foi desligada brevemente para transferir os dados restantes. Obviamente, o trabalho do comutador terminou imediatamente com erro, porque o DNS parou de funcionar.
   
   Felizmente, aqui conseguimos lidar com a situação ativando a réplica manualmente a partir do vSphere (na verdade, não é recomendável executar esta operação por conta própria, como você verá no exemplo a seguir). Mas, como você entende, o processo de manutenção foi interrompido e adiado. Além disso, tivemos que inserir manualmente os nomes de host no arquivo C: \ Windows \ System32 \ drivers \ etc \ hosts no servidor Veeam Backup & Replication para garantir a correção durante o failover.
3. Outro cliente teve toda a infraestrutura de backup construída em torno de unidades de fita e apenas pequenas cadeias de arquivos foram armazenadas no disco. Quando eles precisavam restaurar vários arquivos de um servidor de arquivos grande, descobriu-se que nenhuma máquina poderia ser usada como repositório auxiliar durante a recuperação da fita, pois não havia espaço livre suficiente em um. (Você pode ler sobre a recuperação da fita magnética diretamente e usando um repositório auxiliar aqui (até agora em inglês)).

Penso que nos três exemplos, os usuários, por assim dizer, foram cativados por ilusões - sugeriram que, se o backup for bem-sucedido, não haverá problemas com a recuperação. Mas isso, como você sabe, nem sempre é o caso e, portanto, você precisa se preparar para a recuperação com o mesmo cuidado que faz para o backup. Para começar, vale a pena estudar o manual do usuário , que contém informações bastante detalhadas sobre os diferentes tipos de recuperação. No início de cada parágrafo, são listados os requisitos, etapas preparatórias e possíveis limitações. A descrição da recuperação de fitas magnéticas ou de imagens de hardware de sistemas de armazenamento pode ser encontrada nas seções da documentação e em nossos artigos sobre Habré. Além disso, as etapas para preparar a recuperação de objetos de aplicativo usando as ferramentas do Veeam Explorers são descritas na seção "Planejamento e preparação" do manual de cada ferramenta. Eu recomendo que você os leia com atenção - isso ajudará você a preparar adequadamente o sistema para recuperação, se necessário. Em russo, instruções para restaurar o banco de dados do SQL Server são fornecidas aqui .

Por que você não precisa trabalhar com réplicas do console do vSphere?

Em teoria, as réplicas da Veeam são máquinas virtuais comuns com as quais parece lógico trabalhar usando o kit de ferramentas vSphere, em particular, o cliente vSphere. No entanto, não recomendamos fazer isso, e aqui está o porquê: alternar para uma réplica no Veeam Backup & Replication é um processo bastante complicado que requer etapas estritamente sequenciais (para que você possa reverter uma etapa, se necessário) e as etapas finais corretas - basta ver ilustração que ilustra o processo:



Se você decidir habilitar uma réplica do cliente vSphere, no futuro você provavelmente esperará vários problemas:

1. A mudança para o mecanismo de réplica do Veeam Backup e replicação (mostrado no diagrama) desta máquina não funcionará mais.
2. Os dados no banco de dados Veeam Backup não corresponderão ao estado real da VM. Na pior das hipóteses, você precisa editar o banco de dados para corrigi-lo.
3. Pode até haver perda de dados, como neste exemplo: o usuário ativou manualmente a réplica no cliente vSphere e decidiu continuar trabalhando com ela. Depois de um tempo, ele percebeu que a réplica ainda estava sendo exibida no console do Veeam Backup & Replication e decidiu removê-la como desnecessária. Cliquei com o botão direito e dei o comando "Excluir do disco" . O Veeam Backup & Replication excluiu imediatamente a réplica do disco, que, por um momento, já estava em uso total como uma VM comum e continha os dados necessários e úteis.

Obviamente, há situações em que você ainda precisa habilitar a réplica do cliente vSphere - como regra, são casos em que o servidor Veeam está desligado e a réplica precisa ser ativada com atraso. Mas se tudo estiver em ordem com o servidor Veeam, você precisará trabalhar com réplicas do console.

Além disso, não exclua réplicas usando o cliente vSphere. O Veeam Backup & Replication permanecerá inconsciente de tal alteração, e isso está repleto de erros e dados desatualizados. Se você não precisar mais da réplica, exclua-a usando o console Veeam, e não como uma VM do cliente vSphere. Portanto, você sempre terá uma lista atualizada de réplicas.

"O" - com cuidado, atualizações!

Aqui queremos dizer, é claro, atualizações para hipervisores e vários aplicativos com backup usando o Veeam. Se você olhar para eles do ponto de vista do trabalho com o Veeam Backup & Replication, as atualizações poderão ser divididas em 2 categorias: grandes, sérias, trazendo muitas alterações - e pequenas.

Considere primeiro a primeira categoria.

As atualizações mais importantes são aquelas projetadas para o hypervisor. Antes de instalar essa atualização, verifique se ela é suportada pelo Veeam Backup & Replication. Essas atualizações trazem muitas alterações às bibliotecas e APIs usadas pelo Veeam Backup & Replication. Portanto, para anunciar oficialmente seu suporte, é necessário atualizar o código do Veeam Backup & Replication e realizar testes rigorosos.

Também devemos ter em mente que, por exemplo, a VMware não fornece acesso preliminar às versões mais recentes do vSphere para fabricantes de software, para que os desenvolvedores e testadores da Veeam recebam uma nova versão ao mesmo tempo que o resto da humanidade progressiva - portanto, geralmente entre o lançamento do VMware e o suporte anunciado oficialmente um certo tempo. O número e a variedade de alterações necessárias para fazer com que um hotfix simples atenda às suas chances seja pequeno - e, como regra geral, o suporte oficial é anunciado juntamente com o lançamento da versão do Veeam Backup & Replication.

Como resultado, existe um momento estranho em que, após o lançamento da nova versão do vSphere, o número de aplicativos para suporte técnico aumenta acentuadamente, porque os usuários correm para instalar a nova versão e seus backups, é claro, param imediatamente de funcionar imediatamente. Nós, suporte técnico da Veeam, temos que explicar aos usuários exatamente o que eles fizeram de errado, pedir que eles revertam (se possível) ou pensar em maneiras complexas de quebrar o impasse. Portanto, antes de instalar uma atualização importante, verifique sua compatibilidade com o software em execução no seu computador, eu imploro!

Todas as opções acima se aplicam aos aplicativos que você faz backup e espera recuperar usando o Veeam. A linha de ferramentas Veeam Explorers também possui uma lista de versões suportadas dos respectivos aplicativos, que são atualizadas a cada versão do Veeam Backup & Replication. Portanto, antes de instalar uma nova versão do seu aplicativo - seja Exchange, Oracle ou SharePoint - leia novamente a seção correspondente da documentação do Veeam Explorers .

Para a segunda categoria, ou seja, Refiro-me a pequenas atualizações, por exemplo, novas versões do VMware Tools, atualizações cumulativas do Exchange, atualizações de segurança do vSphere, etc. Como regra, eles não carregam nenhuma modificação importante e, na maioria dos casos, o Veeam Backup & Replication não apresenta problemas com eles. (Portanto, não há anúncios públicos de suporte oficial ao produto para eles.) No entanto, em nossa prática, houve casos em que essas atualizações alteraram significativamente o curso normal das coisas que levaram a erros no Veeam Backup & Replication. Nessas situações, após confirmar o problema, os engenheiros da Veeam tentam liberar rapidamente o hotfix.


Como você entende, patches e atualizações podem causar problemas não apenas nos backups, mas também nos aplicativos para os quais esses backups são feitos. E aqui laboratórios virtuais - o Veeam DataLabs o ajudará. Você provavelmente já ouviu falar sobre a funcionalidade do SureBackup, projetada para verificar backups. Ele se baseia precisamente no uso do DataLabs, com a criação de um ambiente isolado no qual você pode, em particular, testar atualizações antes de instalá-las na produção. Aconselho vivamente que o faça - poupe muitas células nervosas. E se alguém não souber sobre o SureBackup, recomendo a leitura da documentação .

Talvez por hoje eu tenha tudo, obrigado pela atenção!

O que mais ler

Artigos sobre Habré:

• Um caso na Pixar ou mais uma vez sobre a importância de testar backups
• Recursos de armazenamento de backup de longo prazo
• Práticas recomendadas para diretivas de backup
• Recomendações para a política de backup e recuperação após o Dia do Juízo Final

Manual do usuário (em russo)