O incêndio da OVHcloud mostrou que a localização dos dados não é uma separação de desastres

Resumo

• Os alarmes de incêndio dispararam no local de Estrasburgo da OVHcloud às 0h35 do dia 10 de março de 2021. O incêndio começou nas salas de energia do térreo do SBG2, destruiu este edifício, danificou quatro das doze salas do SBG1 e forçou o corte de energia em todo o campus. SBG3 e SBG4 não foram consumidos pelo incêndio inicial, mas os serviços estavam indisponíveis devido ao isolamento elétrico, inspeção de segurança, limpeza e reinicialização progressiva. Ninguém morreu ou ficou ferido.
• A investigação de segurança industrial francesa não determinou a causa precisa das falhas elétricas quase simultâneas observadas em um no-break e suas baterias de chumbo associadas. Ela estabeleceu fatores de propagação e resposta: ausência de sistema de extinção automática nos cinco edifícios de Estrasburgo, rápida propagação da fumaça devido ao design aberto e de resfriamento do SBG2, capacidade limitada de água para incêndio e difícil desligamento elétrico em todo o site. Detecção funcional, equipe noturna, separação corta-fogo protegendo o SBG3 e a chegada de um barco-bomba franco-alemão de alta capacidade limitaram as consequências mais graves.
• A perda de disponibilidade e a perda permanente de dados foram resultados diferentes. A OVHcloud relatou que 65.000 clientes e 120.000 serviços foram afetados, enquanto a Netcraft observou que cerca de 3,6 milhões de sites em 464.000 domínios estavam offline. A OVHcloud afirmou que muitos clientes que perderam dados não haviam selecionado backup opcional. Isso não encerra a questão da responsabilidade: o documento de registro da OVHcloud indicava que os backups oferecidos podiam ser armazenados no mesmo data center ou em um diferente, e uma sentença de apelação posterior envolveu um cliente cujo backup automatizado pago foi destruído no mesmo edifício que a produção.
• O evento revelou um erro de categoria no provisionamento em nuvem. A soberania dos dados, a jurisdição legal, a latência, a disponibilidade, o backup e a recuperação de desastres estão relacionados, mas são intercambiáveis. Manter dados na França ou na União Europeia pode satisfazer uma política de localidade enquanto permite que as cópias de produção e recuperação compartilhem o mesmo risco físico. Inversamente, uma cópia geograficamente distante pode permanecer dentro do mesmo território jurídico e sob os mesmos controles europeus.
• A OVHcloud divulgou mudanças substanciais após o incêndio, incluindo extinção automática estendida, compartimentação reforçada, salas de energia separadas, cortes elétricos remotos, auditorias de site, trabalho com os bombeiros e novas opções multizona e de backup remoto. Uma conclusão responsável requer, no entanto, evidências específicas de serviço e site: cobertura completa dos controles, inspeção independente, exercícios realistas de incêndio e isolamento elétrico, locais declarados de backups, testes de restauração bem-sucedidos e prova de que a recuperação do cliente não depende da região danificada ou do mesmo plano de controle.

Um incêndio físico tornou-se um evento de responsabilidade em nuvem

A expressão “dados na nuvem” incentiva uma abstração. Ela é útil quando engenheiros desejam uma interface padrão para capacidade computacional, mas perigosa quando tomadores de decisão começam a tratar localização, energia e fogo como detalhes pertencentes a outra pessoa. Cada servidor virtual repousa em uma sala. Cada réplica de armazenamento ocupa um equipamento conectado a sistemas elétricos e de resfriamento. Cada fluxo de recuperação depende de pessoas, redes, credenciais, catálogos e um local de onde a capacidade substituta pode ser obtida.

Estrasburgo tornou essa cadeia física visível. Nas primeiras horas de 10 de março de 2021, um incêndio destruiu o SBG2, um dos edifícios do campus da OVHcloud no Porto do Reno. O SBG1 foi parcialmente destruído. Os outros dois data centers do local foram desligados, embora a primeira atualização da empresa os descrevesse como não danificados. A perda se propagou por pelo menos três mecanismos distintos: o equipamento foi fisicamente destruído; o equipamento em edifícios adjacentes foi exposto a calor, fumaça, água ou incerteza; e o equipamento saudável tornou-se indisponível quando o local teve que ser isolado eletricamente e protegido.

Esses mecanismos são importantes porque correspondem a controles diferentes. Uma supressão automática e uma compartimentação podem conter um incêndio. Zonas de energia independentes podem reduzir a área que os bombeiros precisam desconectar. Uma aplicação multissite pode continuar enquanto um site está indisponível. Um backup remoto verificado pode apoiar a reconstrução após a destruição dos dados. Uma página de status pode guiar os clientes por essas opções. Chamar tudo isso de “redundância” esconde quem controla cada camada e qual evento ela pode sobreviver.

A reconstrução pública mais autorizada é o relatório de investigação de maio de 2022 do Bureau d’enquêtes et d’analyses sur les risques industriels (BEA-RI). Seu mandato era a prevenção, não a atribuição de responsabilidade civil ou criminal. Esse limite é importante. O relatório pode estabelecer observações, causas possíveis, fatores contribuintes e recomendações de segurança. Ele não pode ser convertido em uma constatação judicial de que toda fraqueza identificada foi negligente ou que uma fraqueza causou legalmente a perda de um cliente específico.

A análise de responsabilidade faz uma pergunta relacionada, mas mais ampla: quais atores tinham autoridade sobre as condições que permitiram que um evento noturno de equipamento se tornasse uma falha de múltiplos edifícios, uma recuperação prolongada e uma perda irreversível para o cliente? A OVH controlava o design e a operação do local, os produtos oferecidos, a precisão de suas descrições e a resposta. Os clientes controlavam a classificação da carga de trabalho, a arquitetura, muitas seleções de serviços e cópias independentes. Reguladores e organismos profissionais controlavam partes da estrutura mínima.

Nenhum desses papéis anula os outros.

O que as evidências estabelecem e o que não estabelecem

O relatório do BEA-RI coloca o primeiro alarme às 0h35. Um guarda alcançou uma sala de energia do SBG2 às 0h37 e encontrou fumaça preta espessa. O edifício foi evacuado às 0h39, o serviço de incêndio e resgate do Baixo Reno foi chamado às 0h42, e as primeiras equipes chegaram às 0h59. A página pública de incidentes da OVH usava 0h47 como horário de início do incêndio. A diferença deve ser preservada em vez de forçada em um único timestamp: a investigação de segurança tinha acesso a alarmes e registros operacionais, enquanto a página da empresa fornecia um marcador de incidente público.

A energia de emergência do SBG2 foi desligada à 1h13 e a do SBG1, SBG3 e SBG4 à 1h28. Os bombeiros viram arcos elétricos e retardaram o uso de água até que o risco fosse controlado. Por volta de 1h42, o incêndio havia se espalhado para o primeiro andar. Por volta de 2h00, os bombeiros relataram envolvimento generalizado do SBG2. O barco-bomba de alta capacidade EUROPA chegou por volta de 3h00, captando água da via navegável adjacente. O incêndio foi extinto às 10h02 e a intervenção foi considerada encerrada às 18h13.

A investigação localizou a origem do incêndio em salas contendo baterias e equipamentos de energia ininterrupta. Gravações de vídeo e monitoramento mostraram uma falha elétrica quase simultânea no no-break ASI2 e suas baterias associadas, que estavam em salas separadas. Manutenção havia sido realizada no no-break naquela manhã e medições incomuns de umidade foram feitas mais tarde no dia. Os investigadores listaram várias hipóteses, incluindo umidade, mau funcionamento relacionado à manutenção ou operação fora das condições esperadas. Eles declararam explicitamente que as evidências eram insuficientes para escolher uma causa inicial precisa.

Essa contenção foi frequentemente perdida em narrativas que dizem que um sistema de resfriamento com vazamento ou um no-break recentemente mantido “causou” o incêndio. O registro oficial de acidentes ARIA francês é uma corroboração útil para o cenário da sala de máquinas e a resposta, mas não transforma um mecanismo plausível em uma causa raiz comprovada. Um relato crível diria que os primeiros eventos elétricos e a área de origem são conhecidos; a razão pela qual esses eventos ocorreram não foi resolvida no relatório publicado do BEA-RI.

A distinção não impede a análise de controles. Uma organização deve estar preparada para uma falha de equipamento sem saber qual componente falhará em seguida. A proteção contra incêndio é projetada em torno dessa incerteza. A questão de responsabilidade não é apenas se a OVH deveria ter previsto uma sequência elétrica específica. É se a detecção, o controle automático, a compartimentação, a água, o isolamento elétrico, o design do edifício e os procedimentos de emergência forneceram às pessoas e serviços adjacentes proteção independente suficiente após uma ignição.

O edifício detectou o perigo, mas não conseguiu contê-lo

O local de Estrasburgo cumpriu bem uma missão de segurança das pessoas. A detecção óptica e por aspiração de fumaça funcionou. A equipe noturna permitiu verificação rápida e chamada precoce aos bombeiros. Todos escaparam e não houve ferimentos. O relatório do BEA-RI elogia esses controles. A responsabilidade deve reter as barreiras bem-sucedidas com tanto cuidado quanto as falhas, pois o design futuro depende de saber o que realmente ganhou tempo.

A detecção não foi acompanhada de supressão automática. A investigação revelou que nenhum dos cinco edifícios do local possuía um sistema automático de proteção contra incêndio. As salas de baterias e no-breaks do SBG2 eram monitoradas, mas não havia sistema projetado para extinguir, controlar ou retardar o incêndio em seu estágio mais inicial. Tal sistema poderia ter agido antes do desligamento elétrico completo e sem expor os bombeiros a equipamentos energizados. Não teria garantido a extinção, especialmente em uma sala elétrica, mas poderia ter alterado a curva de crescimento do incêndio.

O edifício então facilitou o movimento de fumaça e calor. O SBG2 usava um design aberto em forma de torre de resfriamento, altamente permeável ao ar externo. Dentro de quinze minutos após o evento inicial, os detectores de aspiração haviam sido ativados em todos os níveis. O BEA-RI alertou que o tempo dos detectores indicava fumaça, não necessariamente chama, mas concluiu que a construção permitia rápida propagação da fumaça. Em cerca de noventa minutos, o SBG2 estava geralmente envolvido.

O contraste com o SBG3 adjacente foi instrutivo: paredes corta-fogo de duas horas e uma porta corta-fogo, juntamente com água de incêndio, deixaram-no menos danificado que o SBG1 menor e menos protegido.

Água e eletricidade interagiram com esse design. O abastecimento público de água de incêndio disponível para os primeiros respondedores era inadequado para o evento em desenvolvimento, segundo a investigação, e a OVH não tinha reserva própria de água de extinção nem meio de bombear diretamente do canal vizinho. A chegada do EUROPA foi decisiva. A independência elétrica, normalmente um ativo de data centers, também tornou o isolamento de emergência difícil: o local combinava alimentações da rede, geradores e grandes sistemas de baterias.

O corpo de bombeiros não podia aplicar jatos de água grandes com segurança até que essas fontes fossem neutralizadas.

Este é o paradoxo da resiliência de infraestrutura. A energia de backup preserva a computação durante uma falha de energia comum, mas torna-se outra fonte de energia a ser gerenciada durante um incêndio. O fluxo de ar aberto pode reduzir custos de resfriamento e melhorar a eficiência operacional, mas pode enfraquecer o confinamento de fumaça e calor. A densidade de equipamentos e utilidades compartilhadas do local podem melhorar a economia de escala, mas concentram as consequências. Cada otimização cria um risco que deve ser controlado por uma barreira diferente.

A resposta formal da OVH às recomendações do BEA-RI argumentou que a ausência de supressão automática não violava um requisito regulatório e que as diretrizes da indústria citadas pela investigação eram posteriores ao design do SBG2. Isso é relevante para análise jurídica e de conformidade. Não é o fim da responsabilidade operacional. A conformidade mínima pergunta se uma regra impunha um controle. A resiliência pergunta se o controle era necessário para um cenário crível de alto impacto. A decisão da OVH após o incêndio de generalizar a extinção automática em locais não equipados é, por si só, evidência de que o tratamento do risco mudou.

Quatro edifícios não significavam quatro resultados independentes

De um painel de cliente, SBG1, SBG2, SBG3 e SBG4 podiam parecer múltiplos locais de infraestrutura. Durante o incidente, eles formavam um único local de emergência. O SBG2 queimou. SBG1 e SBG3 foram afetados pelo incêndio em graus variados. O SBG4 não foi danificado pelo fogo inicial. No entanto, a energia foi cortada para todos os quatro, o acesso foi controlado, sistemas compartilhados tiveram que ser avaliados e a infraestrutura sobrevivente exigiu limpeza, inspeção, recabeamento e reinicialização progressiva.

O diário de atualização contemporâneo de Estrasburgo da OVHcloud torna o caráter físico da recuperação excepcionalmente visível. As equipes removeram, limparam, inspecionaram, reinstalaram e reiniciaram equipamentos sala por sala, corredor por corredor, rack por rack e servidor por servidor. Servidores contaminados por fuligem foram transferidos para uma fábrica em Croix para trabalho especializado. Máquinas recuperáveis do SBG1 foram transferidas para outros data centers. Especialistas em recuperação de dados tentaram recuperar discos de salas danificadas.

A recuperação inicial não foi linear. SBG3 tornou-se operacional em 18 de março. Na noite de 19 de março, fumaça foi detectada em uma sala de baterias não conectada do SBG1. A OVH parou novamente SBG1 e SBG4 por precaução e revisou o cronograma de reinicialização. A restauração dos serviços retomou em 22 de março. No final de março, os servidores bare-metal do SBG4 estavam acessíveis e os serviços do SBG3 retornavam em porcentagens, enquanto o equipamento do SBG1 ainda era limpo, reparado e realocado.

O documento de registro da OVH declarou mais tarde que a maioria dos serviços de clientes retornou em três a quatro semanas e que o serviço foi completamente restabelecido para os cerca de 65.000 clientes afetados, usando aproximadamente 120.000 serviços, no início de maio. “Serviço restabelecido” não pode ser lido como “todos os dados restabelecidos”. Um servidor substituto pode ser provisionado enquanto os discos antigos e registros do cliente permanecem destruídos. Relatórios de recuperação devem separar disponibilidade de infraestrutura, inicialização de aplicativos, restauração de dados, atualidade dos dados e aceitação de negócios.

O desligamento em todo o local também mostra por que a palavra “data center” pode ser granular demais para o planejamento de desastres. Um domínio de falha é tudo que um perigo pode afetar em conjunto. Para a resposta a incêndio em Estrasburgo, o domínio relevante incluía edifícios vizinhos, procedimentos de isolamento elétrico, acesso de emergência, capacidade de água, fumaça, operações compartilhadas e a autoridade de segurança controlando o reingresso. Múltiplos nomes de edifícios não criaram recuperação independente se a mesma decisão de emergência pudesse torná-los todos indisponíveis.

Contar o impacto requer mais de um número

A medição externa da falha pela Netcraft encontrou cerca de 3,6 milhões de sites em 464.000 domínios distintos offline e mais de 18% dos endereços IP atribuídos à OVH em sua pesquisa recente não respondendo durante a janela medida. Esta é uma visão em escala da Internet da perda de acessibilidade. Ela captura subdomínios hospedados e arranjos de hospedagem downstream, o que explica por que excede em muito o número de clientes da OVH.

Os 65.000 clientes afetados e 120.000 serviços da OVH descrevem relações comerciais e de produto. Nenhum desses números diz quantos usuários finais não podiam acessar um serviço, quantas empresas perderam um canal de receita ou quantos conjuntos de dados eram irrecuperáveis. Uma reportagem contemporânea da Reuters identificou portais governamentais, bancos, lojas, sites de notícias e outros serviços online entre as perturbações. Esses exemplos mostram a diversidade de consequências, não um censo completo.

O efeito também variou ao longo do tempo. Um site sem estado com código em um repositório externo podia ser reconstruído em outra região em horas. Um serviço gerenciado com dados de recuperação mantidos pelo provedor podia retornar quando a OVH restaurasse sua plataforma. Um cliente bare-metal aguardando inspeção ou movimentação física podia ficar indisponível por semanas. Um cliente cujos únicos dados de produção e backups foram destruídos enfrentava perda permanente, independentemente da rapidez com que um novo servidor vazio chegava.

Um relatório de incidente responsável deve, portanto, usar múltiplos denominadores: clientes, serviços, servidores físicos, domínios, endereços externos inacessíveis, faixas de duração, restaurações bem-sucedidas pelo provedor, reconstruções iniciadas pelo cliente e casos de perda permanente de dados. Deve identificar quantos clientes não tinham backup, uma cópia no mesmo edifício, uma cópia no mesmo local, uma cópia em uma região OVH diferente ou uma cópia sob controle independente. As evidências públicas não fornecem essa matriz completa.

A ausência é importante porque a remediação deve seguir o mecanismo de perda. Se os clientes não selecionaram um backup remoto claramente oferecido, melhor educação sobre o produto e padrões mais seguros são relevantes. Se um produto chamado backup colocava todas as cópias em um único edifício sem divulgação clara do domínio de falha, o design do produto e o contrato são centrais. Se cópias remotas existiam, mas os clientes não podiam recuperá-las porque identidade, chaves, catálogos ou caminhos de rede estavam vinculados a Estrasburgo, a independência do sistema de recuperação é o problema.

Agregar esses casos como “alguns clientes não tinham backup” impede uma responsabilidade precisa.

Um backup é uma afirmação sobre uma restauração futura

O documento de registro de 2021 da OVHcloud indicava que os serviços de backup de dados eram serviços pagos opcionais para a maioria dos clientes e que alguns sofreram perda permanente de dados. Também indicava que os clientes podiam escolher opções oferecidas nas quais os dados de backup eram armazenados no mesmo data center ou em um data center diferente. Alguns serviços gerenciados pelo provedor, especialmente e-mail, foram apenas levemente interrompidos e não perderam dados porque a OVH os fazia backup.

Essas divulgações contradizem duas narrativas simplistas. É incorreto dizer que a OVH fez backup de todos os serviços e não conseguiu preservar todas as cópias. Também é insuficiente dizer que todos os clientes que perderam dados não compraram backup. Os modelos de serviço diferiam. Alguns clientes mantinham a responsabilidade pela única cópia durável, alguns selecionavam opções do provedor com locais diferentes, e alguns consumiam serviços para os quais a OVH controlava a recuperação.

Um backup não é definido apenas por um trabalho de cópia bem-sucedido. É uma promessa controlada de que, após falhas especificadas, uma organização pode recuperar uma versão suficientemente recente e intacta de suas informações e usá-la para restaurar um serviço prioritário dentro de um prazo aceito. Essa promessa contém pelo menos seis propriedades:

1. Escopo:os dados, estado do sistema, configurações, armazenamentos de identidade, chaves, software e dependências externas incluídos ou intencionalmente excluídos.
2. Ponto:a idade máxima aceitável dos dados restaurados, geralmente expressa como um objetivo de ponto de recuperação, e o histórico de retenção necessário no caso de corrupção ou descoberta tardia.
3. Isolamento:as falhas físicas, lógicas, administrativas e do provedor que não podem destruir ou alterar todas as cópias em conjunto.
4. Acesso:as credenciais, chaves de criptografia, catálogos, ferramentas, caminhos de rede e pessoas autorizadas necessárias para recuperar a cópia durante uma crise.
5. Tempo:a duração testada para obter capacidade, transferir dados, reconstruir dependências, reconciliar transações e trazer uma função de negócios a um estado aceitável.
6. Evidência:o monitoramento de que o backup foi concluído, verificações de integridade, restaurações amostradas, exercícios de serviço completos e registros mantidos mostrando o resultado.

Estrasburgo foi principalmente um teste de isolamento físico e tempo de recuperação, mas expôs todos os seis. Uma imagem de disco sem registros DNS, segredos, código de implantação ou consistência de banco de dados pode não reiniciar um aplicativo. Uma cópia remota criptografada com chaves disponíveis apenas através da região com falha pode ser durável e inutilizável. Um arquivo de vários terabytes que leva dias para recuperar pode perder um objetivo de negócio de doze horas. Um backup armazenado no mesmo domínio energético e de incêndio pode estar perfeitamente atualizado até o evento que deveria cobrir.

A autoridade francesa de proteção de dados CNIL agora define a lição física claramente em suas diretrizes de segurança de backup: manter pelo menos uma cópia em um local geograficamente distinto, isolar pelo menos uma cópia offline, proteger backups no mesmo nível de segurança que a produção e testar a integridade e a restauração. As diretrizes de segurança em nuvem da CNIL instruem os clientes a verificar se um provedor de nuvem possui locais de backup geograficamente distantes de seus data centers. Esses documentos de 2024 são orientações posteriores, não evidência da obrigação contratual precisa para cada serviço OVH em 2021.

Eles são uma referência clara para a prática atual.

O caso Bati Courtage tornou a linguagem do produto consequente

A disputa de um cliente dá à fronteira do backup uma especificidade legal. France Bati Courtage usava um servidor privado virtual OVH e uma opção de backup automatizado paga. Segundo o processo, a OVH o informou em abril de 2021 que o backup também havia sido total e irreversivelmente destruído porque as cópias estavam no mesmo edifício que o servidor primário. O cliente pediu milhões de euros por perda de dados e danos comerciais downstream.

O resultado mudou em apelação. Em sua decisão de 24 de abril de 2025, a Corte de Apelação de Douai considerou violação contratual porque a OVH não poderia deixar o cliente acessar o backup concluído e retê-lo para recuperação. Não confirmou o pedido separado do cliente de que a OVH falhou ao não localizar os serviços em locais geograficamente isolados. Também manteve a conclusão anterior de que a OVH não cometeu falta grave ou violações graves de segurança contra incêndio nesta disputa, rejeitou a defesa de força maior da OVH, confirmou as limitações de responsabilidade aplicáveis e reduziu a indenização para 1.800,48 EUR.

Esta decisão é mais restrita e instrutiva do que a indenização amplamente relatada em primeira instância. Ela não estabelece que todo contrato de backup da OVH prometia um data center remoto. Ela não estabelece uma regra geral de que qualquer backup no mesmo site é legalmente defeituoso. Ela mostra que a responsabilidade não pode ser resolvida dizendo “o cliente possuía a política de backup” quando o cliente pagou ao provedor para realizar um backup e o provedor tinha obrigações contratuais em relação à cópia resultante.

O caso também demonstra por que os rótulos contratuais precisam de uma topologia por trás deles. Termos como “fisicamente isolado”, “infraestrutura”, “local”, “região” e “remoto” podem ter significados diferentes. Um rack de disco separado está isolado de uma falha de servidor. Uma sala separada pode estar isolada de um incêndio de rack. Um edifício separado pode sobreviver a alguns eventos de sala, mas não necessariamente a um corte de energia no campus ou fechamento de perímetro. Uma região separada é mais forte, desde que as regiões não compartilhem controle, conta, chave ou dependências de rede que bloqueiem a recuperação.

Os clientes não deveriam ter que deduzir esses limites de um adjetivo de marketing. Uma descrição de serviço deve nomear o domínio de falha da cópia, se o local é selecionado por padrão ou por opção, se o local pode mudar, os perigos que o design deve sobreviver, o objetivo de recuperação e os deveres restantes do cliente. Os provedores devem manter a versão histórica dessas representações, pois a interface e a documentação disponíveis no momento da compra do serviço podem se tornar evidências centrais posteriormente.

A limitação contratual e a responsabilidade operacional também divergem. A indenização em apelação foi baixa porque o tribunal aplicou as limitações acordadas após avaliar as reivindicações e cláusulas diante dele. Um limite de responsabilidade não torna a perda permanente de dados aceitável operacionalmente, assim como uma perda alegada grande não prova que o provedor deve legalmente esse valor. Os contratos alocam exposição financeira. Eles não restauram informações nem provam que um controle foi adequadamente projetado.

Responsabilidade compartilhada precisa ser específica o suficiente para ser operacional

“Responsabilidade compartilhada” é frequentemente usada como uma maneira educada de dizer que ambas as partes tinham trabalho a fazer. A menos que o trabalho seja nomeado, a expressão distribui a culpa após a falha em vez de atribuir controles antes. Estrasburgo apoia uma divisão mais exata.

A OVH possuía a probabilidade de um evento elétrico local se transformar em perda de edifício. Ela escolheu o design físico, detecção e supressão de incêndio, compartimentação, isolamento de utilidades, procedimentos de emergência, estrutura de manutenção, recursos hídricos e o relacionamento com os bombeiros públicos. Os clientes não podiam instalar sprinklers no SBG2 nem criar um desligamento elétrico de emergência. Esses são controles do provedor mesmo quando os contratos de cliente limitam danos.

A OVH também possuía a verdade sobre seus produtos. Apenas o provedor podia saber onde um backup automatizado caía, quais serviços ele fazia backup por padrão, quais regiões compartilhavam sistemas e como o plano de controle se comportava durante a perda de Estrasburgo. Ela devia descrever essas propriedades com precisão suficiente para que um cliente pudesse tomar uma decisão de risco. Onde a OVH se encarregava do serviço de backup, ela possuía o desempenho do serviço prometido e as evidências sobre a cópia resultante.

Os clientes possuíam o modelo de consequência. Um provedor não podia saber, sem arranjo gerenciado específico, se um pequeno servidor virtual continha um site de teste descartável ou a única cópia de anos de registros comerciais. O cliente devia classificar os dados, definir objetivos de recuperação, selecionar uma arquitetura proporcional ao impacto, manter cópias fora do domínio de falha primário e testar a reconstrução. Comprar infraestrutura não transferia o dever do cliente de decidir quanto tempo o negócio podia tolerar sua perda.

A fronteira se move com o modelo de serviço. Em bare metal ou infraestrutura como serviço, o cliente geralmente possui o backup e o failover consistentes com o aplicativo. Em um banco de dados gerenciado, um produto de e-mail hospedado ou um serviço de backup explícito, o provedor possui mais da cópia, retenção, consistência e caminho de restauração. Um revendedor no mercado ou um provedor de serviços gerenciados introduce outra camada: ele pode selecionar a OVH, configurar o backup, representar a resiliência para seus próprios clientes e reter o único acesso administrativo. Os clientes finais devem conhecer essa cadeia.

As fundamentações atuais de backup da agência francesa de cibersegurança ANSSI transformam esses deveres em controles práticos. Elas recomendam objetivos de ponto e tempo de recuperação, o esquema 3-2-1, pelo menos uma cópia offline ou devidamente protegida fora do local, testes de restauração regulares, ordem de restauração e proteção das mídias de instalação e configurações de aplicativo. Para backup terceirizado, a ANSSI destaca a localização na UE, o comportamento de replicação do provedor, a criptografia controlada pelo cliente e o tempo de recuperação.

É um lembrete útil de que resiliência física, isolamento cibernético, soberania e recuperabilidade devem ser projetados juntos.

Localidade responde a várias perguntas diferentes

A identidade europeia da OVHcloud importava em 2021 e ainda importa. Para governos e organizações reguladas buscando uma alternativa aos hyperscalers não europeus, um provedor francês operando data centers europeus pode oferecer vantagens jurisdicionais, econômicas e operacionais significativas. O incêndio de Estrasburgo não tornou a soberania de dados irrelevante. Mostrou que a soberania não é um substituto para a engenharia de disponibilidade.

“Onde estão os dados?” pode significar pelo menos cinco coisas:

• Localização jurídica:quais regras de proteção de dados, divulgação, insolvência e setoriais do país governam o armazenamento, processamento e acesso.
• Controle corporativo:quais empresas controladoras, administradores, subcontratados e solicitações legais estrangeiras podem influenciar o serviço.
• Localização física:qual edifício, planície de inundação, rede elétrica, abastecimento de água, campus e risco regional contém cada cópia.
• Localização lógica:qual região, zona, conta, locatário, sistema de chaves e plano de controle precisam funcionar para recuperar ou fazer failover dos dados.
• Distância operacional:quanta latência, largura de banda, pessoal e tempo de recuperação separam a produção de seus usuários e da cópia de recuperação.

Uma política que diz “todos os dados devem permanecer na França” responde a parte da primeira pergunta e restringe a terceira. Ela não exige que produção e backup ocupem o mesmo edifício. A França contém várias áreas metropolitanas e regiões de nuvem. Uma política exigindo armazenamento na UE permite ainda mais diversidade geográfica enquanto preserva um perímetro jurídico europeu. Se isso é suficiente depende da lei da organização, seu modelo de ameaça, sensibilidade dos dados e objetivo de recuperação.

A explicação da Comissão Europeia sobre transferências internacionais também impede uma simplificação inversa: o GDPR não impõe uma regra absoluta de que dados pessoais nunca podem deixar o Espaço Econômico Europeu. Ele prevê decisões de adequação, garantias e derrogações limitadas para transferências. Algumas organizações adotam requisitos de localidade mais rigorosos devido a leis setoriais, política pública, compromissos contratuais ou exposição a jurisdições estrangeiras.

As diretrizes de qualificação SecNumCloud da ANSSI ilustram o modelo de soberania mais rico. Elas tratam da localização na UE não apenas para dados do cliente, mas também para administração, supervisão, backups, diretórios e dados técnicos, considerando controle corporativo e exposição a leis não europeias. Este quadro é sobre controle do serviço e dos dados, não apenas latitude e longitude de um disco.

A conclusão prática é construtiva: soberania e separação de desastres podem reforçar-se mutuamente. Um órgão público francês pode manter produção sensível em um ambiente europeu qualificado, manter uma cópia de recuperação geograficamente distinta dentro da UE, usar criptografia e chaves controladas pelo cliente e manter procedimentos de exportação testados para outro ambiente aprovado. A arquitetura pode custar mais e exigir revisão jurídica cuidadosa. A compensação deve ser explícita em vez de escondida atrás da palavra “local”.

Concentração é uma propriedade de aplicação e também uma propriedade de mercado

A falha afetou portais governamentais, comércio, mídia, jogos e serviços ao consumidor porque muitas organizações escolheram um único provedor o herdaram através de um provedor. Esta é a concentração de nuvem no nível de mercado. Havia também concentração dentro de aplicações individuais: produção, backups, DNS, e-mail, gerenciamento e ferramentas de implantação podiam compartilhar a OVH ou Estrasburgo mesmo quando apareciam como produtos separados.

Ambas as formas exigem tratamento diferente. Reguladores podem monitorar a dependência sistêmica de um pequeno grupo de provedores de nuvem. Equipes de procurement podem evitar concentração não examinada de provedores entre departamentos. Proprietários de aplicação devem mapear dependências que determinam se seu próprio serviço pode se recuperar. Uma empresa pode usar três provedores de nuvem em seu portfólio enquanto um único sistema crítico ainda não tem cópia independente. Outra pode permanecer com um único provedor, mas usar regiões verdadeiramente separadas, backups exportáveis, DNS independente e mídias de recuperação offline.

A regulamentação financeira expressa cada vez mais essa responsabilidade retida do cliente. As diretrizes de 2019 da Autoridade Bancária Europeia sobre terceirização exigem que instituições cobertas governem riscos de terceirização e permaneçam capazes de supervisão em vez de se tornarem cascas vazias. O subsequente Regulamento de Resiliência Operacional Digital da UE (DORA) exige que entidades financeiras cobertas mantenham e testem periodicamente disposições de backup, restauração e recuperação. Seus requisitos no Artigo 12 incluem segregação física e lógica quando as entidades restauram dados de backup usando seus próprios sistemas.

Essas regras têm escopos definidos e não devem ser projetadas retroativamente sobre cada cliente OVH de 2021. Elas mostram a direção da prática responsável: terceirização não terceiriza a responsabilidade do órgão de governança pela continuidade.

O quadro de implementação detalhado da DORA vai além. O regulamento delegado de 2024 sobre gestão de risco de TIC inclui cenários envolvendo perda parcial ou total de instalações e data centers, falha de serviço de terceiros, failovers para capacidade redundante e cortes de energia generalizados. Estrasburgo é exatamente o tipo de evento físico e de provedor combinado que um exercício sério deve modelar.

Design multi-provedor pode reduzir algumas dependências, mas não é automaticamente superior. Adiciona complexidade em identidade, rede, consistência de dados, habilidades, observabilidade e coordenação de incidentes. O objetivo correto é recuperação portável e testável para funções importantes, não um slogan arquitetônico. Às vezes, isso significa serviço ativo em zonas independentes. Às vezes, uma capacidade morna em outra região. Às vezes, um backup protegido mais infraestrutura como código e reconstrução testada atendem à necessidade de negócio a custo muito menor.

Restauração deve ser comprovada do lado do cliente

Restauração pelo provedor e recuperação pelo cliente não são o mesmo relógio. A OVH podia declarar um data center operacional quando energia, rede e grande parte dos servidores estavam disponíveis. Um cliente ainda precisava validar sistemas de arquivos, bancos de dados, filas, certificados, DNS, integrações e transações de negócio. Se o servidor original foi destruído, o cliente precisava provisionar uma alternativa, recuperar dados, reconstruir o aplicativo e reconciliar tudo o que ocorreu após a última cópia utilizável.

Um exercício de recuperação maduro começa com uma perda presumida, não uma exportação conveniente. A equipe deve fingir que a região primária está inacessível, que os administradores normais não podem fazer login através de seu caminho de identidade e que o suporte do provedor está saturado. Deve obter o backup usando credenciais e chaves armazenadas fora do ambiente com falha, construir capacidade limpa no destino aprovado, restaurar dependências na ordem documentada, validar a integridade dos dados, redirecionar usuários e medir o resultado de negócio.

As evidências devem responder a perguntas práticas. Qual era o timestamp do banco de dados restaurado? Quais escritas foram perdidas? Todas as versões do armazenamento de objetos estavam incluídas? As chaves podiam ser recuperadas sem enfraquecer o controle de acesso? O DNS mudou dentro do prazo esperado? Provedores externos de pagamento, e-mail e identidade aceitaram os novos endereços? Quanto tempo até a primeira transação segura, e quanto tempo até a capacidade total? Quem aprovou o retorno e qual reconciliação restava?

Monitoramento de backups sozinho não pode responder a essas perguntas. Um trabalho verde prova que o software escreveu algo em um destino. Um teste de integridade prova que dados selecionados podem ser lidos. Uma restauração técnica prova que sistemas podem ser reconstruídos. Um exercício de serviço prova que a organização pode fornecer sua função prioritária sob a falha presumida. Cada um é útil; nenhum deve ser representado como o próximo.

Isso é particularmente importante para organizações pequenas. Elas podem não precisar de infraestrutura ativo-ativo ou de uma segunda nuvem dedicada. Precisam de um caminho proporcionado. Uma pequena empresa pode exportar seu banco de dados e documentos críticos para um destino criptografado sob uma conta separada, manter seu domínio e credenciais de implantação independentemente, documentar uma reconstrução limpa e testar uma amostra de restauração. O controle deve corresponder ao custo da perda dos registros, não ao preço mensal do servidor.

A remediação da OVHcloud tratou da cadeia física

A resposta da OVH ao BEA-RI descreveu um programa substancial “Hyper Resilience”. A empresa afirmou que fortaleceria a detecção, generalizaria a extinção automática onde estava ausente, redesenhearia zonas e compartimentação, aumentaria a resistência ao fogo comum de 60 para 120 minutos e colocaria salas de energia e baterias fora dos edifícios dos data centers para novos locais e, onde possível, para locais existentes. Planejava cortes elétricos remotos por zona para que os respondedores pudessem isolar o perigo sem desativar desnecessariamente áreas não afetadas.

A resposta também indicou que os bombeiros locais visitaram todos os locais da OVH dentro de quatro meses após o incidente, que documentos de emergência e procedimentos de corte elétrico foram revisados e que um novo departamento de riscos industriais foi criado. Em Estrasburgo, a OVH instalou um reservatório privado de água de 120 metros cúbicos em colaboração com o SIS67. Afirmou que todos os locais receberam uma análise de risco de incêndio e que a eficácia seria medida por um estudo de vulnerabilidade quando os trabalhos fossem concluídos. O SBG5, inaugurado em julho de 2022, foi apresentado como exemplo dos novos padrões.

Essas ações correspondem bem à cadeia causal e de propagação da investigação. A supressão responde ao crescimento precoce. Compartimentos corta-fogo mais fortes respondem à propagação vertical e entre edifícios. Salas de energia externas separam riscos de ignição das salas de servidores. Cortes zoneados respondem ao atraso e ao raio de explosão do isolamento elétrico. O armazenamento de água responde à capacidade de primeira resposta. Visitas e exercícios dos bombeiros respondem ao desconhecimento, planos e decisões de comando.

O documento de registro universal de 2025 da OVHcloud indica que o grupo continuou o mapeamento de riscos de local durante o ano de 2025 e descreve Hyper Resilience como fortalecendo a segurança dos data centers além das recomendações regulatórias e de seguradoras. Também registra uma provisão contínua para as consequências do incêndio de Estrasburgo, incluindo ações de responsabilidade. Isso é evidência de um programa sustentado e tratamento financeiro, não de um certificado de conclusão independente site por site.

Uma conclusão responsável publicaria ou forneceria a clientes qualificados e auditores uma matriz de controle: quais locais têm supressão automática em cada sala de energia e TI relevante; quais têm compartimentos de 120 minutos; quais salas de bateria são externas; quais zonas têm isolamento acionado remotamente; quais necessidades de fluxo de água foram testadas; quais exercícios de bombeiros ocorreram; quais constatações permanecem abertas; e qual parte independente verificou a operação. Um compromisso político é o início da remediação. A cobertura e o exercício contraditório mostram se funciona.

A empresa também merece crédito por manter um diário público detalhado de atualizações durante uma recuperação difícil, mobilizar capacidade especializada de limpeza e recuperação, substituir infraestrutura, comunicar progresso específico do produto e publicar uma resposta formal às recomendações de segurança. Transparência não é completa apenas porque as atualizações são frequentes, mas esses registros permitem que clientes e investigadores reconstruam decisões que de outra forma desapareceriam.

O design de produtos evoluiu, mas a configuração ainda decide a resiliência

A documentação atual da OVHcloud é mais explícita sobre domínios de falha do que a linguagem anterior ao incêndio visível na disputa Bati Courtage. Seu guia de modos de implantação distingue regiões de uma zona de disponibilidade, regiões de três zonas e zonas locais. Ele afirma que uma região 1-AZ permanece vulnerável a falhas que afetam um data center inteiro, enquanto uma arquitetura 3-AZ usa zonas independentes para casos de produção e recuperação de desastres mais exigentes.

A visão geral da região e zona de disponibilidade da empresa também afirma que clientes buscando maior resiliência devem selecionar uma região multizona suportada e construir para várias zonas. Os verbos importam: o provedor fornece as zonas; o cliente deve distribuir recursos e estado do aplicativo entre elas. Simplesmente iniciar em uma região 3-AZ não garante que uma máquina virtual, banco de dados ou volume colocado manualmente abranja várias zonas.

A documentação atual de backup de instância agora distingue backups locais e remotos. Um backup local permanece na mesma região. Um backup remoto cria uma cópia em outra região selecionada e é cobrado separadamente. Esta é uma linguagem de domínio de falha muito mais clara. Isso também preserva uma escolha explícita do cliente, o que significa que provisionamento e configuração permanecem parte do controle.

A documentação atual não deve ser usada para reconstruir o que era oferecido a cada cliente em março de 2021. Ela é relevante para a questão atual de responsabilidade: o mercado aprendeu a expor separadamente localidade e resiliência? A OVHcloud faz isso agora nesses guias de produto. O próximo passo de garantia é tornar a distinção consistente em páginas de produto, contratos, padrões de painel de controle, APIs, faturas e respostas de suporte, incluindo produtos onde backups gerenciados pelo provedor seguem regras diferentes.

Um design mais seguro também pode usar padrões progressivos. Um serviço de desenvolvimento de baixo custo pode razoavelmente usar backup local como padrão se a interface o rotular como proteção contra falha de instância, não desastre regional. Um banco de dados de produção ou um produto marcado como backup pode exigir que o cliente confirme o domínio de falha, mostrar um aviso quando todas as cópias compartilham um único site e oferecer um destino remoto na mesma região jurídica. O objetivo é aceitação informada de risco, não forçar toda carga de trabalho na arquitetura mais cara.

O conselho precisa de evidências sobre dois planos de controle

O incêndio de Estrasburgo atravessou um plano de controle de instalações e um plano de controle de recuperação do cliente. O conselho e a gestão de risco da OVH precisam de garantia sobre ambos. A engenharia de incêndio não pode ser tratada como nota de rodapé imobiliária, e produtos de backup não podem ser tratados apenas como receita de armazenamento.

Para a camada de instalações, a gestão deve conhecer a perda máxima provável em cada local, não apenas a redundância de equipamentos. Relatórios devem mostrar cobertura de supressão, integridade da compartimentação, separação de salas de energia, desempenho de detecção, água de emergência, tempo de isolamento elétrico, familiaridade dos bombeiros, exceções de manutenção e trabalhos corretivos atrasados. Exercícios devem assumir que controles comuns falham e que os bombeiros precisam de autoridade imediata e precisa para isolar energia.

Para a camada de serviço, a gestão deve saber como os domínios de falha dos produtos são representados e testados. Relatórios devem mostrar quantos serviços comercializados com linguagem de backup ou alta disponibilidade armazenam cada cópia em um único site ou região; quantos clientes selecionaram proteção remota; sucesso de restauração por produto e escala; dependências de chaves e identidade; distribuição de tempos de recuperação; desvio de documentação; e reclamações indicando que clientes entenderam mal o local.

O conselho também deve receber exceções, não apenas médias. Uma taxa de sucesso de 99,99% de trabalhos de backup pode coexistir com milhares de cópias em um único domínio físico. Uma porcentagem geral de supressão pode esconder um edifício antigo de alta densidade. Um tempo médio de restauração pode esconder os conjuntos de dados maiores e mais consequentes. A exposição dos extremos pertence à governança porque Estrasburgo foi um evento extremo com impacto concentrado.

Um desafio independente deve traçar uma promessa ao cliente até o fim. Selecione um serviço vendido como backup. Registre o que a interface e o contrato dizem. Localize cada cópia e seus metadados de controle. Remova o site primário do exercício. Negue caminhos normais de identidade e suporte. Restaure em um destino que satisfaça as regras de localidade do cliente. Compare os resultados medidos com o objetivo de recuperação prometido. Qualquer ruptura é um desvio acionável, seja pertencente ao produto, infraestrutura, suporte ou cliente.

O que os clientes devem exigir antes de qualificar um serviço como resiliente

As organizações não precisam de acesso privado a cada plano de data center. Precisam de respostas suficientemente detalhadas para decidir se um serviço corresponde à consequência da falha. As seguintes perguntas transformam as lições de Estrasburgo em evidências de procurement:

As respostas devem estar vinculadas ao produto exato. Um relatório de resiliência corporativa do provedor pode não descrever o VPS barato, o snapshot local ou o banco de dados gerenciado comprado. Certificações podem estabelecer controles úteis, mas podem ter exclusões de escopo. Um acordo de nível de serviço de disponibilidade fornece recurso após um limite perdido; não descreve por si só a durabilidade dos dados nem garante a recuperação.

Os clientes também devem verificar a concentração sob nomes de revendedores. Um provedor de backup gerenciado pode armazenar seu repositório na mesma região OVH que a produção. Uma marca de hospedagem secundária pode usar a OVH internamente. DNS, e-mail, código fonte, segredos e comunicações de incidente podem todos compartilhar o provedor. A diversidade é medida pelos caminhos sobreviventes, não pelo número de faturas.

Por fim, um cliente deve decidir quanta perda é aceitável. Perda zero de dados e tempo de inatividade quase zero em desastre regional exigem replicação contínua, design de aplicativo, capacidade e testes operacionais que podem ser caros. Uma cópia semanal offline pode ser adequada para um arquivo estático e catastrófica para transações. Responsabilidade não exige o mesmo controle em todos os lugares. Exige uma relação consciente entre consequência, recuperação prometida, arquitetura e evidências.

O sinal duradouro

O incêndio de Estrasburgo não foi apenas uma ignição infeliz seguida de um lembrete para fazer backups. Foi uma demonstração de como as abstrações falham sob tensão física. Edifícios separados formavam um único local de emergência. Servidores saudáveis tornaram-se indisponíveis junto com os danificados. Um backup concluído podia desaparecer com a produção. Um local europeu que servia à soberania e latência podia se tornar uma concentração de risco de incêndio. Um servidor substituto podia restaurar a infraestrutura sem restaurar a atividade do cliente.

O registro público também contém melhorias significativas. A detecção e a equipe noturna protegeram vidas. Os bombeiros e o barco-bomba EUROPA limitaram a propagação. A OVH conduziu uma recuperação difícil e transparente, aceitou as recomendações do BEA-RI em termos operacionais e lançou um amplo programa de resiliência física. Sua documentação atual de produto distingue mais claramente backup local de backup remoto e implantação monozona de implantação multizona. Essas não são mudanças cosméticas.

O padrão de responsabilidade restante é a evidência ao longo do tempo. A OVH deve ser capaz de mostrar que os controles físicos identificados após o incêndio estão instalados, mantidos e exercidos nos locais relevantes; que a linguagem do produto corresponde aos reais domínios de falha; e que a recuperação gerenciada funciona quando uma região e seus caminhos normais de controle estão ausentes. Os clientes devem ser capazes de mostrar que dados críticos têm uma cópia utilizável fora do risco primário, dentro dos limites jurídicos aprovados, e que suas pessoas podem restaurá-los dentro do objetivo de negócio.

Nenhum provedor de nuvem pode prometer que um edifício nunca pegará fogo. Nenhum cliente pode eliminar todas as dependências. A promessa crível é mais restrita: um evento físico previsível não consumirá silenciosamente a produção, a recuperação e o meio de entender o que foi perdido; as escolhas de localidade serão explícitas tanto sobre jurisdição quanto sobre risco; e a palavra “backup” será apoiada pela única evidência que importa em última análise: uma restauração bem-sucedida nas condições para as quais a cópia foi adquirida.