Yandex Cloud recuperou 97,16% dos dados após ataques a data centers, e os backups agora vêm ativados por padrão

Há coisas que todo mundo sabe e mesmo assim deixa para depois. Backups são a principal delas. A nova história da Yandex Cloud mostra bem o preço desse "depois": após os ataques aos data centers, a empresa contou quantos dados de clientes conseguiu salvar e quantos não.

O que aconteceu e quais são os números

Segundo informações publicadas com referência à Interfax, a Yandex Cloud restabeleceu o acesso a 97,16% dos dados dos clientes. Isso ocorreu com danos críticos ao equipamento, ou seja, não se trata de uma falha curta, mas de dano físico à infraestrutura.

Os 2,84% restantes não puderam ser recuperados. Foram duas causas, e elas agiram em conjunto: o hardware em que os dados estavam foi criticamente danificado, e os proprietários desses dados não tinham backups próprios na plataforma.

Se o cliente tinha o backup ativado, 100% dos dados foram preservados. Este é o número principal de toda a história. Ele mostra que a tecnologia falha para todos, e o que salva os dados são as configurações feitas antecipadamente pelo cliente.

Para contextualizar: recentemente a AWS reconheceu que, após ataques à infraestrutura no Bahrein e nos Emirados Árabes Unidos, parte dos dados e recursos nas instalações afetadas não poderá ser recuperada. Portanto, os riscos físicos para as grandes nuvens são bem reais, não são algo exótico.

O que muda no produto

A Yandex dá um passo simples e correto: ao criar novas máquinas virtuais, os backups passarão a ser ativados por padrão. Antes, era preciso ativá-los manualmente, e muitos não o faziam.

É possível desativar, e as condições do serviço não mudaram. É uma técnica clássica de design de produto: a opção segura se torna a padrão, enquanto a decisão consciente de correr risco continua com o usuário. A maioria das pessoas não altera os padrões, então a parcela de máquinas desprotegidas em novos projetos deve cair de forma notável.

Ao mesmo tempo, os engenheiros continuam distribuindo recursos computacionais por novas localidades independentes em diferentes regiões da Rússia. A publicação não traz detalhes sobre prazos ou esquema, então ainda é cedo para avaliar quanto isso mudará a tolerância a falhas.

O que fazer como desenvolvedor ou fundador

A lição é pé no chão, sem grandes conclusões.

• Verifique se os backups estão ativados. Especialmente nas máquinas virtuais criadas antes da mudança. O novo padrão não se aplica a elas, e a publicação não diz nada sobre as máquinas antigas.
• Não confunda a tolerância a falhas da nuvem com um backup. A nuvem pode prometer disponibilidade, mas a destruição física de um site mostra a diferença: sem uma cópia separada, os dados permanecem no mesmo hardware.
• Pense em onde fica a cópia. A publicação não especifica onde os backups dos clientes são armazenados, mas a lógica é simples: uma cópia ao lado do original corre o risco de ser danificada junto com ele em um acidente grave. Vale ler a documentação do provedor e descobrir se a cópia é armazenada em outra localidade.
• Teste a restauração. Um backup a partir do qual você nunca tentou subir um sistema continua sendo uma hipótese.
• Incorpore isso ao produto. Se você constrói um serviço sobre uma nuvem, o SLA e a arquitetura devem ter metas explícitas: quantos dados você está disposto a perder e com que rapidez precisa voltar.

Limitações

Todos os números vêm da própria empresa e são repassados na publicação. Não há auditoria independente, e não se sabe qual parcela de clientes e quais tipos de dados entraram nos 2,84%. Também não há detalhes sobre os ataques e a escala dos danos. Por isso, não convém concluir que um provedor é mais confiável que outro. A comparação com a AWS no post é mais emocional do que rigorosa: os incidentes são diferentes e não há dados para uma comparação direta.

Ainda assim, a principal conclusão não se enfraquece. Mesmo com danos físicos graves, 97,16% dos dados foram recuperados, e entre os que faziam backup não houve nenhuma perda. O backup custa pouco em comparação com a perda de dados, e agora nem é preciso ativá-lo manualmente ao criar novas máquinas.