Disaster recovery, backups, RTO/RPO, failover e, acima de tudo, a pergunta que muitas empresas só fazem depois de uma falha: realmente conseguimos restaurar o sistema e voltar ao trabalho?
Falha de servidor. Banco de dados corrompido. Erro após a implantação. Ransomware. Problemas com o provedor de infraestrutura. Exclusão acidental de dados. Falha de toda a região.
Há muitos cenários. O problema é que a maioria das empresas se prepara прежде всего para evitar que a falha aconteça.
E muito menos para a situação em que ela, de fato, acontece.
É exatamente essa a área do disaster recovery.
E aqui surge a pergunta principal: se sua aplicação parar de funcionar hoje às 14:00, quanto tempo você precisa para colocá-la de volta no ar e quantos dados você pode perder?
Se a resposta for “temos backup”, isso ainda não responde à pergunta.
Backup não é disaster recovery
Backup é uma cópia dos dados. Disaster recovery é o processo de restaurar o funcionamento do sistema.
Essa é uma distinção muito importante.
Você pode ter cópias do banco de dados feitas diariamente e, ainda assim, não saber:
-
se a última cópia está correta,
-
se ela pode ser restaurada,
-
quanto tempo a restauração levará,
-
se, após a restauração, o banco de dados funcionará com a versão atual da aplicação,
-
se você também restaurará a configuração do sistema,
-
se possui todas as chaves, certificados e segredos necessários para iniciar o ambiente,
-
se a infraestrutura necessária para executar a aplicação ainda está disponível,
-
quem deve executar as etapas individuais,
-
se todo o processo cabe no tempo aceitável para o negócio.
O NIST aponta explicitamente a necessidade de testar a restauração de cópias, e as diretrizes atuais da AWS também tratam testes periódicos de recovery como uma forma de verificar se o backup realmente permite atingir o RTO e o RPO definidos.
Por isso, o backup é um elemento da estratégia de recovery, e não seu equivalente completo.
A pergunta mais importante: o que acontecerá depois de uma falha?
Vamos imaginar uma loja virtual.
Às 10:17, o banco de dados deixa de responder.
O servidor de aplicação continua funcionando, mas os usuários não conseguem fazer login. Os pedidos não funcionam. O painel administrativo deixa de responder. O sistema de pagamentos não recebe informações corretas.
A equipe verifica a situação.
Descobre-se que o último backup do banco foi feito às 8:00.
Em teoria, os dados podem ser recuperados.
Mas então surgem outras perguntas;
- Sabe-se onde está a cópia?
- Sabe-se como restaurá-la?
- A pessoa que sabe fazer isso está disponível?
- O backup está completo?
- A configuração da aplicação corresponde à versão salva na cópia?
- Após a restauração, o banco funcionará com a aplicação atual?
- E o mais importante: quanto tempo levará para restabelecer o funcionamento da loja?
Se ninguém verificou isso antes, a resposta pode ser surpreendente.
RTO - quanto tempo de indisponibilidade podemos aceitar?
RTO, ou Recovery Time Objective, define o tempo máximo aceitável para recuperar o sistema após uma falha.
Por exemplo: RTO = 4 horas significa que a organização considera possível restaurar o funcionamento do sistema em no máximo quatro horas.
Isso, porém, não significa que toda aplicação deva ter RTO de quatro horas.
Para um sistema interno usado algumas vezes por dia, esse tempo pode ser aceitável. Para uma plataforma de vendas que opera 24/7, isso pode significar perdas muito sérias.
Portanto, o RTO deve derivar do negócio, e não do que a infraestrutura oferece no momento.
O NIST define RTO como o tempo durante o qual o sistema pode permanecer na fase de recuperação antes de impactar negativamente as atividades da organização.
RPO - quantos dados podemos perder?
O segundo parâmetro fundamental é o RPO, ou Recovery Point Objective.
O RPO responde à pergunta: até que ponto no tempo podemos voltar com os dados após uma falha?
Exemplo: RPO = 1 hora significa que a organização aceita a possível perda de, no máximo, cerca de uma hora de dados.
Se o sistema falhar às 15:00 e a última cópia utilizável for das 14:00, esse é exatamente o cenário que se encaixa no RPO assumido. Mas se o backup é feito uma vez por dia, é difícil esperar um RPO de uma hora.
O RPO influencia diretamente a forma de fazer backups, replicação de dados e o desenho da infraestrutura.
O RTO nos diz, прежде всего, por quanto tempo podemos ficar indisponíveis.
O RPO diz quais dados podemos perder.
Esses dois parâmetros devem ser definidos junto com o negócio, porque alcançá-los envolve custos e soluções técnicas. A Microsoft também ressalta que RTO e RPO devem derivar de requisitos reais de negócio, e não da suposição abstrata de “zero downtime e zero perda de dados”.
O backup pode existir e, ainda assim, ser inútil
Esse é um dos mitos mais perigosos em TI.
“O backup é executado corretamente” não significa automaticamente: “o sistema pode ser restaurado a partir dele”.
A cópia pode estar incompleta. Pode estar corrompida. Pode conter dados que não podem ser usados corretamente. Pode ter sido feita de um modo que não permite restaurar todo o ambiente.
Por isso, o backup precisa ser testado por meio de restauração real.
Não basta verificar se o arquivo existe.
É preciso restaurá-lo.
Iniciar o sistema.
Verificar os dados.
Validar as dependências.
Checar a configuração.
Medir o tempo.
E responder à pergunta se o resultado corresponde às premissas de RTO e RPO.
A AWS aponta como erro típico justamente restaurar um backup sem verificar se o recurso restaurado realmente funciona e se os dados recuperados podem ser usados.
Failover - quando não queremos esperar pela restauração
Nem toda aplicação pode se dar ao luxo de esperar várias horas pela recuperação. Nesses casos, usam-se, entre outros, mecanismos de failover.
Failover significa mudar a operação do ambiente principal para um ambiente de backup preparado.
Pode ser:
-
servidor reserva,
-
segunda zona de disponibilidade,
-
segunda região,
-
réplica do banco de dados,
-
ambiente standby,
-
infraestrutura alternativa pronta para ser ativada.
No modelo mais simples, a aplicação funciona em um único local e, em caso de falha, colocamos em funcionamento um ambiente de backup. Em soluções mais avançadas, parte da infraestrutura funciona em paralelo e está preparada para assumir o tráfego.
No entanto, não existe uma única estratégia adequada para todos.
Backup e restore costumam ser mais baratos, mas podem significar um tempo de recuperação mais longo. Soluções do tipo warm standby ou redundância ativa podem reduzir significativamente o recovery, mas exigem maiores investimentos e uma infraestrutura mais complexa.
Failover também precisa ser testado
Aqui surge outro problema.
A empresa pode ter um ambiente de backup, mas não o utiliza há dois anos;
- Ele ainda funciona?
- A configuração corresponde à produção?
- Tem desempenho suficiente?
- Todos os serviços estão disponíveis?
- Os certificados estão atualizados?
- O DNS fará a mudança corretamente?
- A aplicação se conectará ao banco de dados?
- O mecanismo de autorização funcionará?
- A equipe sabe exatamente o que deve fazer?
Só o teste responde a essas perguntas.
A AWS recomenda testar o failover regularmente justamente para verificar o funcionamento do caminho de recuperação e checar se o RTO e o RPO reais correspondem às suposições.
Um ambiente de disaster recovery que nunca foi testado é apenas parcialmente uma suposição.
Disaster recovery não é apenas infraestrutura
É fácil olhar para DR apenas pela perspectiva de servidores.
Isso é um erro.
A recovery também inclui:
- Dados
Todos os dados importantes estão protegidos? - Aplicativo
Temos a versão correta do código e a possibilidade de implantá-la? - Configuração
Sabemos quais configurações são necessárias para iniciar o sistema? - Segredos e certificados
Temos acesso seguro às chaves, tokens e certificados? - Dependências externas
O que acontecerá se o sistema de pagamento externo, a API, o provedor de identidade ou um serviço SaaS ficar indisponível? - Infraestrutura
Temos um lugar onde a aplicação pode ser executada? - Pessoas
Sabemos quem toma a decisão de acionar o procedimento? - Procedimentos
Existe um runbook específico ou a recovery depende do conhecimento de uma única pessoa?
Este último ponto é especialmente importante.
Se apenas um administrador sabe como restaurar o sistema, ainda não temos um procedimento resiliente. Temos dependência de uma pessoa específica.
O pior momento para escrever um procedimento de recovery
É o momento em que o sistema já não funciona.
É тогда que surgem a pressão de tempo, o estresse, as ligações dos clientes e as perguntas da diretoria.
Por isso, o procedimento deve ser preparado com antecedência.
Ele deve definir, entre outras coisas:
-
quando acionamos o disaster recovery,
-
quem toma a decisão,
-
quais sistemas têm a maior prioridade,
-
onde estão os backups,
-
como restaurá-los,
-
quais dependências precisam ser iniciadas,
-
como funciona o failover,
-
como verificar se tudo está funcionando corretamente,
-
como comunicar a falha,
-
quando é possível iniciar o failback,
-
quem aprova o retorno ao ambiente principal.
Em caso de falha grave, não deve haver espaço para a pergunta: “O que fazemos agora?”
O procedimento deve responder isso com antecedência.
DR deve ser testado como uma função da aplicação
Uma boa abordagem é tratar a recovery de forma semelhante aos testes de software. Não basta preparar o procedimento uma vez.
O sistema muda.
O banco de dados cresce.
As dependências mudam.
Surge nova infraestrutura.
As versões da aplicação mudam.
Novas integrações aparecem.
As permissões mudam.
Por isso, a estratégia de recovery também exige verificação contínua.
O teste pode começar com um cenário simples: “O banco de dados foi perdido. Vamos restaurá-lo a partir da última cópia.”
Depois é possível passar para cenários mais complexos:
- “O servidor de aplicação não está funcionando.”
- “Todo o ambiente de produção está indisponível.”
- “Os dados foram criptografados.”
- “A região principal da infraestrutura não está funcionando.”
- “Não temos acesso ao administrador principal.”
Cada teste desse tipo pode revelar problemas que não aparecem durante a operação normal do sistema.
Toda aplicação precisa de um disaster recovery avançado?
Não.
E isso também é importante.
Projetar uma infraestrutura resistente a todos os cenários possíveis pode ser desproporcionalmente caro.
Se a falha de uma aplicação interna pode significar uma hora de inconveniência, não precisamos necessariamente de uma infraestrutura active-active em várias regiões. Se, porém, a falha de um sistema significar a paralisação de vendas, produção, atendimento ao cliente ou de um processo de negócio crítico, a situação é completamente diferente.
Primeiro é preciso determinar o impacto da falha no negócio.
Só depois escolher a tecnologia.
Isso pode levar a diferentes soluções:
Backup + restore
Solução mais simples e mais barata para sistemas de menor criticidade.
Warm standby
O ambiente de backup está parcialmente preparado e pode ser iniciado rapidamente.
Hot standby
O ambiente de backup funciona de forma mais paralela e está pronto para assumir a carga.
Active-active
Dois ambientes podem atender o tráfego simultaneamente, reduzindo a dependência de um único ponto de falha.
A escolha da solução deve resultar do RTO, do RPO, da criticidade do sistema, do custo da indisponibilidade e das possibilidades técnicas.
Checklist: sua aplicação está pronta para uma falha?
Vale a pena responder a algumas perguntas simples.
1. Temos backup?
Isso é apenas o começo.
2. O backup é armazenado de forma que também o proteja contra falhas do ambiente de produção?
3. Já fizemos alguma restauração completa?
4. Quanto tempo realmente leva o restore?
5. Conhecemos o RTO?
6. Conhecemos o RPO?
7. Conseguimos restaurar não apenas os dados, mas também a aplicação e sua configuração?
8. Temos um procedimento de recovery?
9. Mais de uma pessoa sabe executá-lo?
10. Testamos o failover?
11. O ambiente de backup está atualizado?
12. Depois das últimas mudanças no sistema, testamos novamente a recovery?
Se respondemos “não sei” a algumas perguntas, esse é um ótimo momento para analisar a estratégia de disaster recovery.
O teste mais importante é: „Mostre”
Na TI é muito fácil dizer:
- „Temos backup.”
- „Temos um servidor de reserva.”
- „Temos um procedimento.”
- „Temos disaster recovery.”
- Mas a segurança do sistema não deve basear-se exclusivamente em declarações.
A pergunta mais importante é: Mostre que consegue restaurá-lo.
- Execute o restore.
- Meça o tempo.
- Verifique os dados.
- Teste a aplicação.
- Realize o failover.
- Verifique o procedimento.
- Repita o teste após alterações significativas.
Só então se pode dizer que a estratégia de recovery foi testada na prática.
Backup protege os dados. Recovery restaura o negócio
Essa é provavelmente a diferença mais importante.
Backup responde à pergunta: „Temos uma cópia?”
Disaster recovery responde a uma pergunta muito mais difícil: „Após uma falha, conseguimos voltar a operar?”
E entre um e outro encontra-se toda a arquitetura de recuperação: RPO, RTO, replicação, backups, restore, failover, configuração, procedimentos, responsabilidade e testes regulares.
Um sistema bem projetado não pressupõe que a falha nunca acontecerá. Pressupõe que a falha acontecerá um dia e será preciso saber o que fazer.
Porque a verdadeira resiliência da aplicação não consiste no facto de nunca falhar. Consiste no facto de que, quando algo corre mal, a organização consegue voltar a operar de forma previsível, controlada e alinhada com as exigências do negócio.
Glossário
Disaster Recovery (DR) - estratégia e procedimentos que permitem recuperar o funcionamento dos sistemas após uma falha grave.
Backup - cópia de dados destinada a ser restaurada posteriormente.
Restore - processo de restauração de dados ou do sistema a partir de uma cópia.
RTO (Recovery Time Objective) - tempo máximo aceitável para recuperar o sistema.
RPO (Recovery Point Objective) - perda máxima aceitável de dados expressa em tempo.
Failover - transferência da operação do sistema do ambiente principal para o de reserva.
Failback - retorno da operação ao ambiente principal após a eliminação da causa da falha.
Recovery test - teste destinado a confirmar que o sistema pode realmente ser restaurado de acordo com as premissas adotadas.
Runbook - instrução detalhada de procedimento para um cenário específico de falha.
