O incidente do GitLab coloca backup sob teste real

O GitLab.com acaba de enfrentar um incidente severo de banco de dados. Durante uma resposta a instabilidade na base, dados da instância primária foram removidos acidentalmente. O serviço ficou indisponível por horas e parte das alterações feitas em produção não pôde ser recuperada. No comunicado inicial, a empresa reconhece perda de dados de banco, incluindo issues, merge requests, usuários, comentários e snippets, enquanto repositórios Git e wikis não foram afetados.¹

O episódio chama atenção não só pela gravidade, mas pela transparência. O GitLab publicou uma transmissão aberta e documentos de acompanhamento do incidente. Essa abertura ajuda equipes de TI a discutir um ponto frequentemente tratado como checklist: não basta "ter backup". É preciso saber se o backup é íntegro, se está recente o suficiente, se pode ser restaurado dentro do prazo necessário e se alguém consegue conduzir a recuperação quando o ambiente está degradado.

Backup não é evidência de recuperação

O incidente expõe uma combinação de falhas comuns em operações reais: mecanismos de backup que existem, mas não entregam a confiança esperada; restaurações não validadas com frequência suficiente; pressão operacional crescente; e decisões tomadas no meio de um incidente ativo.²

A lição prática é direta. Políticas de backup precisam sair da planilha e entrar na rotina de engenharia. RPO e RTO devem ser definidos por sistema, por tipo de dado e por impacto de negócio. Um ERP, uma plataforma de atendimento, um repositório de código e um data lake não têm o mesmo custo de perda, nem a mesma urgência de retorno.

Também é insuficiente olhar apenas para o sucesso do job. Um backup que "rodou" pode estar incompleto, corrompido, inacessível, lento demais para restaurar ou dependente de credenciais e caminhos que não estarão disponíveis durante uma crise. A métrica relevante é a restauração testada.

Observabilidade inclui os caminhos de sobrevivência

Muitas empresas monitoram CPU, memória, latência de API e filas, mas deixam backup, replicação e restauração fora do painel principal. O incidente reforça que os controles de sobrevivência precisam ser observáveis como qualquer serviço crítico.

Isso inclui idade do último backup restaurável, atraso de réplica, divergência entre primário e secundário, taxa de erro de cópias, tempo real de restauração em ambiente isolado e alertas acionáveis quando algum desses sinais sai do limite. Também inclui documentação curta: em incidente severo, runbook longo e ambíguo vira risco.

Outro ponto relevante é a separação entre automação e autoridade. Scripts devem reduzir erro humano, mas operações destrutivas em produção precisam de guardrails: confirmações explícitas, permissões temporárias, trilhas de auditoria, bloqueios por ambiente e comandos que deixem claro onde estão atuando.

Transparência acelera maturidade

O GitLab transforma uma falha séria em material público de aprendizado. Para clientes, isso não apaga o impacto. Para a comunidade, porém, o caso amadurece a conversa sobre confiabilidade: incidentes não são apenas "falhas técnicas", mas consequências de desenho operacional, pressão, processo e cultura.

Empresas que dependem de software devem tratar esse tipo de evento como simulado indireto. A pergunta não é se alguém poderia apagar dados por engano. A pergunta é o que impediria essa ação, o que detectaria rapidamente o problema, o que seria restaurado, quanto seria perdido e quem teria autonomia para coordenar a resposta.

O GitLab deixa claro que confiabilidade não nasce de confiança verbal. Ela nasce de restaurações ensaiadas, monitoramento dos próprios mecanismos de recuperação e humildade suficiente para assumir que o incidente vai acontecer no pior horário possível.