Backup e recuperacao de desastres (DR) tratam de uma questao central: se o pior acontecer, com que rapidez podemos voltar ao normal?
Em termos cotidianos, e como fazer uma copia de documentos importantes antes de guardar os originais (backup) e ter um plano de evacuacao de incendio que detalha para onde ir e o que pegar primeiro (estrategia DR). Sem preparacao, um desastre vira caos. O mesmo vale para sistemas de TI empresariais.
RTO e RPO — As duas metricas fundamentais da recuperacao de desastres
Todo plano de recuperacao de desastres comeca com duas perguntas.
RTO (Recovery Time Objective — Objetivo de tempo de recuperacao): "Por quanto tempo nosso servico pode ficar fora do ar antes de causar danos inaceitaveis?" Se seu RTO for 4 horas, voce deve restaurar o servico em 4 horas apos uma falha. Como um restaurante: "Mesmo que haja um incendio, devemos reabrir em 4 horas."
RPO (Recovery Point Objective — Objetivo de ponto de recuperacao): "Quanto dado podemos perder?" Se seu RPO for 1 hora, voce pode tolerar a perda de ate 1 hora de dados. Isso tambem significa que voce deve fazer backup pelo menos a cada hora. Como o restaurante: "Podemos perder o ultimo registro de pedidos da ultima hora se necessario."
| Metrica | A pergunta que responde | Exemplo | |---------|------------------------|---------| | RTO | Com que rapidez devemos nos recuperar? | O servico deve ser retomado em 4 horas | | RPO | Quanta perda de dados e aceitavel? | Perder no maximo 1 hora de dados |
RTO e RPO mais curtos exigem solucoes mais caras. "Recuperar em 1 minuto sem perda de dados" requer a arquitetura Active-Active mais cara.
AWS Backup — Um lugar para gerenciar todos os seus backups
A AWS oferece dezenas de servicos: EC2, RDS, DynamoDB, EFS, S3 e mais. Se voce configurar backups separadamente para cada servico, o gerenciamento se torna complexo e propenso a erros. O AWS Backup fornece um unico servico centralizado para gerenciar backups de todos esses servicos.
Componentes principais
Um Plano de Backup e a politica que define quando os backups sao executados, por quanto tempo sao retidos e quando fazem transicao para armazenamento mais barato. Por exemplo: "Executar um backup todos os dias as 2h, mante-lo por 30 dias, depois mover para armazenamento frio apos 90 dias."
Um Vault de Backup e o container logico onde os dados de backup sao armazenados. Como um cofre em um banco.
Backup entre Regioes replica automaticamente backups para outra regiao da AWS. Se um desastre destruir a regiao principal, voce pode restaurar a partir do backup em uma regiao diferente.
Backup entre Contas compartilha backups com uma conta AWS separada. Mesmo que a conta principal seja comprometida por um hacker ou acidentalmente excluida, o backup na conta separada permanece seguro.
AWS Backup Vault Lock — Protegendo seus backups
O Vault Lock torna impossivel excluir ou modificar dados de backup por um periodo definido. Protege contra funcionarios maliciosos e ataques de ransomware que tentam destruir seus backups. Isso e chamado de protecao WORM (Write Once, Read Many — Escrever uma vez, ler muitas). Uma vez habilitado o Vault Lock, nem mesmo os administradores podem desativa-lo.
Snapshots EBS — Fotos em um ponto no tempo do seu disco
Um snapshot captura o estado exato de um volume EBS em um momento especifico. Como salvar um jogo, permite restaurar para aquele estado exato mais tarde.
Caracteristicas principais:
Snapshots incrementais: o primeiro snapshot copia o volume inteiro. Snapshots subsequentes armazenam apenas os blocos que mudaram desde o snapshot anterior. Isso economiza espaco de armazenamento e custo significativos ao longo do tempo.
Fast Snapshot Restore (FSR): normalmente ao restaurar um volume a partir de um snapshot, ele comeca lentamente e gradualmente atinge o desempenho maximo. O FSR pre-aquece o volume para que ele entregue desempenho maximo imediatamente apos a restauracao. Ha um custo adicional, mas e valioso quando voce precisa se recuperar rapidamente durante um desastre.
Data Lifecycle Manager (DLM): automatiza a criacao e exclusao de snapshots em um cronograma. Por exemplo: "Criar um snapshot toda noite a meia-noite. Excluir snapshots com mais de 7 dias."
Copia entre regioes: copie um snapshot para outra regiao para fins de DR.
Criptografia: snapshots de volumes EBS criptografados sao criptografados automaticamente.
Backups RDS — Protegendo seu banco de dados
Backups automaticos vs Snapshots manuais
| Recurso | Backups automaticos | Snapshots manuais | |---------|-------------------|-----------------| | Como sao criados | Automaticamente todos os dias durante uma janela de backup | Voce os aciona manualmente | | Retencao | 0-35 dias (padrao 7, maximo 35) | Mantidos ate voce exclui-los | | Recuperacao para um ponto no tempo | Sim, ate 5 minutos de precisao | Apenas para o momento exato do snapshot | | Quando o BD e excluido | Excluidos automaticamente | Retidos |
Ponto critico do exame: a retencao de backup automatico do RDS e de no maximo 35 dias. Se os regulamentos exigirem manter backups por 1 ano ou 7 anos, voce deve usar snapshots manuais.
!Backups automáticos vs snapshots manuais
Recursos especiais de backup do Aurora
O Aurora faz backups continuos dos dados para o S3 em segundo plano. Isso permite a recuperacao para um ponto no tempo (PITR) com precisao de 1 segundo. O RDS padrao suporta PITR apenas com precisao de 5 minutos.
O Backtrack e um recurso exclusivo do Aurora. Em vez de restaurar para uma nova instancia de banco de dados, ele rebobina seu banco de dados atual para um ponto passado no tempo de forma in-place. Isso e extremamente rapido. Se alguem acidentalmente executar uma instrucao DELETE que apaga milhoes de linhas, voce pode retroceder 5 minutos antes de acontecer sem criar uma nova instancia.
Versionamento e replicacao do S3
O S3 tambem fornece varios recursos de protecao de dados.
Versionamento: quando habilitado, toda vez que um arquivo e modificado ou excluido, a versao anterior e preservada. Se alguem acidentalmente excluir um arquivo critico, voce pode restaurar qualquer versao anterior.
Replicacao entre Regioes (CRR): copia automaticamente objetos para um bucket em uma regiao diferente. Usado para fins de DR e para requisitos de conformidade que exigem copias de dados em multiplas localizacoes geograficas.
Replicacao na Mesma Regiao (SRR): copia objetos para outro bucket dentro da mesma regiao. Usado para distribuir dados entre ambientes de desenvolvimento, preparacao e producao.
S3 Object Lock: protege objetos usando WORM. Para um periodo de retencao configurado, o objeto nao pode ser excluido ou sobrescrito. Usado para atender a requisitos normativos e legais de retencao de dados.
Estrategias DR — Quatro formas de se recuperar de um desastre
Existem quatro estrategias DR principais, cada uma com um equilibrio diferente entre custo e velocidade de recuperacao.
Backup e Restauracao
O metodo mais barato mas mais lento. Voce salva backups periodicamente e quando o desastre acontece reconstroi o ambiente do zero usando esses backups.
Analogia: apos um incendio, voce recebe o seguro e reconstroi a loja do zero.
RTO: horas. RPO: tempo desde o ultimo backup. Custo: o mais baixo.
Pilot Light
Nomeado pela pequena chama que mantem uma calefacao a gas pronta para acender. Voce mantem apenas os sistemas mais criticos (como o banco de dados) rodando em escala minima na regiao DR o tempo todo. Todo o resto fica desligado. Quando o desastre acontece, voce rapidamente inicia o restante do ambiente em torno dos sistemas centrais ja em execucao.
Analogia: a cozinha de backup sempre tem o gas ligado e as panelas prontas. Quando o desastre acontece, voce so manda os cozinheiros.
RTO: dezenas de minutos a poucas horas. RPO: minutos. Custo: baixo.
Warm Standby
Uma versao completamente funcional mas reduzida de todo o seu ambiente roda continuamente na regiao DR. Quando o desastre acontece, voce a escala para capacidade total para lidar com todo o trafego de producao.
Analogia: voce opera uma segunda loja com 50% de capacidade o tempo todo. Se a loja principal pegar fogo, voce escala a segunda loja para 100%.
RTO: minutos. RPO: segundos a minutos. Custo: medio.
Active-Active (Multi-Site)