Backup e recuperação de desastres

Quando a redundância dentro de uma região não foi suficiente

As últimas 2 lições cobriram redundância dentro de 1 única região da AWS: distribuir instâncias e bancos de dados entre zonas de disponibilidade para que a queda de 1 data center não derrube o sistema inteiro. Isso protege contra uma falha de hardware ou uma queda de energia. Não protege se um deploy ruim corrompe uma tabela do banco de dados, ou se uma região geográfica inteira sai do ar, exatamente a lacuna que a lição sobre regiões e zonas de disponibilidade, mais cedo neste curso, já tinha sinalizado. Esta lição é sobre o plano para exatamente isso: quando a falha é maior do que a redundância no nível de AZ jamais foi construída para absorver.

2 perguntas antes de qualquer plano de recuperação: quantos dados, quanto tempo fora do ar

Todo plano de recuperação de desastres começa respondendo 2 perguntas separadas, e confundir as 2 é o erro mais comum que times cometem.

Recovery Point Objective (RPO) limita a perda de dados aceitável. Responde "quantos dados podemos perder", medido como o tempo máximo aceitável entre agora e o último ponto a partir do qual você conseguiria recuperar. Um RPO de 15 minutos significa que seus backups ou sua replicação precisam rodar pelo menos com essa frequência, ou você arrisca perder mais do que o negócio tolera.

Recovery Time Objective (RTO) limita o downtime aceitável. Responde "quanto tempo podemos ficar fora do ar", medido como o atraso máximo aceitável entre o início de uma queda e o serviço voltar a funcionar. Um RTO de 1 hora significa que todo o processo de recuperação, detectar a falha, subir a infraestrutura, restaurar os dados, precisa terminar dentro dessa hora.

Um banco de dados de pedidos de e-commerce com um RPO de 15 minutos e um RTO de 1 hora está prometendo 2 coisas bem diferentes: no máximo 15 minutos de pedidos perdidos, e no máximo 1 hora até a loja voltar a receber pedidos. Cumprir os 2 exige engenharia deliberada, e cumprir com mais rigor sempre custa mais.

Backups: a base sob toda estratégia

Nenhuma estratégia de recuperação de desastres funciona sem backups confiáveis por baixo. O AWS Backup centraliza esse trabalho entre serviços, EC2, RDS, DynamoDB, EFS e mais, por meio de planos de backup: políticas que definem agendamentos e retenção. Um plano típico combina uma regra diária, fazendo backup toda noite e guardando cada backup por 1 mês, com uma regra mensal, fazendo backup 1 vez por mês e guardando essa cópia por 1 ano inteiro. Recursos são atribuídos a um plano simplesmente com tags, e os backups podem copiar automaticamente para uma região diferente da AWS no mesmo agendamento, o que transforma um backup de rotina na matéria-prima que uma estratégia de recuperação de desastres consegue realmente usar.

As 4 estratégias de recuperação de desastres, da mais barata à mais cara

Com os backups como base, a questão vira quanta infraestrutura você mantém rodando em um local secundário, e estar pronto custa dinheiro, o desastre acontecendo ou não.

Backup e restauração reconstrói tudo, dados e infraestrutura, do zero depois que um desastre é declarado, geralmente por meio de Infrastructure as Code, o que explica por que demora mais, mas custa menos no dia a dia. Pilot light mantém a camada de dados replicando continuamente, mas deixa o resto da stack apagado, precisando ser ligado e escalado antes de atender tráfego. Warm standby vai além, mantendo uma versão menor de toda a aplicação já rodando, então a recuperação significa escalar um deployment existente em vez de implantar um pela primeira vez. Multi-site active/active elimina a etapa de ligar tudo: mais de 1 região já está atendendo tráfego de produção, então uma falha no nível de região só significa redirecionar requisições para longe da região que não consegue atendê-las.

Exemplo prático: encaixando a estratégia no requisito

Um painel interno de relatórios consegue tolerar várias horas de downtime e perder até 1 dia de dados sem prejudicar o negócio de forma mensurável; backup e restauração não é só aceitável aqui, é a escolha de engenharia correta, já que pagar por uma estratégia mais quente seria gastar dinheiro que o requisito nunca pediu. Um serviço de autorização de pagamentos é o caso oposto: 1 minuto de downtime ou qualquer transação perdida é inaceitável, o que justifica o custo e a complexidade de multi-site active/active. Nenhum dos 2 times está errado. Cada um encaixou a estratégia no RTO e no RPO que o negócio realmente precisa, que é todo o sentido de existirem 4 estratégias em vez de partir direto para a mais cara por padrão.

Fronteira: backup e restauração versus pilot light

Essas 2 são o par mais confundido, porque as 2 mantêm seus dados seguros em uma segunda região e as 2 parecem, de fora, "temos backups em outro lugar". A diferença está no que acontece com a computação. Backup e restauração não tem nenhuma infraestrutura de prontidão; tudo é provisionado a partir de Infrastructure as Code só depois que um desastre é declarado. Pilot light mantém um núcleo mínimo, geralmente só a camada de dados, ativo e replicando continuamente, enquanto o resto da stack, os servidores de aplicação, por exemplo, fica completamente apagado até o failover ligá-lo. Essa única diferença, se existe algo além dos dados já esperando, é o que separa a estratégia mais barata da próxima.

Ativo-ativo reaparece, em um raio maior

Multi-site active/active não é uma ideia nova criada só para recuperação de desastres. É o padrão de redundância ativo-ativo da lição anterior, em que toda réplica atende tráfego ao mesmo tempo, esticado da escala de zonas de disponibilidade dentro de 1 região para a escala de regiões inteiras. O mecanismo é o mesmo; só a geografia e o risco são maiores.

Equívoco: backups sozinhos não são um plano de recuperação de desastres

É tentador tratar "temos backups automatizados todas as noites em uma segunda região" como o mesmo que "temos um plano de recuperação de desastres". Não é. Um backup que nunca foi restaurado é uma hipótese sobre como a recuperação vai acontecer, não uma prova de que vai dar certo. Um plano de verdade tem um procedimento de restauração documentado e ensaiado, e um RTO conhecido que a liderança realmente aprovou como aceitável. Backups são necessários para cada uma das 4 estratégias acima; não são suficientes sozinhos para nenhuma delas.

Dicas para a prova: encaixando um cenário em uma estratégia

Onde isso deixa você

Escolher uma estratégia de recuperação de desastres é escolher um ponto em uma régua entre custo em regime permanente e velocidade de recuperação, não procurar uma única resposta certa; o ponto certo é onde o RTO e o RPO reais do negócio caem, nem mais caro que isso. Backups tornam toda estratégia possível, mas só um procedimento de restauração testado as transforma em um plano de verdade. A próxima lição fecha este tópico com uma pergunta diferente: como você realmente descobre que uma falha aconteceu, e o que o SLA de um provedor de nuvem promete de verdade quando ela acontece.