Incêndio na OVHcloud expõe o risco físico por trás da nuvem

A OVHcloud informou um incêndio em seu site de datacenters em Estrasburgo, na França. Segundo a empresa, o fogo começou em uma sala do datacenter SBG2, foi contido nas primeiras horas da manhã e não deixou feridos.¹

O impacto inicial é severo. A OVHcloud comunicou que o SBG2 foi majoritariamente destruído, enquanto parte do SBG1 sofreu danos. Os datacenters SBG3 e SBG4 não teriam sido atingidos pelo fogo, mas ficaram desligados no contexto de segurança e resposta ao incidente.²

Backup fora do site não é detalhe

O caso é um lembrete direto de que nuvem continua dependendo de prédios, energia, climatização, rede, cabos, baterias, pessoas e procedimentos físicos. Abstrações como instância, volume, bucket e serviço gerenciado escondem a complexidade, mas não eliminam risco material.

Para clientes, a pergunta imediata é onde estão os backups e se eles podem ser restaurados fora da região afetada. Backup no mesmo datacenter pode proteger contra exclusão acidental, mas não resolve perda física do local. Backup sem teste de restauração também é apenas esperança documentada.

Disaster recovery precisa ser desenhado antes do incidente. Isso inclui frequência de cópia, retenção, criptografia, isolamento contra ransomware, documentação de restauração, ordem de prioridade dos sistemas, responsáveis de plantão e metas realistas de RPO e RTO.

Zona de disponibilidade não é sinônimo de resiliência

Muitas arquiteturas usam o termo "cloud" como se ele garantisse continuidade por padrão. Na prática, resiliência depende de escolhas explícitas. Se aplicação, banco, filas, armazenamento de objetos e DNS dependem de um mesmo campus, o desenho tem ponto único de falha físico.

Alta disponibilidade local ajuda contra falha de servidor ou rack, mas incêndio, inundação, problema elétrico amplo ou interdição de prédio pedem outra estratégia. Replicação entre regiões, backups independentes e plano de failover precisam estar no escopo de sistemas críticos.

Também há diferença entre serviço gerenciado e responsabilidade de dados. O provedor opera a infraestrutura, mas o cliente precisa entender limites contratuais, opções de replicação e políticas de backup. Confiar que "a nuvem cuida disso" é uma decisão arquitetural ruim quando o dado é essencial ao negócio.

Risco físico deve entrar na governança

O incidente em Estrasburgo deve acionar revisão de inventário. Quais workloads estão na OVHcloud? Quais ficam no site afetado? Há cópias recentes? Quem tem acesso a consoles, chaves e documentação? Quais clientes finais precisam ser informados? Quais sistemas podem esperar e quais precisam voltar primeiro?

Essa priorização deve ser feita com linguagem de negócio, não só técnica. Um servidor de homologação pode ficar indisponível; uma loja online, um prontuário, um ERP ou um serviço de autenticação talvez não possam. O plano de recuperação precisa refletir essa diferença.

Para o mercado, o episódio reduz a distância entre infraestrutura tradicional e cloud. A nuvem oferece automação, elasticidade e catálogo de serviços, mas não suspende princípios básicos de continuidade. Dados precisam existir em mais de um domínio de falha, procedimentos precisam ser treinados e dependências precisam ser conhecidas.

A OVHcloud trabalha para conter e comunicar o incidente, mas cada cliente tem sua própria responsabilidade de resiliência. O fogo em um datacenter europeu mostra que arquitetura robusta começa antes do painel do provedor: começa na hipótese de que um local inteiro pode falhar.