Desafios na Restauração de uma Aplicação

Atualmente, realizar os testes de restauração de backup não é, ou não deveria ser, mais um desafio. Fazer testes de restore e validação de backup é um dos pilares da resiliência de dados de um negócio. Porém para conseguir garantir essa resiliência, apenas validar a restauração de uma máquina virtual não é o suficiente.

Um exemplo típico é quando a gente faz a restauração de um servidor Windows e, depois de voltar o backup, é notado que o sistema operacional está apresentando a típica tela azul. A restauração do backup foi realizada com sucesso e dentro do tempo esperado, porém o sistema operacional não subiu e por consequência a aplicação também não.

Esse tipo de problema acontece quando a gente trata o backup e os cenários de recuperação apenas no lado da infraestrutura e da TI. Proteger a VM, validar a política de retenção, acompanhar o consumo de storage e armazenamento dos backups são apenas uma metade da operação.

A outra metade é entender que uma aplicação moderna não opera sozinha. Ela é uma teia de conexões com dependências de várias outras áreas. Caso você não tenha tudo isso já mapeado, muito provavelmente você vai descobrir na marra, durante a crise, enquanto você restaura o backup.

Outro exemplo comum em ambientes corporativos é a clássica aplicação de 3 camadas. Um servidor Web fazendo o front-end (IIS, Apache, Nginx) que atende todos os usuários e depende de resolução de nomes DNS para encontrar o back-end. Um outro servidor de aplicação que executa e valida as regras de negócio, normalmente essa validação pode estar amarrada a uma conta de serviço restrita do Active Directory. Por último, um servidor de banco de dados, que também normalmente possui regras de firewall liberando o tráfego exclusivamente para o IP do middleware.

Isso tudo é o DNA da aplicação. Ter o entendimento claro de todas as interdependências é o que faz um plano de restauração ser efetivo ou não.

O problema não é subir a VM

Quando você restaura ou replica uma aplicação para outro ambiente, seja um site de DR, Azure ou qualquer outro ambiente de destino, o servidor em si geralmente sobe sem grandes dramas ou traumas. A VM está íntegra, a rede conecta, o sistema operacional inicializa. Até aqui, tudo bem.

O problema é que a aplicação, para funcionar de verdade, depende de uma série de componentes de infraestrutura. Conectividade, autenticação, inicialização automática de serviços. São uma série de itens que precisam acontecer para que a aplicação fique disponível e pronta para o usuário final trabalhar.

E é exatamente aí que a maioria dos planos de DR não funciona da maneira esperada ou até mesmo quebra. Proteger a carga de trabalho não é suficiente, é necessário entender todo o ecossistema ao redor da aplicação.

Autenticação de Domínio

Praticamente qualquer aplicação vai depender de autenticação de domínio ou Entra ID. Seja uma aplicação Web validando usuários ou o serviço da aplicação autenticando contra o próprio banco de dados exigindo autenticação integrada. Nesses cenários, se o AD não estiver disponível no ambiente, muito provavelmente a aplicação vai travar no primeiro login ou na primeira chamada de autenticação.

Resolução de nomes (DNS)

DNS é praticamente o principal serviço responsável pela disponibilidade da aplicação. A camada Web precisa resolver o nome da camada de aplicação, que por sua vez precisa resolver o nome do banco de dados, e por aí vai. Se o ambiente de recuperação não tem um servidor DNS com as zonas e os registros corretos, ou pior, se a aplicação tiver algum tipo de hardcoded onde ao invés de resolver nomes está sendo utilizado apontamento diretamente para endereços IPs, você com certeza vai ter problemas no momento da restauração.

Endereçamento IP (DHCP)

Como citei um pouco no exemplo anterior, caso a sua aplicação dependa de DHCP, ou pior, de uma reserva DHCP para sempre receber o mesmo endereço IP, isso precisa estar planejado no ambiente de restauração antes do incidente, não durante ele. É surpreendente quantas aplicações têm IP fixo amarrado em configuração, certificado, firewall rule ou string de conexão. Isso faz com que, se o ambiente de recuperação não conseguir entregar aquele mesmo endereço (ou um esquema de IP compatível), você vai estar reconfigurando aplicação em plena crise, sob pressão, com todo o risco de erro que esse tipo de operação implica.

Conectividade de rede

Por fim, depois das VMs restauradas, elas precisam efetivamente conseguir falar com os outros servidores da rede. Regras de firewall, segmentação da rede, roteamento, tudo isso precisa ser levado em conta.

O conceito do DNA da aplicação

Isso tudo nos leva a um conceito que eu acho essencial e que muitas vezes é subestimado ou até esquecido nos planos de recuperação que eu vejo. O DNA da aplicação.

O DNA da aplicação é, essencialmente, o conjunto completo de dependências que fazem aquela aplicação funcionar. Autenticação, DNS, IP, conectividade, mas também integrações com outros sistemas, certificados, service accounts, ordens de inicialização entre camadas são itens que precisam ser levados em conta para entender a funcionalidade do sistema como um todo.

Entender esse DNA é tão importante quanto proteger a máquina virtual em si. Muitas vezes é até mais importante. Proteger a VM é algo relativamente fácil. Qualquer ferramenta de backup que se preste faz isso bem. Porém, mapear o ecossistema de um sistema ou aplicação é algo que precisa ser feito com o envolvimento do time e com uma boa documentação.

Como já mencionado, mover ou restaurar apenas a VM não garante que a aplicação funcione. O servidor pode até inicializar, mas caso esse servidor não tenha todos os serviços de suporte necessários rodando ao seu redor, tem chance do restore ter sido inútil. Essa é a diferença entre uma restauração isolada, do ponto de vista de infraestrutura, e uma recuperação que coloca a aplicação no ar por completo, do ponto de vista do negócio, que é o que realmente importa.

Mapeando o Sistema

Por isso, o trabalho essencial antes de qualquer plano de teste de restore é mapear o sistema. Isso é essencial pelo menos para cada uma das aplicações críticas de uma empresa. Então isso significa que precisamos documentar, aplicação por aplicação.

Quais serviços de autenticação ela usa, de quais zonas e registros DNS ela depende, se tem IP fixo ou reserva DHCP, quais regras de conectividade de rede são necessárias entre as camadas, e quais outras aplicações ou sistemas externos ela precisa alcançar para funcionar de ponta a ponta.

Com isso é possível ter uma boa noção de como a aplicação funciona, se conecta entre si com todas as suas interdependências.

Conclusão

No final das contas, restaurar uma aplicação é sempre mais complexo do que restaurar uma VM. A tecnologia de backup e replicação evoluiu muito nos últimos anos, e hoje é relativamente trivial trazer uma carga de trabalho de volta. Porém ainda existe um gargalo que não está ligado à tecnologia: entender profundamente como suas aplicações se conectam, documentar essas dependências, e garantir que o ambiente de destino, seja ele um site de DR ou uma cloud como Azure, tenha tudo o que a aplicação precisa para não só ligar, mas efetivamente funcionar.

Proteger a VM é o ponto inicial, mas compreender o DNA da aplicação é o que garante que, quando o incidente acontecer de verdade, você vai recuperar uma área de negócio, ou o negócio inteiro, ao invés de um servidor.

Mateus Wolff

Meu nome é Mateus Wolff e trabalho com TI desde 2009. Sou arquiteto de soluções de proteção de dados e tenho algumas certificações como VMCE, VCP-DCV e ITIL.

Participo do programa de reconhecimento Veeam Vanguard e sou ex membro do grupo Veeam Legends.

Também sou líder do grupo Veeam User Group Brasil.