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

Resumo

• Alarmes de incêndio ativados 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 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 lá ficaram indisponíveis devido à necessidade de isolamento elétrico, inspeção de segurança, limpeza e reinicialização em etapas. Ninguém morreu ou ficou ferido.
• A investigação francesa de segurança industrial não determinou a causa precisa das falhas elétricas quase simultâneas observadas em um UPS e suas baterias de chumbo associadas. Ela estabeleceu fatores de propagação e resposta: nenhum sistema de extinção automática em nenhum dos cinco edifícios de Estrasburgo, rápida movimentação da fumaça pelo design aberto de resfriamento do SBG2, capacidade limitada de água para incêndio e um difícil desligamento elétrico em todo o local. Detecção funcional, pessoal noturno, separação resistente ao fogo protegendo o SBG3 e a chegada de um barco de bombeiros franco-alemão de alta capacidade limitaram consequências piores.
• Perda de disponibilidade e 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 próprio documento de registro da OVHcloud afirmava que os backups oferecidos podiam ser armazenados no mesmo data center ou em um diferente, e uma decisão judicial posterior envolveu um cliente cujo backup automático pago foi destruído no mesmo edifício 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 enquanto ainda permite 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 de local, trabalho com serviços de incêndio e novas opções multizona e de backup remoto. O encerramento responsável, no entanto, exige evidências específicas de serviço e local: cobertura de controle concluída, 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" encoraja uma abstração. É útil quando engenheiros desejam uma interface padrão para capacidade de computação, mas perigoso quando tomadores de decisão começam a tratar localização, energia e incêndio como detalhes de outra pessoa. Cada servidor virtual reside em uma sala. Cada réplica de armazenamento ocupa equipamento conectado a sistemas elétricos e de resfriamento. Cada fluxo de trabalho de recuperação depende de pessoas, redes, credenciais, catálogos e um local de onde a capacidade de substituição 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 Port du Rhin. O SBG1 foi parcialmente destruído. Os dois outros 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 edifícios adjacentes foram expostos a calor, fumaça, água ou incerteza; e equipamentos saudáveis se tornaram indisponíveis quando o local teve que ser isolado eletricamente e tornado seguro.

Esses mecanismos importam porque correspondem a controles diferentes. Supressão automática e 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" oculta quem controla cada camada e qual evento ela pode sobreviver.

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. Seu mandato era prevenção, não alocação de responsabilidade civil ou criminal. Essa fronteira é 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 de equipamento se tornasse uma interrupção em vários edifícios, uma restauração prolongada e uma perda irreversível de clientes? A OVH controlava o projeto 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, arquitetura, muitas seleções de serviço e cópias independentes. Reguladores e órgãos profissionais controlavam partes do quadro mínimo. 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 edifício foi evacuado às 00:39, o serviço de bombeiros e resgate do 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 a hora em que o incêndio começou. 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 forneceu um marcador público de incidente.

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

A investigação localizou a origem do incêndio em salas que abrigavam baterias e equipamentos de fonte de alimentação ininterrupta. Registros 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 naquele 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 moderação tem sido frequentemente perdida em versões que dizem que um sistema de resfriamento com vazamento ou um UPS recentemente reparado 'causou' o incêndio. O registro oficial de acidentes ARIA francês é uma confirmaçã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 confiá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 falhas 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 projeto do edifício e os procedimentos de emergência deram às pessoas e aos serviços adjacentes proteção independente suficiente depois que algo inflamou.

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

O local de Estrasburgo fez bem um trabalho de segurança de vida. A detecção de fumaça óptica e aspirante funcionou. A equipe noturna permitiu verificação rápida e um chamado precoce aos bombeiros. Todos escaparam, e não houve ferimentos. 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 acompanhada por supressão automática. A investigação descobriu que nenhum dos cinco edifícios do local tinha um sistema automático de proteção contra incêndio. As salas de bateria 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 a extinção, particularmente em uma sala elétrica, mas poderia ter alterado a curva de crescimento do incêndio.

O edifício 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 aspirantes haviam sido ativados em todos os níveis. O BEA-RI advertiu que o tempo dos detectores mostrava 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 de 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 este design. O abastecimento público de água para incêndio disponível para a primeira resposta foi inadequado para o evento em desenvolvimento, de acordo com a investigação, e a OVH não tinha 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 bombeiros não pôde aplicar grandes jatos de água com segurança até que essas fontes fossem neutralizadas.

Este é o paradoxo da resiliência de infraestrutura. A energia de reserva preserva a computação durante uma falha comum de utilidade, mas torna-se outra fonte de energia a ser gerenciada 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 de local compartilhadas 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 orientações do setor citadas pela investigação eram posteriores ao projeto do SBG2. Isso é relevante para a 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 de alta consequência crível.

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ó, uma evidência de que o tratamento de risco mudou.

Quatro edifícios 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, eles formaram um único local de emergência. O SBG2 queimou. O SBG1 e o SBG3 foram afetados pelo incêndio em diferentes graus. O SBG4 não foi danificado pelo incêndio inicial. No entanto, a eletricidade 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 em etapas.

O registro de atualizações 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 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 o SBG1 e o SBG4 novamente como precaução e revisou o cronograma de reinicialização. A restauração do serviço 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 porcentagens, enquanto o equipamento do SBG1 ainda estava sendo limpo, reparado e realocado.

O documento de registro da OVH posteriormente disse que a maioria dos serviços dos clientes retornou em três a quatro semanas e 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 substituto pode ser provisionado enquanto os discos e registros anteriores do cliente permanecem destruídos. A relatoria de recuperação deve separar disponibilidade de infraestrutura, inicialização de aplicativo, 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 é o que um perigo pode afetar em conjunto. Para a resposta a incêndio em Estrasburgo, o domínio relevante incluía os edifícios vizinhos, procedimentos de isolamento de energia, acesso de emergência, capacidade de água, fumaça, operações compartilhadas e a autoridade de segurança controlando o reingresso. Vários nomes de edifícios 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 interrupção pela Netcraft encontrou cerca de 3,6 milhões de sites em 464.000 domínios distintos offline e mais de 18 por cento 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 arranjos de hospedagem a jusante, 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 relacionamentos 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 mantidos pelo provedor poderia retornar quando a OVH restaurasse sua plataforma. Um cliente bare-metal esperando por 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, uma cópia no mesmo edifício, uma cópia no mesmo local, uma região diferente da OVH ou uma cópia sob controle independente. A evidência pública não fornece 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 edifício 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 afirmava 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 copiados eram armazenados no mesmo data center ou em um data center diferente. Certos serviços gerenciados pelo provedor, incluindo correio, foram apenas moderadamente 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 fazia 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 deixou de comprar 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 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 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 que falhou pode ser durável e inutilizável. Um arquivo de vários terabytes que leva dias para ser recuperado 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 expõe claramente a lição física em sua orientação de segurança de backup: mantenha pelo menos uma cópia em um local geograficamente distinto, isole pelo menos uma cópia offline, proteja os backups no mesmo nível de segurança que a produção e teste a integridade e a restauração. A orientação de segurança em nuvem da CNIL diz aos clientes para verificar se um provedor de nuvem tem locais de backup geograficamente remotos de seus datacenters. Estes 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 parâmetro 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. 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 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 buscou milhões de euros por perda de dados e supostos danos comerciais a jusante.

O resultado mudou em recurso. Em seu julgamento de 24 de abril de 2025, o Tribunal de Apelação de Douai manteve uma violação contratual porque a OVH não pôde deixar o cliente com acesso ao backup concluído e conservá-lo para recuperação. Não manteve a alegação separada do cliente de que a OVH falhou em localizar os serviços em locais geograficamente isolados. Também manteve a constatação anterior de que a OVH não cometeu falta 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 EUR 1.800,48.

Essa decisão é mais restrita e instrutiva do que a amplamente noticiada sentença de primeira instância. Ela 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 relativas à 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 conjunto de discos separado é isolado de uma falha de servidor. Uma sala separada pode ser isolada de um incêndio em 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 dependências de controle, conta, chave ou rede que bloqueiem a recuperação.

Os clientes não devem ter que inferir essas fronteiras a partir 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 sobreviver, 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 mais tarde se tornar evidência central.

A limitação contratual e a responsabilidade operacional também divergem. A indenização no recurso foi pequena porque o tribunal aplicou as limitações acordadas após avaliar as alegaçõ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 deve legalmente esse valor. Os contratos alocam exposição financeira. Eles não restauram informações nem provam que um controle foi adequadamente projetado.

A 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 controlava a probabilidade de que um evento elétrico local crescesse para uma perda de edifício. Escolheu o projeto 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 que os contratos dos clientes limitem danos.

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

Os clientes controlavam o modelo de consequência. Um provedor não podia saber, sem um arranjo gerenciado específico, se um pequeno servidor virtual abrigava 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 quanto tempo o negócio podia tolerar sua perda.

A fronteira se move com o modelo de serviço. Em bare metal não gerenciado ou infraestrutura como serviço, o cliente geralmente controla o backup consistente com o aplicativo e o failover. Em um banco de dados gerenciado, produto de correio hospedado ou serviço de backup explícito, o provedor controla mais da cópia, retenção, consistência e caminho de restauração. Um revendedor de marketplace ou provedor de serviços gerenciados introduz outra camada: 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 fora do local adequadamente protegida, testes regulares de restauração, uma ordem de restauração e proteção de mídias de instalação e configurações de aplicativo. 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.

A 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 hyperscalers 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 a soberania não é um substituto para a engenharia de disponibilidade.

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

• Local legal:as regras de proteção de dados, divulgação, insolvência e setoriais de qual país governam armazenamento, processamento e acesso.
• Controle corporativo:quais empresas controladoras, administradores, subprocessadores e demandas legais estrangeiras podem influenciar o serviço.
• Local físico:qual edifício, planície de inundação, rede elétrica, abastecimento de água, campus e perigo regional contém cada cópia.
• Local lógico:qual região, zona, conta, locatário, sistema de chaves e plano de controle devem 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 edifício. 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 impede uma simplificação oposta: o GDPR não impõe uma regra absoluta de que os dados pessoais nunca podem deixar o Espaço Econômico Europeu. Ele fornece adequação, salvaguardas e derrogações limitadas para transferências. Algumas organizações adotam requisitos de localidade mais estritos devido a leis setoriais, políticas públicas, promessas contratuais ou exposição a jurisdições estrangeiras.

A orientação de qualificação SecNumCloud da ANSSI ilustra o modelo de soberania mais rico. Ela aborda 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 à lei não europeia. 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 troca deve ser explícita, em vez de escondida dentro da palavra 'local'.

A concentração é uma propriedade tanto de aplicação quanto de mercado

A interrupção afetou portais governamentais, comércio, mídia, jogos e serviços públicos porque muitas organizações selecionaram um provedor ou o herdaram através de um fornecedor. Isso é concentração de nuvem no nível de mercado. Houve também concentração dentro de aplicações individuais: produção, backups, DNS, correio, gerenciamento e ferramentas de implantação podiam compartilhar a OVH ou Estrasburgo mesmo quando apareciam como produtos separados.

As duas formas requerem tratamento diferente. Reguladores podem monitorar a dependência sistêmica de um pequeno grupo de provedores de nuvem. Equipes de contratação podem evitar concentração de provedor não examinada 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 todo 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 cada vez mais expressa 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. A posterior Lei de Resiliência Operacional Digital (DORA) da UE 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. Mostram a direção da prática responsável: terceirizar não terceiriza a responsabilidade do órgão de governança pela continuidade.

O quadro de implementação detalhado da DORA vai mais longe. 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 cortes de energia generalizados. Estrasburgo é exatamente o tipo de evento físico combinado com fornecedor que um exercício sério deve modelar.

O design multiprovedor pode reduzir algumas dependências, mas não é automaticamente superior. Adiciona complexidade de identidade, rede, consistência de dados, habilidade, 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 significa capacidade morna em outra região. Às vezes um backup protegido mais infraestrutura como código e uma reconstrução exercida atendem à necessidade de negócio a um custo muito menor.

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

Restauração do provedor e 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 de 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 o aplicativo e reconciliar tudo que ocorreu após a última cópia utilizável.

Um exercício de recuperação maduro 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 de negócio.

A evidência deve responder a perguntas práticas. Qual era o timestamp do banco de dados restaurado? Quais gravações foram perdidas? Todas as versões do armazenamento de objetos 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, correio 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 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 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. 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 seu domínio e credenciais de implantação independentemente, documentar uma reconstrução limpa e testar uma restauração amostrada. 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 ordinária ao fogo de sessenta para 120 minutos e colocaria salas de energia e bateria fora dos edifícios de 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 serviços de incêndio 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 estivesse concluído. O SBG5, inaugurado em julho de 2022, foi apresentado como um exemplo dos novos padrões.

Essas ações se alinham bem com a cadeia causal e de propagação da investigação. Supressão aborda o crescimento inicial. Compartimentos de incêndio mais fortes abordam a propagação vertical e entre edifícios. Salas de energia externas separam fontes de ignição das salas de servidores. Cortes zoneados abordam o atraso e o raio de explosão do isolamento elétrico. Armazenamento de água aborda a capacidade de primeira resposta. Visitas e exercícios dos bombeiros abordam desconhecimento, planos e decisões de comando.

O documento de registro universal de 2025 da OVHcloud diz que o grupo continuou o mapeamento de risco de local durante 2025 e descreve o Hyper Resilience como fortalecendo a segurança de 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 encerramento 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 dos 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 adversarial mostram se funciona.

A empresa também merece crédito por preservar um registro 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 1-AZ permanece vulnerável a falhas que afetam um data center inteiro, enquanto a arquitetura 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 do aplicativo entre elas. Meramente lançar em uma região 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âncias 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. 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 contratação e a 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 do painel de controle, APIs, faturas e respostas de suporte, incluindo produtos onde backups gerenciados pelo provedor seguem regras diferentes.

Design mais seguro também pode usar padrões graduados. Um serviço de desenvolvimento de baixo custo pode razoavelmente ter como padrão backup local 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. Engenharia de incêndio não pode ser tratada como uma nota de rodapé imobiliária, e produtos de backup não podem ser tratados apenas como receita de armazenamento.

Para a camada de instalação, a liderança deve conhecer a perda máxima provável em cada local, não apenas redundância de equipamento. Relatórios devem mostrar cobertura de supressão, integridade de compartimento, separação de salas 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 remota; 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 trabalho de backup de 99,99% pode coexistir com milhares de cópias em um domínio físico. Uma porcentagem global de supressão pode esconder um edifício 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 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

Organizações não precisam de acesso privado a cada planta de data center. 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 contrataçã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 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 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 dos 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 subjacentemente. DNS, correio, código fonte, segredos e comunicações de incidentes podem todos compartilhar o provedor. A diversidade é medida por caminhos sobreviventes, não pela 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 aplicativo, 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 abstrações falham sob estresse físico. Edifícios separados formaram um único local de emergência. Servidores saudáveis se tornaram 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 substituto podia restaurar infraestrutura sem restaurar o negócio do cliente.

O registro público também contém melhoria significativa. Detecção e pessoal noturno protegeram vidas. Bombeiros e o barco de bombeiros 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. Estas 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 nos locais relevantes; que a linguagem do produto mapeia para domínios de falha reais; 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 perigo primário, dentro de limites legais aprovados, e que suas pessoas podem restaurá-la dentro do objetivo de negócio.

Nenhum provedor de nuvem pode prometer que um edifício nunca queimará. Nenhum cliente pode eliminar toda dependência. A promessa crível é mais restrita: um evento físico previsível não consumirá silenciosamente produção, recuperação e os meios de 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á sustentada pela única evidência que importa, uma restauração bem-sucedida sob as condições para as quais a cópia foi comprada.