Hoje, tenho o prazer de apresentar dicas úteis do meu colega Evgeny Ivanov, líder da equipe de suporte técnico da Veeam. Desta vez, Zhenya compartilhou recomendações para trabalhar com backups e réplicas. Espero que isso ajude você a evitar erros comuns e que suas réplicas e backups nunca sejam o "elo fraco" no processo de recuperação, caso seja necessário.

Então, seja bem-vindo ao conteúdo.

No meu artigo anterior, artigo analisamos como otimizar a carga nos componentes da infraestrutura de backup e discutimos erros típicos de configuração. Agora, vamos para outro assunto importante – a preparação e execução corretas da recuperação. Também o vamos abordar com exemplos reais com os quais a equipe de suporte técnico lidou.

Backup sem teste é dinheiro jogado fora

Recebemos regularmente usuários que se encontram em situações semelhantes: precisam realizar uma recuperação de um backup, mas, ao tentar fazê-lo, se deparam com um problema insolúvel. E esse problema não é a ausência de um backup, atividade do CryptoLocker ou qualquer coisa semelhante. É "apenas" a falta de atenção à verificação dos backups e réplicas em relação à possibilidade de recuperação. Muitos costumam se concentrar apenas no processo de criação do backup, esquecendo que a mera existência de um backup não é uma panaceia contra possíveis problemas. É importante entender que a recuperação é um processo completamente diferente, com suas particularidades, e que deve ser monitorado e testado antes de ser acionado em produção. Aqui estão alguns exemplos ilustrativos:

Um usuário enfrentou uma falha em uma máquina virtual crítica de 20 TB. Paralisações, por óbvio, são inaceitáveis, e o administrador inicia o processo de recuperação instantânea de VM – em 5 minutos a máquina está funcionando. Mas lembramos que esse estado da máquina pode ser utilizado apenas temporariamente – é necessário migrá-la para o datastore de produção. E, neste exemplo, como se descobriu, as capacidades da infraestrutura não permitiam copiar 20 TB de dados em um tempo razoável. Nas configurações do processo de recuperação instantânea, foi escolhida a opção de manter as alterações no disco. De: Os servidores Veeam Backup & Replication (diferente do snapshot do vSphere) resultaram, claro, em um rápido preenchimento do espaço livre no disco. No momento em que o usuário entrou em contato com o suporte, a VM já havia sofrido alterações que não podiam ser ignoradas. Ou seja, temos uma situação em que não é possível finalizar rapidamente o processo de recuperação instantânea da máquina crítica – como salvar os dados?
Confesso que, com o passar dos anos, já não me lembro de todos os detalhes do final, mas lembro que, no final das contas, não conseguimos pensar em nada genial. Os clientes, de sua parte, conseguiram resolver esse problema, ampliando o disco C: a partir de reservas, copiando os arquivos mais importantes e, só depois, desligaram a VM e migraram. Enfim, não houve milagre.
Na infraestrutura do usuário, havia um controlador de domínio em operação, e todos os componentes do Veeam Backup & Replication estavam configurados usando DNS. Sim, você não leu errado. Havia pelo menos uma centena de possíveis desdobramentos, mas a realidade se desenrolou assim: as pessoas agendaram a manutenção e decidiram mudar para a réplica de seu controlador de domínio. Eles utilizaram a mudança programada, o que, de fato, é recomendado fazer em situações semelhantes. No primeiro estágio, tudo correu bem, mas no segundo, a VM original foi desligada por um curto período para transferir os dados restantes. Como era de se esperar, a tarefa de comutação falhou imediatamente, pois o DNS parou de funcionar.
Felizmente, conseguimos lidar com a situação ativando a réplica manualmente a partir do vSphere (na verdade, essa operação não deve ser executada manualmente, como você verá no próximo exemplo). Mas, como você deve entender, o processo de manutenção foi interrompido e adiado. Além disso, tivemos que adicionar manualmente os nomes dos hosts no arquivo C:WindowsSystem32driversetc\hosts no servidor Veeam Backup & Replication, para garantir a precisão durante a reversão.
Outro cliente tinha toda a sua infraestrutura de backup baseada em dispositivos de fita magnética, com arquivos curtos armazenados apenas em disco. Quando precisaram restaurar vários arquivos de um grande servidor de arquivos, descobriram que nenhuma máquina poderia ser usada como repositório auxiliar para a restauração a partir da fita, pois em nenhuma havia espaço livre suficiente. (Sobre a restauração a partir de fita magnética diretamente e utilizando um repositório auxiliar, você pode ler aqui (por enquanto em inglês)).

Acredito que, em todos os três exemplos, os usuários estavam, por assim dizer, aprisionados em ilusões – presumiram que, se o backup foi bem-sucedido, não haveria problemas na restauração. Mas isso, como você deve entender, nem sempre é verdade, e por isso a recuperação deve ser preparada com igual cuidado ao backup. Primeiro, é aconselhável estudar manual do usuário, onde há informações bastante detalhadas sobre diferentes tipos de restauração. No início de cada parágrafo, são listados os requisitos, as ações preparatórias e as possíveis limitações. A descrição da restauração a partir de fitas magnéticas ou de snapshots de hardware de storage pode ser encontrada nas seções da documentação e em nossos artigos no Habr. Além disso, as ações para preparar a restauração de objetos de aplicações usando as ferramentas Veeam Explorers estão descritas na seção 'Planning and preparation' (planejamento e preparação) guias para cada uma das ferramentas. Recomendo que você as examine com atenção — isso ajudará você a preparar corretamente o sistema para restauração, se necessário. Em russo, as instruções para a restauração do banco de dados SQL Server estão disponíveis aqui.

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

De fato, as réplicas do Veeam são máquinas virtuais comuns, com as quais, à primeira vista, seria lógico trabalhar usando as ferramentas do vSphere, em particular, o cliente vSphere. No entanto, não recomendamos isso, e aqui está o porquê: a mudança para a réplica no Veeam Backup & Replication é um processo bastante complexo, exigindo a execução rigorosamente sequencial de etapas (para que, se necessário, você possa voltar a uma etapa anterior) e ações corretas de finalização – basta olhar para a imagem que ilustra o processo:

Se você decidir habilitar a réplica a partir do vSphere client, é muito provável que você enfrente uma série de problemas posteriormente:

O mecanismo de alternância para a réplica do Veeam Backup & replication (mostrado no diagrama) não funcionará mais para esta máquina.
Os dados no banco de dados do Veeam Backup não corresponderão ao estado real da VM. No pior cenário, será necessário editar o banco de dados para corrigir a situação.
É até possível perder dados, como neste exemplo: o usuário habilitou manualmente a réplica no vSphere client e resolveu continuar trabalhando com ela. Depois de algum tempo, percebeu que a réplica ainda estava visível na console do Veeam Backup & Replication, e decidiu removê-la por não ser mais necessária. Clicou com o botão direito e deu o comando «Delete from disk». O Veeam Backup & Replication imediatamente removeu a réplica do disco, que, se me lembro bem, já estava sendo utilizada como uma VM comum e continha dados necessários e úteis.

Certamente, há situações em que é necessário habilitar a réplica a partir do vSphere client – geralmente, quando o servidor Veeam está desligado, e a réplica precisa ser ativada com um atraso. Mas se o servidor Veeam está funcionando corretamente, o trabalho com as réplicas deve ser feito diretamente da sua console.

Além disso, você não deve excluir réplicas utilizando o vSphere client. O Veeam Backup & Replication ficará ignorante sobre tal alteração, o que pode ocasionar erros e dados desatualizados. Se a réplica não for mais necessária, exclua-a por meio da console do Veeam, e não como uma VM do vSphere client. Assim, você sempre terá uma lista atualizada de réplicas.

«Cuidado» — atualizações!

Aqui, estamos nos referindo, é claro, às atualizações para hipervisores e aplicativos diversos que são copiados utilizando o Veeam. Se olharmos para elas do ponto de vista de operação com o Veeam Backup & Replication, as atualizações podem ser grosso modo divididas em 2 categorias: grandes, significativas, que trazem muitas mudanças – e pequenas.

Vamos primeiro considerar a primeira categoria.

As atualizações mais importantes são aquelas destinadas ao hipervisor. Antes de instalar uma atualização desse tipo, é essencial garantir que ela é suportada pelo Veeam Backup & Replication. Essas atualizações trazem muitas mudanças nas bibliotecas e nas interfaces de APIs usadas pelo Veeam Backup & Replication, por isso, para declarar oficialmente o suporte a elas, é necessário atualizar o código do Veeam Backup & Replication e realizar testes rigorosos.

É importante notar que, por exemplo, a VMware não oferece acesso antecipado às versões mais recentes do vSphere para os fabricantes de software, de modo que os desenvolvedores e testadores da Veeam recebem a nova versão ao mesmo tempo que o restante da comunidade tecnológica – assim, geralmente passa um tempo significativo entre o lançamento da VMware e o suporte oficialmente anunciado. O volume e a diversidade das modificações necessárias são tais que é improvável que uma simples correção (hotfix) consiga acomodá-las – e o suporte oficial normalmente é declarado juntamente com o lançamento da versão do Veeam Backup & Replication.

Assim, ocorre aquele momento desconfortável em que, após o lançamento de uma nova versão do vSphere, o número de solicitações ao suporte técnico aumenta drasticamente, pois os usuários correm para instalar a nova versão, e seus backups, claro, deixam de funcionar imediatamente. Nós, do suporte técnico da Veeam, precisamos explicar aos usuários o que exatamente eles fizeram de errado, pedir que revertam (se possível) ou encontrar caminhos complicados para resolver o impasse. Portanto, antes de instalar uma atualização significativa, verifique sempre a compatibilidade com o software que você está usando, por favor!

Tudo o que foi dito se aplica também aos aplicativos que você faz backup e pretende restaurar com o Veeam. A linha de ferramentas Veeam Explorers também possui uma lista de versões de aplicativos suportados, que é atualizada a cada lançamento do Veeam Backup & Replication. Então, antes de instalar uma nova versão do seu aplicativo – seja Exchange, Oracle ou SharePoint — certifique-se de ler a seção correspondente. da documentação do Veeam Explorers.

Na segunda categoria, ou seja, em pequenas atualizações, coloco, por exemplo, novas versões do VMware Tools, atualizações cumulativas do Exchange, atualizações de segurança do vSphere, etc. Em geral, elas não trazem alterações significativas e, na maioria dos casos, o Veeam Backup & Replication não enfrenta problemas com elas. (Por isso, não há anúncios públicos sobre o suporte oficial a essas atualizações no produto.) No entanto, em nossa prática, encontramos casos em que até mesmo essas atualizações mudaram tanto o funcionamento habitual que resultaram em erros no Veeam Backup & Replication. Nesses casos, após a confirmação do problema, os engenheiros da Veeam se esforçam para lançar rapidamente um hotfix.

Para aqueles que dominam o inglês técnicoSe você deseja se manter informado sobre o que os engenheiros estão trabalhando e os desafios que enfrentam os arquitetos de sistemas e os especialistas de suporte, recomendo se inscrever em nossos fóruns. Toda semana, para seus assinantes, é enviada a newsletter "Word from Gostev" de autoria de TheRealGostev. Nela, Anton Gostev, chefe do departamento de gerenciamento de produtos, fala sobre problemas recentemente encontrados (e não apenas do lado da Veeam), planos para novas versões e notícias do mundo da TI. Se você precisar de mais informações, pode explorar os tópicos do fórum – se algum cliente descobrir um problema com o funcionamento do produto após uma atualização, ele provavelmente já escreveu sobre isso no fórum.

Como você deve entender, patches e atualizações podem causar problemas não apenas com backups, mas também com os aplicativos para os quais esses backups são feitos. E aqui, os laboratórios virtuais – Veeam DataLabs – vão ajudá-lo. Você provavelmente já ouviu falar da funcionalidade SureBackup, projetada para a verificação de backups. Ela se baseia exatamente na utilização do DataLabs, criando um ambiente isolado onde, entre outras coisas, é possível testar atualizações antes de instalá-las em produção. Recomendo fortemente fazer isso – você economizará muitas células nervosas. E se alguém ainda não sabe sobre o SureBackup, recomendo ler documentação.

Acho que era tudo por hoje, obrigado pela atenção!