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

Resumo

• Os alarmes de incêndio foram acionados no local de Estrasburgo da OVHcloud às 00:35 do dia 10 de março de 2021. O incêndio começou nas salas de energia do térreo do SBG2, destruiu esse prédio, danificou quatro das doze salas do SBG1 e forçou o desligamento de energia em todo o campus. O SBG3 e o SBG4 não foram consumidos pelo incêndio inicial, mas os serviços lá ficaram indisponíveis devido à necessidade de isolamento elétrico, inspeção de segurança, limpeza e reinicialização escalonada. Ninguém morreu ou ficou ferido.
• A investigação francesa de segurança industrial não determinou a causa exata das falhas elétricas quase simultâneas observadas em um UPS e suas baterias de chumbo associadas. Mas estabeleceu fatores de propagação e resposta: nenhum sistema de extinção automática em nenhum dos cinco prédios de Estrasburgo, movimento rápido da fumaça devido ao design aberto e voltado para resfriamento do SBG2, capacidade limitada de água para incêndio e um difícil desligamento elétrico em todo o local. A detecção funcional, a equipe noturna, a separação resistente ao fogo que protegeu o SBG3 e a chegada de um barco-bomba franco-alemão de alta capacidade limitaram consequências piores.
• A perda de disponibilidade e a perda permanente de dados foram resultados diferentes. A OVHcloud relatou cerca de 65.000 clientes e 120.000 serviços interrompidos, enquanto a Netcraft observou aproximadamente 3,6 milhões de sites em 464.000 domínios offline. A OVHcloud disse que muitos clientes que perderam dados não haviam selecionado um backup opcional. Isso não encerra a questão da responsabilidade: o documento de registro da própria OVHcloud afirmava que os backups oferecidos podiam ser armazenados no mesmo data center ou em um diferente, e uma decisão judicial posterior tratou de um cliente cujo backup automático pago foi destruído no mesmo prédio que a produção.
• O evento expôs um erro de categoria na contratação de nuvem. Soberania de dados, jurisdição legal, latência, disponibilidade, backup e recuperação de desastres são relacionados, mas não intercambiáveis. Manter dados na França ou na União Europeia pode satisfazer uma política de localidade, mas ainda permitir que cópias de produção e recuperação compartilhem um mesmo perigo físico. Por outro lado, uma cópia geograficamente distante pode permanecer dentro do mesmo território legal e sob os mesmos controles europeus.
• A OVHcloud divulgou mudanças substanciais pós-incêndio, incluindo supressão automática mais ampla, compartimentação mais forte, salas de energia separadas, cortes elétricos remotos, auditorias nos locais, trabalho com os bombeiros e novas opções de backup multizona e remoto. O fechamento responsável, no entanto, exige evidências específicas de serviço e local: cobertura de controles concluídos, inspeção independente, exercícios realistas de incêndio e isolamento de energia, locais de backup declarados, 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 se tornou um evento de responsabilidade na nuvem

A frase "dados na nuvem" incentiva uma abstração. É útil quando engenheiros querem uma interface padrão para capacidade de computação, mas perigosa quando tomadores de decisão começam a tratar localização, energia e incêndio como detalhes de outra pessoa. Cada servidor virtual está em uma sala. Cada réplica de armazenamento ocupa equipamentos conectados a sistemas elétricos e de resfriamento. Cada fluxo de trabalho de recuperação depende de pessoas, redes, credenciais, catálogos e um lugar de onde se pode obter capacidade de reposição.

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 prédios do campus da OVHcloud no Porto do Reno. O SBG1 foi parcialmente destruído. Os outros dois datacenters no local foram desligados, embora a atualização inicial da empresa os descrevesse como intactos. A perda, portanto, percorreu pelo menos três mecanismos distintos: equipamentos foram fisicamente destruídos; equipamentos em prédios adjacentes foram expostos a calor, fumaça, água ou incerteza; e equipamentos saudáveis ficaram indisponíveis quando o local teve que ser isolado eletricamente e tornado seguro.

Esses mecanismos importam porque correspondem a diferentes controles. A supressão automática e a 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 local 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 suportar.

A reconstrução pública mais autoritativa é o relatório de investigação de maio de 2022 do Bureau d'enquetes et d'analyses sur les risques industriels (BEA-RI) francês, disponível aqui. Seu mandato foi prevenção, não alocaçã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. Não pode ser convertido em uma conclusã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 em um equipamento se tornasse uma interrupção em vários prédios, uma restauraçã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ço e cópias independentes. Reguladores e órgãos profissionais controlavam partes da estrutura mínima.

Nenhum desses papéis apaga os outros.

O que a evidência estabelece, e o que não estabelece

O relatório do BEA-RI coloca o primeiro alarme às 00:35. Um guarda chegou a uma sala de energia do SBG2 às 00:37 e encontrou fumaça preta espessa. O prédio foi evacuado às 00:39, o serviço de incêndio e resgate de Baixo Reno foi chamado às 00:42, e as primeiras equipes chegaram às 00:59. A página pública de incidentes da OVH usou 00:47 como o horário do 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 teve acesso a alarmes e registros operacionais, enquanto a página da empresa forneceu um marcador público do incidente.

A energia de emergência para o SBG2 foi cortada à 01:13 e para SBG1, SBG3 e SBG4 à 01:28. As equipes de incêndio viram arcos elétricos e seguraram o uso intensivo de água até que o risco pudesse ser controlado. Por volta de 01:42, o incêndio havia se espalhado pelo primeiro andar. Cerca de 02:00, os bombeiros relataram envolvimento generalizado do SBG2. O barco-bomba de alta capacidade EUROPA chegou por volta de 03:00, usando a via navegável adjacente. O incêndio foi extinto às 10:02, e a intervenção foi considerada completa às 18:13.

A investigação localizou a origem do incêndio em salas que continham baterias e equipamentos de fonte de alimentação ininterrupta (UPS). Gravações de vídeo e monitoramento mostraram uma falha elétrica quase simultânea na unidade UPS ASI2 e suas baterias associadas, que estavam em salas separadas. Houve manutenção no UPS naquela manhã e medições incomuns de umidade 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 disseram explicitamente que a evidência era insuficiente para selecionar uma causa iniciadora precisa.

Essa contenção foi frequentemente perdida em releituras que dizem que um sistema de resfriamento com vazamento ou um UPS recentemente revisado "causou" o incêndio. O registro oficial de acidentes ARIA francês (acessível aqui) é uma corroboração útil para o ambiente 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 deve dizer que os eventos elétricos iniciais 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 controle. Uma organização deve estar preparada para falha de equipamentos sem saber qual componente falhará em seguida. A proteção contra incêndio é projetada em torno dessa incerteza. A questão responsável não é apenas se a OVH deveria ter previsto uma sequência elétrica específica. É se detecção, controle automático, compartimentação, água, isolamento elétrico, design do prédio e procedimentos de emergência deram às pessoas e aos serviços adjacentes proteção independente suficiente depois que algo pegou fogo.

O prédio detectou perigo, mas não conseguiu contê-lo

O local de Estrasburgo fez bem um trabalho de segurança de vida. 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 feridos. O relatório do BEA-RI credita esses controles. A responsabilidade deve reter barreiras bem-sucedidas tão cuidadosamente quanto as falhas, porque o design futuro depende de saber o que realmente ganhou tempo.

A detecção não foi combinada com supressão automática. A investigação descobriu que nenhum dos cinco prédios do local tinha um sistema automático de proteção contra incêndio. As salas de baterias e UPS do SBG2 eram monitoradas, mas não havia sistema projetado para extinguir, controlar ou retardar o incêndio em seu estágio inicial. Tal sistema poderia ter agido antes do desligamento elétrico completo e sem expor os bombeiros a equipamentos energizados. Não garantiria extinção, particularmente em uma sala elétrica, mas poderia ter mudado a curva de crescimento do incêndio.

O prédio então ajudou a fumaça e o calor a se moverem. O SBG2 usava um design aberto de resfriamento tipo torre, altamente permeável ao ar externo. Dentro de quinze minutos do evento inicial, detectores por 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 chamas, mas concluiu que a construção permitiu que a fumaça se espalhasse rapidamente. Em aproximadamente noventa minutos, o SBG2 estava geralmente envolvido.

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

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

O serviço de incêndio não podia aplicar com segurança grandes jatos de água 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 comum de utilidade, mas se torna outra fonte de energia a gerenciar durante um incêndio. O fluxo de ar aberto pode reduzir o custo de resfriamento e melhorar a eficiência operacional, mas pode enfraquecer a contenção de fumaça e calor. Equipamentos densos e utilidades compartilhadas do local podem melhorar a economia de escala, mas concentrar a consequência. 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 legal e de conformidade. Não é o fim da responsabilidade operacional. A conformidade mínima pergunta se uma regra exigia um controle. A resiliência pergunta se o controle era necessário para um cenário crível de alta consequência. 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 de risco mudou.

Quatro prédios não significaram quatro resultados independentes

De um painel de cliente, SBG1, SBG2, SBG3 e SBG4 podiam parecer várias localizações de infraestrutura. Durante o incidente, formaram um único local de emergência. SBG2 queimou. SBG1 e SBG3 foram afetados pelo incêndio em diferentes graus. SBG4 não foi danificado pelo incêndio inicial. No entanto, a eletricidade foi cortada em todos os quatro, o acesso foi controlado, sistemas compartilhados tiveram que ser avaliados, e a infraestrutura sobrevivente exigiu limpeza, inspeção, recapacitação e reinicialização escalonada.

O registro de atualizações contemporâneo de Estrasburgo da OVHcloud (log de atualizações) 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 datacenters. Especialistas em recuperação de dados tentaram recuperar discos de salas danificadas.

A primeira recuperação não foi linear. O 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 desligou SBG1 e SBG4 novamente como precaução e revisou o cronograma de reinicialização. A restauração dos serviços foi retomada 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 estavam retornando em percentagens, enquanto os equipamentos do SBG1 ainda estavam sendo limpos, reparados e realocados.

O documento de registro da OVH disse posteriormente que a maioria dos serviços de clientes retornou em três a quatro semanas e que o serviço foi totalmente restaurado para os aproximadamente 65.000 clientes afetados, usando cerca de 120.000 serviços, no início de maio. "Serviço restaurado" não pode ser lido como "todos os dados restaurados". Um servidor de reposição pode ser provisionado enquanto os discos e registros anteriores do cliente permanecem destruídos.

O relato da recuperação deve separar disponibilidade de infraestrutura, inicialização de aplicação, restauração de dados, atualidade dos dados e aceitação do negócio.

O desligamento em todo o local também mostra por que a palavra "data center" pode ser muito granular para planejamento de desastres. Um domínio de falha é tudo que um perigo pode afetar em conjunto. Para resposta a incêndio em Estrasburgo, o domínio relevante incluía os prédios vizinhos, procedimentos de isolamento de energia, acesso de emergência, capacidade de água, fumaça, operações compartilhadas e a autoridade de segurança que controlava o reingresso. Múltiplos nomes de prédios não criaram recuperação independente se a mesma decisão de emergência pudesse tornar todos eles indisponíveis.

Contar o impacto requer mais de um número

A medição externa da Netcraft da interrupção descobriu 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. Essa é uma visão em escala da internet da perda de acessibilidade. Ela captura subdomínios hospedados e acordos de hospedagem downstream, razão pela qual excede em muito a contagem de clientes da OVH.

Os 65.000 clientes afetados e 120.000 serviços da OVH descrevem relações comerciais e de produto. Nenhum número diz quantos usuários finais não conseguiram acessar um serviço, quantas empresas perderam um canal de receita ou quantos conjuntos de dados eram irrecuperáveis. Reportagens contemporâneas da Reuters identificaram portais governamentais, bancos, lojas, sites de notícias e outros serviços online entre a interrupção. Esses exemplos mostram diversidade de consequência, 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 poderia ser reconstruído em outra região em horas. Um serviço gerenciado com dados de recuperação retidos pelo provedor poderia retornar quando a OVH restaurasse sua plataforma. Um cliente bare-metal aguardando inspeção ou realocação física poderia permanecer indisponível por semanas. Um cliente cujos únicos dados de produção e backups foram destruídos enfrentou perda permanente, independentemente da rapidez com que um novo servidor vazio chegasse.

Um relatório de incidente responsável deve, portanto, usar vários denominadores: clientes, serviços, servidores físicos, domínios, endereços externamente inalcançá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, cópia no mesmo prédio, cópia no mesmo local, região diferente da OVH ou cópia sob controle independente. As evidências públicas não fornecem essa matriz completa.

A ausência importa porque a remediação deve seguir o mecanismo de perda. Se os clientes não selecionaram um backup remoto claramente oferecido, melhor educação do produto e padrões mais seguros são relevantes. Se um produto chamado backup colocava todas as cópias dentro de um prédio sem uma divulgação clara do domínio de falha, o design do produto e a contratação 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 em "alguns clientes não tinham backup" impede a responsabilidade precisa.

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

O documento de registro de 2021 da OVHcloud (disponível aqui) disse que os serviços de backup de dados eram serviços pagos opcionais para a maioria dos clientes e que alguns experimentaram perda permanente de dados. Também disse 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. Certos serviços gerenciados pelo provedor, incluindo e-mail, foram apenas levemente interrompidos e não perderam dados porque a OVH fazia backup deles.

Essas divulgações derrotam duas histórias simples. É impreciso dizer que a OVH fez backup de todos os serviços e não conseguiu preservar todas as cópias. Também é inadequado dizer que todo cliente que perdeu dados não comprou backup. Os modelos de serviço diferiam. Alguns clientes mantinham a responsabilidade pela única cópia durável, alguns selecionaram opções do provedor com locais diferentes, e alguns consumiram serviços para os quais a OVH controlava a recuperação.

Um backup não é definido meramente 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 tempo 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 para 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 juntas.
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 retornar uma função de negócio a um estado aceitável.
6. Evidência:monitoramento de que o backup foi concluído, verificações de integridade, restaurações amostradas, exercícios completos de serviço e registros retidos mostrando o resultado.

Estrasburgo foi principalmente um teste de isolamento físico e tempo de recuperação, mas expôs todas as 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 uma aplicação. Uma cópia remota criptografada com chaves disponíveis apenas através da região que falhou pode ser durável e inutilizável. Um arquivo multiterabyte que leva dias para recuperar pode perder um objetivo de negócio de doze horas. Um backup armazenado no mesmo domínio de energia e incêndio pode estar perfeitamente atual até o evento que deveria cobrir.

A autoridade francesa de proteção de dados, CNIL, agora afirma 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 os backups no mesmo nível de segurança que a produção e testar a integridade e restauração. As diretrizes de segurança em nuvem da CNIL dizem aos clientes para verificar se um provedor de nuvem tem locais de backup geograficamente remotos de seus datacenters. Esses materiais de 2024 são orientações posteriores, não prova do dever contratual preciso para cada serviço da OVH em 2021.

São um benchmark claro para a prática atual.

O caso Bati Courtage tornou a linguagem do produto consequente

A disputa de um cliente dá à fronteira do backup especificidade legal. A France Bati Courtage usou um servidor virtual privado da OVH e uma opção de backup automático paga. De acordo com o registro, a OVH a informou em abril de 2021 que o backup também havia sido total e irreversivelmente destruído porque as cópias estavam no mesmo prédio que o servidor primário. O cliente buscou milhões de euros por perda de dados e alegou danos comerciais downstream.

O resultado mudou em apelação. Em seu julgamento de 24 de abril de 2025, o Tribunal de Apelação de Douai reteve uma quebra contratual porque a OVH não podia deixar o cliente acessar o backup concluído e conservá-lo para recuperação. Não manteve a alegação separada do cliente de que a OVH falhou ao não localizar os serviços em lugares geograficamente isolados. Também reteve a conclusão anterior de que a OVH não cometeu falha grave ou violações graves de segurança contra incêndio naquela disputa, rejeitou a defesa de força maior da OVH, manteve as limitações de responsabilidade relevantes e reduziu a indenização para 1.800,48 euros.

Essa decisão é mais estreita e instrutiva do que a amplamente divulgada decisão de primeira instância. Não estabelece que todo contrato de backup da OVH prometia um data center remoto. Não estabelece uma regra geral de que qualquer backup no mesmo local é legalmente defeituoso. Mostra que a responsabilidade não pode ser resolvida dizendo "o cliente era dono da 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 topologia por trás deles. Termos como "fisicamente isolado", "infraestrutura", "local", "região" e "remoto" podem carregar significados diferentes. Um array de discos separado é isolado de uma falha de servidor. Uma sala separada pode ser isolada de um incêndio em rack. Um prédio 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 dependências de controle, conta, chave ou rede que bloqueiem a recuperação.

Os clientes não devem ter que inferir 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 pretende suportar, o objetivo de recuperação e os deveres restantes do cliente. Os provedores devem reter a versão histórica dessas representações porque a interface e a documentação disponíveis quando um serviço foi adquirido podem posteriormente se tornar evidência central.

A limitação contratual e a responsabilidade operacional também divergem. A indenização em apelação foi pequena porque o tribunal aplicou 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 operacionalmente aceitável, nem uma grande perda alegada prova que o provedor legalmente deve esse valor. Os contratos alocam exposição financeira. Eles não restauram informações nem provam que um controle foi adequadamente projetado.

Responsabilidade compartilhada deve ser específica o suficiente para operar

"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 frase distribui culpa após a falha em vez de atribuir controles antes dela. Estrasburgo apoia uma divisão mais exata.

A OVH era dona da probabilidade de que um evento elétrico local crescesse para uma perda de prédio. 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 relacionamento com bombeiros públicos. Os clientes não podiam instalar sprinklers no SBG2 ou criar um corte de energia de emergência. Esses são controles do provedor mesmo quando os contratos dos clientes limitam danos.

A OVH também era dona da verdade sobre seus produtos. Apenas o provedor podia saber onde um backup automático caiu, 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 tinha que descrever essas propriedades com precisão suficiente para que um cliente tomasse uma decisão de risco. Onde a OVH realizava o serviço de backup, ela era dona do desempenho do serviço prometido e da evidência sobre a cópia resultante.

Os clientes eram donos do modelo de consequência. Um provedor não podia saber, sem um acordo 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 tinha que classificar dados, definir objetivos de recuperação, selecionar uma arquitetura proporcional ao impacto, preservar 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 por quanto tempo o negócio podia tolerar sua perda.

O limite se move com o modelo de serviço. Em bare metal não gerenciado ou infraestrutura como serviço, o cliente normalmente é dono do backup consistente com a aplicação e failover. Em um banco de dados gerenciado, produto de e-mail hospedado ou serviço de backup explícito, o provedor é dono de mais da cópia, retenção, consistência e caminho de restauração. Um revendedor de mercado ou provedor de serviços gerenciados introduz outra camada: ele pode selecionar a OVH, configurar o backup, representar resiliência para seus próprios clientes e reter o único acesso administrativo. Os clientes finais precisam conhecer essa cadeia.

Os fundamentos atuais de backup da agência francesa de cibersegurança ANSSI transformam esses deveres em controles práticos. Eles pedem objetivos de ponto e tempo de recuperação, o padrão 3-2-1, pelo menos uma cópia offline ou off-site adequadamente protegida, testes regulares de restauração, uma ordem de restauração e proteção de mídia de instalação e configurações de aplicação. Para backup terceirizado, a ANSSI destaca localização na UE, comportamento de replicação do provedor, criptografia controlada pelo cliente e tempo de recuperação.

Este é um lembrete útil de que resiliência física, isolamento cibernético, soberania e recuperabilidade precisam 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 que buscam uma alternativa aos hiperescaladores não europeus, um provedor francês operando datacenters 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 soberania não é um substituto para engenharia de disponibilidade.

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

• Localização legal:quais regras de proteção de dados, divulgação, insolvência e setoriais do país regem armazenamento, processamento e acesso.
• Controle corporativo:quais empresas controladoras, administradores, subprocessadores e demandas legais estrangeiras podem influenciar o serviço.
• Localização física:qual prédio, planície de inundação, rede elétrica, abastecimento de água, campus e perigo regional contém cada cópia.
• Localização lógica:qual região, zona, conta, locatário, sistema de chaves e plano de controle deve operar 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 parte da primeira pergunta e restringe a terceira. Não exige que produção e backup ocupem o mesmo prédio. A França contém várias áreas metropolitanas e regiões de nuvem. Uma política que exige armazenamento na UE permite ainda mais diversidade geográfica enquanto preserva um perímetro legal da UE. Se isso é suficiente depende da lei, modelo de ameaça, sensibilidade dos dados e objetivo de recuperação da organização.

A explicação da Comissão Europeia sobre transferências internacionais também evita uma simplificação oposta: o GDPR não impõe uma regra absoluta de que os dados pessoais nunca podem sair do Espaço Econômico Europeu. Ele fornece adequação, salvaguardas e derrogações limitadas para transferências. Algumas organizações, no entanto, adotam requisitos de localidade mais rigorosos devido a lei setorial, política pública, promessas contratuais ou exposição a jurisdição estrangeira.

As diretrizes de qualificação SecNumCloud da ANSSI ilustram o modelo de soberania mais rico. Elas abordam a 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. Esse quadro é sobre controle sobre serviço e dados, não meramente a latitude e longitude de um disco.

A conclusão prática é construtiva: soberania e separação de desastres podem se reforçar 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 na UE, usar criptografia e chaves controladas pelo cliente e reter procedimentos de exportação testados para outro ambiente aprovado. A arquitetura pode custar mais e exigir revisão legal cuidadosa. A compensação deve ser explícita em vez de escondida dentro da palavra "local".

Concentração é uma propriedade de aplicação tanto quanto uma propriedade de mercado

A interrupção afetou portais governamentais, comércio, mídia, jogos e serviços voltados ao público porque muitas organizações selecionaram um provedor ou o herdaram através de um fornecedor. Isso é concentração de nuvem no nível do 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.

As duas formas exigem tratamento diferente. Reguladores podem monitorar a dependência sistêmica de um pequeno grupo de provedores de nuvem. Equipes de compras podem evitar concentração não examinada de provedores entre departamentos. Proprietários de aplicações devem mapear as 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 sistema crítico ainda não tem cópia independente. Outra pode permanecer com um provedor, mas usar regiões genuinamente separadas, backups exportáveis, DNS independente e materiais de recuperação offline.

A regulação financeira expressa cada vez mais essa responsabilidade retida do cliente. As diretrizes de terceirização de 2019 da Autoridade Bancária Europeia (EBA) 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 posterior Regulamento de Resiliência Operacional Digital da UE, ou DORA, exige que entidades financeiras cobertas mantenham e testem periodicamente arranjos de backup, restauração e recuperação. Seus requisitos do 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 em todo cliente da OVH de 2021. Elas mostram a direção da prática responsável: terceirização não terceiriza a responsabilidade do órgão de governo pela continuidade.

O quadro de implementação detalhado do 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 datacenters, falha de serviço de terceiros, comutação para capacidade redundante e interrupções generalizadas de energia. Estrasburgo é exatamente o tipo de evento físico e de fornecedor combinado que um exercício sério deve modelar.

O design com múltiplos provedores pode reduzir algumas dependências, mas não é automaticamente superior. Ele adiciona complexidade de identidade, rede, consistência de dados, habilidade, observabilidade e coordenação de incidentes. O objetivo correto é recuperação portátil 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 significa capacidade morna em outra região. Às vezes um backup protegido mais infraestrutura como código e uma reconstrução exercida atende à necessidade do negócio a um custo muito menor.

A restauração deve ser provada do lado do cliente

A restauração do provedor e a recuperação do cliente não são o mesmo relógio. A OVH podia declarar um data center operacional quando energia, rede e uma grande parcela dos servidores estavam disponíveis. Um cliente ainda tinha que 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 tinha que provisionar uma alternativa, recuperar dados, reconstruir a aplicação e reconciliar tudo que ocorreu após a última cópia utilizável.

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

A evidência deve responder a perguntas práticas. Qual era o timestamp do banco de dados restaurado? Quais escritas foram perdidas? Todas as versões do entidade-store foram incluídas? As chaves puderam ser recuperadas sem enfraquecer o controle de acesso? O DNS mudou dentro do tempo 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 que reconciliação permaneceu?

O monitoramento de backup sozinho não pode responder a essas perguntas. Um job 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 os sistemas podem ser reconstruídos. Um exercício de serviço prova que a organização pode entregar sua função prioritária sob a falha assumida. Cada um é útil; nenhum deve ser representado como o próximo.

Isso é especialmente importante para pequenas organizações. Elas podem não precisar de infraestrutura ativo-ativo ou uma segunda nuvem dedicada. Elas precisam de um caminho proporcional para sair. Uma pequena empresa pode exportar seu banco de dados e documentos críticos para um destino criptografado sob uma conta separada, reter suas credenciais de domínio e implantação independentemente, documentar uma reconstrução limpa e testar uma restauração amostral. O controle deve corresponder ao custo de perder os registros, não ao preço mensal do servidor.

A remediação da OVHcloud abordou a cadeia física

A resposta da OVH ao BEA-RI descreveu um programa substancial "Hyper Resilience". A empresa disse que fortaleceria a detecção, generalizaria a extinção automática onde ausente, redesenharía zonas e compartimentação, aumentaria a resistência comum ao fogo de sessenta para 120 minutos e colocaria salas de energia e bateria fora dos prédios do data center para novos locais e, onde viável, nos existentes. Planejou cortes elétricos remotos por zona para que os respondedores pudessem isolar o perigo sem desabilitar desnecessariamente áreas não afetadas.

A resposta também disse que os bombeiros locais visitaram todos os locais da OVH dentro de quatro meses do incidente, documentos de emergência e procedimentos de corte de energia foram revisados, e um novo departamento de risco industrial foi criado. Em Estrasburgo, a OVH instalou um tanque de água privado de 120 metros cúbicos em colaboração com o SIS67. Disse que todos os locais receberam uma análise de risco de incêndio e que a eficácia seria medida através de um estudo de vulnerabilidade quando o trabalho fosse concluído. O SBG5, inaugurado em julho de 2022, foi apresentado como um exemplo dos novos padrões.

Essas ações se mapeiam bem na cadeia causal e de propagação da investigação. A supressão aborda o crescimento inicial. Compartimentos de incêndio mais fortes abordam a propagação vertical e entre prédios. Salas de energia externas separam os perigos de ignição das salas de servidores. Cortes zoneados abordam o atraso e o raio de explosão do isolamento elétrico. O armazenamento de água aborda a capacidade de primeira resposta. Visitas e exercícios dos bombeiros abordam falta de familiaridade, planos e decisões de comando.

O documento de registro universal de 2025 da OVHcloud (disponível aqui) diz que o grupo continuou o mapeamento de risco de locais durante 2025 e descreve a Hyper Resilience como fortalecendo a segurança do data center acima 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 duradouro e tratamento financeiro, não um certificado de conclusão independente local por local.

O fechamento responsável publicaria ou forneceria a clientes qualificados e auditores uma matriz de controle: quais locais têm supressão automática em todas as salas de energia e TI relevantes; quais têm compartimentos de 120 minutos; quais salas de bateria são externas; quais zonas têm isolamento operado remotamente; quais requisitos de fluxo de água foram testados; quais exercícios com bombeiros ocorreram; quais descobertas permanecem abertas; e qual parte independente verificou a operação. Um compromisso de política é o começo da remediação. Cobertura e exercício adversarial mostram se funciona.

A empresa também merece crédito por preservar um log de atualização público detalhado 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 meramente 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 do produto mudou, 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 pré-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. Afirma que uma região de 1 AZ permanece vulnerável a falhas que afetam um data center inteiro, enquanto a arquitetura de 3 AZ usa zonas independentes para casos de produção e recuperação de desastres mais exigentes.

A visão geral de regiões e zonas de disponibilidade da empresa também diz que clientes que buscam maior resiliência devem selecionar uma região multizona suportada e construir para múltiplas zonas. Os verbos importam: o provedor fornece zonas; o cliente deve distribuir recursos e estado da aplicação entre elas. Meramente lançar em uma região de 3 AZ não garante que uma máquina virtual, um banco de dados ou um volume colocado manualmente abranja zonas.

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

A documentação atual não deve ser usada para reconstruir o que todo cliente recebeu em março de 2021. É relevante para a questão atual de responsabilidade: o mercado aprendeu a expor localidade e resiliência separadamente? A OVHcloud agora faz isso 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 os backups gerenciados pelo provedor seguem regras diferentes.

Um design mais seguro também pode usar padrões graduados. Um serviço de desenvolvimento de baixo custo pode razoavelmente usar backup local por 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 produto com marca de backup pode exigir que o cliente afirme o domínio de falha, exiba um aviso quando todas as cópias compartilham um local e ofereça um destino remoto na mesma região legal. O objetivo é aceitação informada de risco, não forçar toda carga de trabalho na arquitetura mais cara.

O conselho precisa de evidência em dois planos de controle

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

Para a camada de instalação, a liderança deve saber a perda máxima provável em cada local, não apenas redundância de equipamentos. Relatórios devem mostrar cobertura de supressão, integridade da compartimentação, separação de sala de energia, desempenho de detecção, água de emergência, tempo de isolamento de energia, familiaridade dos bombeiros, exceções de manutenção e trabalho corretivo atrasado. 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 liderança deve saber como os domínios de falha do produto são representados e testados. Relatórios devem mostrar quantos serviços comercializados com linguagem de backup ou alta disponibilidade armazenam toda cópia em um local ou região; quantos clientes selecionaram proteção distante; sucesso de restauração por produto e escala; dependências de chave e identidade; distribuição de tempo de recuperação; desvio de documentação; e reclamações indicando que clientes entenderam mal a localização.

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

O desafio independente deve rastrear uma promessa ao cliente até o fim. Selecione um serviço vendido como com backup. Registre o que a interface e o contrato dizem. Localize cada cópia e seus metadados de controle. Remova o local 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 quebra é uma lacuna acionável, seja de propriedade do produto, infraestrutura, suporte ou cliente.

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

As organizações não precisam de acesso privado a cada planta de data center. Elas precisam de respostas detalhadas o suficiente para decidir se um serviço se adequa à consequência da falha. As seguintes perguntas transformam as lições de Estrasburgo em evidência de aquisição:

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

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

Finalmente, um cliente deve decidir quanta perda é aceitável. Perda zero de dados e tempo de inatividade quase zero em desastres regionais exigem replicação contínua, design de aplicação, capacidade e testes operacionais que podem ser caros. Uma cópia offline semanal pode ser adequada para um arquivo estático e desastrosa 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ência.

O sinal duradouro

O incêndio de Estrasburgo não foi apenas uma ignição infeliz seguida por um lembrete para fazer backups. Foi uma demonstração de como as abstrações falham sob estresse físico. Prédios separados formaram um único local de emergência. Servidores saudáveis ficaram indisponíveis juntamente com os danificados. Um backup concluído podia desaparecer com a produção. Uma localização europeia que servia soberania e latência podia se tornar uma concentração de risco de incêndio. Um servidor de reposição podia restaurar infraestrutura sem restaurar o negócio do cliente.

O registro público também contém melhoria significativa. A detecção e a equipe noturna protegeram vidas. Os bombeiros e o barco-bomba EUROPA limitaram a propagação. A OVH realizou 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 remoto e implantação de zona única de multizona. Essas não são mudanças cosméticas.

O padrão de responsabilidade restante é 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 em locais relevantes; que a linguagem do produto se mapeia para domínios de falha reais; e que a recuperação gerenciada funciona quando uma região e seus caminhos de controle normais estão ausentes. Os clientes devem ser capazes de mostrar que dados críticos têm uma cópia utilizável fora do perigo primário, dentro dos limites legais aprovados, e que suas pessoas podem restaurá-la dentro do objetivo de negócio.

Nenhum provedor de nuvem pode prometer que um prédio nunca queimará. Nenhum cliente pode eliminar toda dependência. A promessa crível é mais estreita: um evento físico previsível não consumirá silenciosamente produção, recuperação e os meios para entender o que foi perdido; as escolhas de localidade serão explícitas tanto sobre jurisdição quanto sobre perigo; e a palavra "backup" será apoiada pela única evidência que realmente importa, uma restauração bem-sucedida sob as condições para as quais a cópia foi comprada.