A AWS acabou de admitir que os dados desapareceram... #aws #database #programming

Ver no idioma original →

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: AWS just admitted the data is gone… #aws #database #programming · Canal: Better Stack · 01:31 · Assistir no YouTube

Tópicos: Dados, bancos de dados e embeddings, Infraestrutura e hardware de IA

Resumo

A AWS informou que danos em data centers no Bahrein e nos Emirados Árabes Unidos afetaram várias availability zones, e que alguns dados não podem ser restaurados. Embora as availability zones ajudem a manter serviços em funcionamento diante de falhas isoladas, elas ainda podem estar sujeitas a um mesmo evento regional. Segundo o vídeo, clientes que se recuperaram tinham backups armazenados em outra região. A principal lição é que Multi-AZ é uma estratégia de disponibilidade, não de backup.

Pontos-chave

• A AWS comunicou a alguns clientes que certos dados foram perdidos permanentemente.
• Os danos no Bahrein atingiram várias availability zones e excederam o que os serviços regionais e Multi-AZ foram projetados para suportar.
• Uma das três availability zones nos Emirados Árabes Unidos também enfrenta o mesmo problema.
• Availability zones isolam falhas comuns, como problemas em prédios, energia e rede, mas continuam dentro da mesma região.
• Serviços como S3 anunciam durabilidade, mas a transcrição ressalta que isso não elimina o risco de um evento regional extremo.
• Os clientes que se recuperaram tinham backups armazenados em outra região.
• Multi-AZ é uma estratégia de disponibilidade, não uma estratégia de backup.
• É importante verificar em que região os backups estão armazenados.

Capítulos

Início	Capítulo	Resumo
00:00	A perda de dados e os danos iniciais	O vídeo relata que a AWS informou a alguns clientes que seus dados desapareceram e descreve os ataques a data centers no Bahrein e nos Emirados Árabes Unidos.
00:30	Danos além da proteção das availability zones	A AWS afirmou que os danos no Bahrein atingiram várias availability zones e que parte dos dados não pode ser restaurada.
01:00	Backups em outra região	O vídeo explica que availability zones permanecem dentro da mesma região e destaca que clientes com backups remotos conseguiram se recuperar.

Citações

Não está fora do ar, não está atrasado: desapareceu permanentemente. — 00:00

Os danos no Bahrein abrangeram várias availability zones. — 00:30

Multi-AZ não é uma estratégia de backup; é uma estratégia de disponibilidade. — 01:00

Se a produção e os backups estão na mesma região, você não tem backups de verdade. — 01:31

Conceitos e entidades

• AWS (empresa): Provedora de serviços de nuvem que comunicou aos clientes os danos e a perda irrecuperável de alguns dados.
• availability zone (conceito): Zona composta por infraestrutura separada, como prédios, energia e rede, criada para isolar determinadas falhas dentro de uma região.
• Multi-AZ (conceito): Abordagem que distribui workloads entre várias availability zones para aumentar a disponibilidade, mas que não substitui backups em outra região.
• S3 (ferramenta): Serviço citado no vídeo como exemplo de produto que anuncia durabilidade.

Tradução completa (pt-BR)

00:00 A AWS acabou de dizer a alguns de seus clientes que os dados deles se foram. Não estão indisponíveis, nem atrasados: desapareceram permanentemente. E essas cargas de trabalho estavam distribuídas por várias zonas de disponibilidade. Deixe-me explicar. No início de março, drones iranianos atingiram data centers da AWS no Bahrein e nos Emirados Árabes Unidos. No começo, parecia apenas uma interrupção muito grave. Então, no fim de abril, a AWS disse que a restauração poderia levar meses. Mas, em 15 de setembro, seis meses depois, a linguagem mudou. A AWS disse que o

00:30 dano no Bahrein abrangeu várias zonas de disponibilidade e excedeu o que os serviços regionais e multi-AZ foram projetados para suportar. Então, basicamente, em outras palavras, qualquer coisa que existisse apenas nessa região do Bahrein não pode ser restaurada. E uma das três zonas de disponibilidade nos Emirados Árabes Unidos também enfrenta o mesmo problema. As zonas de disponibilidade deveriam isolar essas falhas. Prédios separados, energia separada, redes separadas. Assim, se uma sair do ar, seu app pode continuar funcionando em outra. E serviços como o S3 anunciam esse tipo de

01:00 durabilidade. Mas aqui está o porém. Uma zona de disponibilidade ainda é um data center na mesma região. E uma guerra não se importa muito com a aparência do seu diagrama de arquitetura. Os clientes que conseguiram se recuperar foram aqueles que armazenavam backups em uma região completamente diferente. A AWS diz que a maioria deles conseguiu reconstruir tudo em outro lugar usando esses backups remotos. Todo mundo acabou de aprender uma lição bem dura. Multi-AZ não é uma estratégia de backup; é uma estratégia de disponibilidade. E são duas coisas bem diferentes. Então, se você executa algo importante na nuvem, confira onde seus backups realmente

01:31 estão. Porque, se a produção e os backups estiverem na mesma região, você não tem backups de verdade. Tudo o que tem são cópias. Se você gosta de dicas e truques de programação como este, não deixe de se inscrever no canal Better Stack.

Transcrição original

[00:00] AWS just told some of their customers their data was gone. Not down, not delayed, permanently gone. And these workloads were running across multiple availability zones. Let me explain. Back in early March, Iranian drones hit AWS data centers in both Bahrain in the UAE. At first, it just looked like a really bad outage. Then by the end of April, AWS said restoration could take months. But on September 15th, 6 months later, the language changed. AWS said the

[00:30] damage in Bahrain spanned multiple availability zones and exceeded what its regional and multi-AZ services were designed to survive. So basically, in other words, anything that only existed in this Bahrain region, it can’t be restored. And one of three availability zones in the UAE also faces the same problem. Availability zones are supposed to isolate these failures. Separate buildings, separate power, separate networking. So if one goes down, your app can keep running in another. And services like S3 advertise this kind of

[01:00] durability. But here’s the catch. An availability zone is still a data center in the same region. And some war doesn’t really care about how your architecture diagram actually looks. The customers who recovered were the ones with backups stored in a completely different region. AWS says most of them were able to build elsewhere using those remote backups. Everyone just learned a pretty brutal lesson. Multi-AZ is not a backup strategy, it’s an uptime strategy. And those are two very different things. So if you run anything important in the cloud, check where your backups actually

[01:31] live. Because if production and your backups are in the same region, you don’t really have any backups. All you really have then is copies. If you enjoy coding tips and tricks like this, be sure to subscribe to the Better Stack channel.