Backup, restauração e recuperação de desastres
Tolerância a falhas Multi-AZ, AWS Backup e snapshots, restauração point-in-time, versionamento de armazenamento e as quatro estratégias de DR.
Os três tópicos anteriores mantêm uma carga em pé enquanto as peças continuam funcionando. Este começa onde isso já não basta: uma Availability Zone inteira que apaga, um DELETE sem WHERE, uma Região que para de responder. São 5 lições que percorrem a skill 2.2 do SOA-C03, da menor falha com nome próprio até a decisão de quanto vale gastar para sobreviver à maior.
Elas começam pelo que o Multi-AZ realmente protege e pelo que ele deixa passar, seguem para o mecanismo por baixo de todo backup na AWS, depois para as restaurações específicas de bancos de dados e de armazenamento de objetos, e fecham com as quatro estratégias de recuperação de desastres e os dois números que escolhem entre elas.
O que este tópico cobre
- O que é fisicamente uma Availability Zone, e a classificação zonal, regional e global que decide o que some junto com ela
- A aritmética AZ+1, a estabilidade estática e as dependências de zona única que ficam escondidas em arquiteturas multi-AZ
- Multi-AZ DB instance contra Multi-AZ DB cluster contra Aurora, por replicação, leitura e tempo de failover
- Como snapshots do EBS guardam blocos de forma incremental e o que apagar um deles realmente libera
- Amazon Data Lifecycle Manager contra AWS Backup, com backup plans, vaults e cópias entre Regiões e entre contas
- Vault Lock em modo governance e compliance, e o restore testing que transforma um RTO declarado em um RTO medido
- Point-in-time recovery no RDS, automated backups contra snapshots manuais, e a virada de endpoint que toda restauração exige
- Cloning e Backtrack do Aurora, PITR do DynamoDB e a lista de configuração que uma restauração não leva junto
- Versionamento do S3, delete markers, Object Lock e o que a S3 Replication recusa copiar sem avisar
- RTO e RPO, as quatro estratégias de DR, a regra do data plane e os padrões de escrita global, local e particionada
Por que isso importa
As questões deste tópico quase sempre te dão uma restrição e pedem o mecanismo: um RPO de 5 minutos, uma norma que exige backups impossíveis de apagar por 7 anos, um incidente em que o dado corrompido já chegou às duas Regiões. Responder bem depende de sustentar uma separação fácil de borrar: disponibilidade protege contra coisas quebrando, backups protegem contra coisas estarem erradas, e confundir as duas leva a escolher a resposta que soa protetora em vez da que resolve.
Num plantão real essa mesma distinção decide os primeiros minutos. Diante de dados que sumiram, alguém vai propor um failover; saber por que isso não ajuda, e qual é o ponto exato para onde dá para voltar, é a diferença entre recuperar e replicar o problema.